Certificate chain

Chains exist so that the most valuable keys can stay offline. A root signs a handful of intermediates and then goes back in a safe, and the intermediates do the daily work of signing servers. Verification walks the other way, from the certificate you were handed up to something your device already had, and it fails if any link is missing, expired, or unrecognized.

How it works

Three positions make up a typical chain, and a server transmits only two of them.

At the bottom is the leaf, issued for a particular set of domain names. Above it sit one or more intermediates, whose purpose is to insulate the root from day-to-day use. At the top is the root, self-signed and sitting in your trust store since long before you visited the site. The server sends the leaf and the intermediates, because sending the root would add bytes and prove nothing: a root counts only if you already had it.

Validation is not a straight walk up a list. One certificate can be signed by more than one issuer, a practice called cross-signing, so a client may face several candidate paths and has to find one ending in a root it holds. This is why the same website loads on a new laptop and fails on an old phone. The paths differ because the trust stores differ.

The clearest illustration remains the Let's Encrypt transition. Its own root, ISRG Root X1, was cross-signed by the older DST Root CA X3 so that devices which had not yet added X1 could still build a path. DST Root CA X3 expired on September 30, 2021. Devices holding X1 switched paths without anyone noticing, while Android versions older than 7.1.1 and several legacy TLS libraries did not, and connections broke worldwide in a single afternoon. Nothing had been hacked and no key had leaked. A date had passed.

Where you see it

Chain problems look alarming and are almost always mundane.

The commonest server misconfiguration is a forgotten intermediate. Browsers often paper over it by caching intermediates from earlier visits or fetching them from a URL inside the certificate, so the site works for the administrator and fails for command line tools and phones, which makes it a memorably annoying bug to track down.

For anyone managing bitcoin, the useful reading of a chain error is diagnostic. When an exchange throws a certificate error on one device and works on another, the difference is nearly always the device: a wrong system clock, an operating system too old to have received a newer root, or an antivirus product inserting itself into the connection. Fix the device before assuming an attack, and never click past the warning to get in.

Hardware wallet attestation uses the same shape at a much smaller scale, with a vendor root, sometimes one intermediate, and a certificate held on the device itself.

Certificate chain vs root certificate

A chain is a path; a root is where the path has to end. Every certificate in the chain except the root is trusted only because something above it signed it, whereas the root is trusted because it appears on a list your device shipped with, and it signs itself. Adding a root to that list is therefore a much larger decision than accepting any other certificate, which is exactly what corporate networks and traffic interception tools ask you to do.