Certificates and the Chain of Trust

A certificate binds a name, such as shop.example.com, to a public key, and is signed by a certificate authority (CA) that vouches for the binding. A client trusts a certificate when it can follow a chain of signatures from it up to a root certificate it already holds in its trust store, the list of root CAs shipped with the operating system or browser.

Think of a reference letter for a stranger, signed by someone whose own reference is signed by a person you already trust. The comparison breaks in one place: a reference can be weighed and partly believed, while a signature either verifies exactly or the chain fails.

Each certificate holds a few fields that matter in practice: the subject, who it was issued to; the issuer, who signed it; the names it is valid for, in the subject alternative name list; the validity dates; and the public key.

The chain usually has three levels. The leaf is the server's own certificate. The intermediate is the CA certificate that signed the leaf. The root signed the intermediate and is trusted because it is in the trust store, not because anything else signs it. CAs keep root keys offline and do day-to-day signing with intermediates, so a compromised intermediate can be replaced without changing every trust store.

The client checks every link: each signature verifies with the public key of the certificate above, every certificate is within its dates, the leaf lists the host name requested, and the chain ends at a root in the store.

The server must send the leaf and the intermediates. The client has the roots but not, in general, the intermediates. Forgetting to send the intermediate is a classic fault: some browsers fill the gap from a cache or by fetching it, while command-line tools and other servers fail.

So when a certificate is not trusted, walk the chain: which link is missing, or which check failed on it.