y509

A certificate chain that works in the browser and fails in curl. The cause is almost always structural: the server never sent an intermediate, or sent its root, or sent them out of order. Browsers hide it by chasing the AIA URL to fetch the missing piece; curl, Go and Java do not, so the bug sits in production for months until a client library upgrade trips over it. The tools for this all answer the wrong question. openssl s_client dumps the raw handshake and leaves you counting BEGIN CERTIFICATE lines by eye. Everything else answers "does this verify", which is exactly the question that says yes while the chain is still broken for half your clients. I wanted the two questions separated, and I wanted the answer in a pane I could scroll rather than a wall of text.

Point it at a server that is misconfigured on purpose: y509 validate incomplete-chain.badssl.com:443 It reports the chain as valid, and then separately reports that the chain as presented is broken: the issuer was never sent, so a client that does not chase AIA cannot build a chain. It also prints the URL to fetch the missing intermediate from. That gap between the two answers is the whole tool in one screen. Then open the same host without validate, y509 incomplete-chain.badssl.com:443, to browse the chain interactively: a list of certificates on the left, tabbed detail on the right, search across subject/issuer/SAN, filters for expired and expiring, and export or copy any certificate as PEM.

Trust and presentation are two separate answers, and the certificates are never sorted. Every other tool sorts a chain into leaf-to-root order before showing it, because that reads better. But sorting destroys the evidence: the order the server actually sent them in is the bug. y509 keeps them exactly as they arrived, and derives the presentation report from that raw order. The handshake also deliberately verifies nothing. A chain that fails to verify is the reason you opened the tool, so rejecting it at the transport would defeat the purpose. The same split shows up in validate --json: trust.level and presentation.ok are independent fields. An exit code cannot carry that distinction. It collapses "internal PKI" and "does not link up" into one non-zero, and says nothing at all about how the chain was served.

STARTTLS coverage is expanding beyond smtp/imap/postgres to ftp, ldap and mysql, which closes the gap against certigo. Windows binaries are landing, along with a GitHub Action so the mis-served check can gate CI rather than only being run by hand. Nixpkgs packaging is in review; Homebrew and FreeBSD ports are already there. Longer term the interesting direction is expiry: as CA/Browser Forum maximum lifetimes shrink toward 47 days, renewals get frequent enough that a leaf-only certificate reaching production becomes a matter of when, not if.