Certificates, and where trust comes from

A certificate is a public key plus a list of names it is valid for, signed by somebody else. It is not a secret and it is not encryption — it is a claim, and the whole question is why you would believe it.

The client runs five checks, all of which must pass:

1. The chain is well-formed: each certificate is signed by the next one up.
2. The top of that chain is a certificate authority in the local trust store.
3. The current time is inside the validity window.
4. One of the certificate's subjectAltName entries matches the hostname.
5. It has not been revoked, and the key usage permits this.

Three of those fail interestingly, and they fail differently. Start with the second:

Trust is a list, not a discovery

That chain was internally perfect. Correct signatures, right hostname, current dates — and worthless, because the root at the top was not on the client's list.

This is the crucial structural fact about the web PKI: trust is a fixed set of root certificates shipped with the operating system or browser, not something established during a handshake. A server sends its leaf and any intermediates and never its root, because the client is supposed to already have it.

It is the same shape as the DNSSEC chain from track 3 — signatures down a chain, anchored at a root you were given out of band — with one important difference. DNSSEC has one root; the web PKI has hundreds, and any one of them can vouch for any name.

Right certificate, wrong name — and out of date

The fourth check catches a genuine certificate presented for a site it was not issued for. Identity is matched against the subjectAltName list, and against nothing else: a certificate whose Common Name matches perfectly and whose SANs do not still fails, even though the CN is the field a certificate viewer shows first.

The third check is the mundane one, and it is the most common failure in production:

Expiry exists to bound the damage of a leaked key. Revocation is supposed to do that job directly, but revocation checking is unreliable in practice — so certificates are simply short-lived instead, and a certificate that merely expired is still reported as "good" by a revocation responder. Expired and revoked are different rows.