What is a certificate chain of trust, and what does a client check before it trusts a server certificate?
Show the answer
Say this first
A server certificate (the leaf) binds a public key to names and is signed by an intermediate CA, which is signed by a root CA that the client already trusts in its store. The server sends the leaf plus the intermediates; the client builds a path to a trusted root and checks each signature, the validity dates, that the hostname matches a Subject Alternative Name, that the key usage allows server authentication, that each issuer is really a CA, and revocation and certificate transparency where its policy requires. A missing intermediate is the classic outage.
Go deeper
The chain
Root CA (self-signed, in the OS or browser trust store, not sent by the server)
signs -> Intermediate CA (sent by the server)
signs -> Leaf: shop.example.com (sent by the server, first)Roots stay offline; intermediates do daily issuing so a compromise can be contained.
Checks, in the order a client roughly applies them
- Build a path from leaf to a trusted root using what the server sent and the local store.
- Each certificate's signature verifies with its issuer's public key.
- Every certificate is within its notBefore and notAfter dates.
- Issuers have Basic Constraints CA:TRUE, and path length and name constraints are respected.
- The leaf's Extended Key Usage includes serverAuth.
- The hostname matches a DNS name in the SAN. Browsers ignore the Common Name.
- Revocation (CRLs, or OCSP where the CA still runs it; CRLs are now the required method for public CAs) and, in browsers, certificate transparency proofs.
Wildcards
*.example.com matches shop.example.com, but not example.com and not a.shop.example.com. The
wildcard covers exactly one label.
Lifetimes are shrinking
The CA/Browser Forum has voted to cut the maximum lifetime of public TLS certificates in steps, down to 47 days by 2029. Renewal has to be automated, usually with ACME.
They will ask next
Why does a site with a missing intermediate work in Chrome but fail in curl?
Many browsers fill the gap: they cache intermediates seen before, ship preloaded ones, or download the issuer from the Authority Information Access URL in the leaf. curl, Python, Java, Go and most API clients do not, so they fail with "unable to get local issuer certificate".
Should the server send the root too?
It is not needed: the client must already have the root to trust it. Sending it only adds bytes to the handshake. Send the leaf first, then each intermediate in order.
How do you see the chain a server actually sends?
openssl s_client -connect shop.example.com:443 -servername shop.example.com -showcerts. The "Certificate chain" section lists each certificate with s: (subject) and i: (issuer). Each i: must match the next s:.
Traps
- Saying the browser checks the Common Name. Modern clients only match the SAN.
- Fixing a chain error by installing the intermediate on one client. Fix the server so every client works.