Certificates and the Chain of Trust

An X.509 certificate is a signed statement: "issuer *I* asserts that public key *K* belongs to subject *S*, valid from *t₁* to *t₂*". The parts that matter for TLS are the Subject Alternative Name extension listing the DNS names (and IPs) the certificate is valid for, the public key, the validity period, the issuer name, key usage flags, and the issuer’s signature over all of it. The Common Name field in the subject is historical; browsers have ignored it for hostname matching since around 2017 and only SANs count.

The signature is what makes the statement checkable: anyone with the issuer’s public key can verify it, and nobody without the issuer’s private key can forge it. So the question "is this key really api.example.com’s?" becomes "do I trust the issuer, and did the issuer really sign this?" — which is the same question one level up.

The recursion terminates at a root certificate that is self-signed and trusted not because of any signature but because it ships in the client’s trust store — the OS store (Windows, macOS, Android), Mozilla’s NSS bundle (Firefox, and the source of ca-certificates on most Linux distributions), or a language-runtime bundle (Java’s cacerts, Python’s certifi, Node’s compiled-in Mozilla list). Roots are kept offline and precious; they sign a handful of intermediate CAs, and intermediates sign the millions of leaf certificates servers present.

During the The TLS Handshake the server sends the leaf and the intermediates — not the root, which the client must already have. The client builds a path: leaf’s issuer must be the intermediate’s subject, the intermediate’s signature over the leaf must verify, the intermediate’s issuer must be a root in the store, and so on. Each certificate’s validity window, key usage and name constraints are checked along the way. A missing intermediate is the single most common chain misconfiguration, and it fails inconsistently: browsers often fetch the missing certificate via the AIA URL or have it cached, while curl, Java and mobile apps do not.

Hostname validation is the last step: the name the client connected to must match a SAN entry. A wildcard *.example.com matches exactly one label — api.example.com but not example.com and not a.b.example.com. IP addresses must appear as IP: SANs; connecting to a server by IP with a DNS-only certificate fails even when everything else is fine.

A certificate is valid until Not After regardless of what happens to the key. If the private key leaks, the issuer needs a way to say "no longer trust this one". Two mechanisms exist. A CRL is a signed list of revoked serial numbers published by the CA — simple, but large and slow to propagate, and a client must download it. OCSP lets the client ask the CA about one serial in real time, which leaks browsing history to the CA and adds a network round trip to every handshake.

Both mechanisms fail open in practice. If the OCSP responder is unreachable, browsers soft-fail and proceed, because a hard failure would let anyone who can block one URL take down every site using that CA. An attacker with a stolen key and on-path position can block the OCSP check, which is exactly the situation revocation was meant to cover. OCSP stapling helps: the server fetches a signed OCSP response periodically and sends it in the handshake, removing the client round trip and the privacy leak; Must-Staple in the certificate turns a missing staple into a hard failure, but it is rarely used.

The industry’s practical answer has been short lifetimes: Let’s Encrypt certificates last 90 days (with 6-day certificates being introduced), and the browser-CA forum has agreed to reduce the maximum public certificate lifetime to 47 days by 2029. A key that is only valid for days limits the damage of a leak without depending on a check that fails open. Browsers meanwhile push aggregated revocation data (Chrome’s CRLSets, Firefox’s CRLite) rather than querying per site.

Before 2015 a certificate meant a purchase, a manual CSR, an email validation and a person pasting files onto a server once a year — and forgetting to, which is why expired certificates were the most common TLS outage. Let’s Encrypt made issuance free and the ACME protocol (RFC 8555) made it automatic: the client proves control of the domain by serving a token at /.well-known/acme-challenge/ (HTTP-01) or publishing a _acme-challenge TXT record (DNS-01, the only option for wildcards), and receives a certificate minutes later. Clients such as certbot, acme.sh, Caddy (built in) and Kubernetes’ cert-manager renew at two-thirds of the lifetime without human involvement.

Every publicly trusted certificate is also logged to Certificate Transparency logs before browsers accept it — the SCTs in the extensions above — so a misissued certificate for your domain is publicly visible; monitoring CT for your names is how you find out a CA or a colleague issued one you did not expect.

The remaining operational work is making renewal *observable*: an alert on days-to-expiry (from an external probe, not from the box that is supposed to renew) catches the case where the automation is broken and nobody noticed — a renewed certificate that was never reloaded into the running process is the modern form of the old outage.

Almost every certificate incident is one of six shapes, and each has a recognisable error string. Learn the strings; they tell you which check failed and therefore where to look.