Trust · stage 03
The certificate chain
Every site certificate is a claim. The chain is the evidence.
Stage 03 of six/Trust, piece 1 of 3/Full piece/Next: What the padlock does not mean
When your browser opens a TLS connection, the server sends a certificate asserting its identity. The browser does not trust that certificate directly — it trusts a set of root certificates embedded in the operating system or the browser itself, and the server's certificate is accepted only if a chain of cryptographic signatures connects it back to one of those roots.
How the chain is built
The chain typically has three layers. At the top sits a root certificate authority (CA): an organisation whose public key is already present in your device's root store — a curated list maintained by browser makers and OS vendors. Root certificates are extraordinarily sensitive; their private keys are kept offline, in hardware security modules, inside physically guarded facilities. Because actually signing things with a root key is dangerous, root CAs instead sign intermediate certificates and stop there.
Intermediate CAs do the day-to-day work. A root CA vouches for an intermediate by signing its certificate; the intermediate then signs the leaf certificates issued to actual websites. This two-step structure limits exposure: if an intermediate is compromised, it can be revoked without touching the root. Multiple intermediates can hang off the same root, each scoped to a particular type of certificate or a reseller's customers.
The leaf certificate — the one the server presents — identifies the domain, carries the server's public key, and names the intermediate that signed it. When the browser receives a TLS handshake, it verifies each signature in turn: leaf signed by intermediate, intermediate signed by root. If every signature checks out and the root is in the trust store, the chain is valid.
One practical detail trips up server operators constantly: the server must send the intermediate certificate along with its own. The browser almost never has intermediates cached. If the intermediate is missing from the handshake, the browser cannot complete the chain and will refuse the connection — even though the leaf certificate itself is perfectly legitimate. This is a configuration error, not a cryptographic failure, and it is among the most common causes of TLS errors in production.
Where Let's Encrypt fits
Let's Encrypt, the free CA operated by the nonprofit Internet Security Research Group, illustrated chain mechanics vividly in 2021 when its own cross-signed root expired. Let's Encrypt's root — ISRG Root X1 — was not yet in every device's trust store when the CA launched, so its certificates were also signed by an older IdenTrust root that was already universally trusted. That cross-signature gave the chain an alternative path to a trusted root on older devices. When the IdenTrust cross-signature expired, devices running old versions of Android that lacked ISRG Root X1 in their store began rejecting Let's Encrypt certificates — not because anything was wrong with the certificates, but because those devices could no longer complete a chain to a root they trusted.
The episode made concrete something easy to forget: trust is not a property of the certificate itself. It is a property of the path from that certificate to something already trusted, and that path can have more than one route, each with its own expiry.
Because actually signing things with a root key is dangerous, root CAs instead sign intermediate certificates and stop there.
What browsers actually check
Verifying the chain is necessary but not sufficient. Browsers also check that the certificate has not expired, that the domain in the certificate matches the domain being connected to, and that the certificate has not been revoked. Revocation is checked through mechanisms like OCSP (Online Certificate Status Protocol) or CRL (Certificate Revocation List) distribution points referenced inside the certificate itself. In practice, browsers handle revocation inconsistently — a problem explored in more depth in the guide on revocation.
The root store is ultimately a political and commercial artefact as much as a technical one. Inclusion in a major root store requires audits against standards such as the CA/Browser Forum's Baseline Requirements, a set of rules jointly developed by CAs and browser makers. Being removed from a root store — as happened to Symantec's CA infrastructure — breaks every certificate that chains through it, for every user of that browser. That is how much leverage the trust store holds.
