Understand the certificate chain

A certificate rarely stands alone. The certificate for a website is signed by an intermediate CA. That intermediate is signed by a root CA, and the root is what your operating system or browser already trusts. Verifying a certificate means walking that path: leaf, through the intermediates, up to a root you hold.

Why the extra layer? Damage control. Root keys stay offline and get used rarely. Day-to-day signing happens with intermediate keys. If an intermediate key leaks, the CA replaces it, and no device on earth needs a trust store update.

The split also decides who sends what. The server sends the leaf and the intermediates. The client already has the roots. From those two halves, the client builds a verified path.

Let’s see every certificate a server sends:

openssl s_client -connect flaviocopes.com:443 -servername flaviocopes.com -showcerts </dev/null

-showcerts prints each certificate as a PEM block, in the order the server sent them. Above each block you get subject and issuer. This is what my site returned in September 2026; the site sits behind Cloudflare, which rotates certificates between a few CAs, so your names may differ while the shape stays the same:

 0 s:CN=flaviocopes.com
   i:C=US, O=Google Trust Services, CN=WE1
 1 s:C=US, O=Google Trust Services, CN=WE1
   i:C=US, O=Google Trust Services LLC, CN=GTS Root R4
 2 s:C=US, O=Google Trust Services LLC, CN=GTS Root R4
   i:C=BE, O=GlobalSign nv-sa, OU=Root CA, CN=GlobalSign Root CA

Certificate 0 is the leaf, the one for the site itself. Certificate 1 is the intermediate. Notice how its s: line matches the leaf’s i: line exactly. That subject-to-issuer match is the chain. Each certificate points at the one that signed it.

Certificate 2 is interesting. It’s the GTS Root R4 root, but signed by an older GlobalSign root. That’s a cross-sign: it gives older devices that only know GlobalSign a way to reach a root they trust. Your laptop already has GTS Root R4 and ignores this extra hop.

That’s the general rule. Servers don’t need to send the root, and clients ignore a root they receive. What clients need is every intermediate between the leaf and a root they hold.

This structure explains a whole family of production bugs. A server configured with only the leaf works in a browser that cached the intermediate from another site. Then it fails in curl, in a mobile app, or in CI with unable to get local issuer certificate. Later in this course you’ll reproduce that failure on purpose and fix it.

A chain isn’t trusted because the certificates exist. Every signature must check out, the names must match, the dates must be current, and the root must be in the local trust store. One broken link fails the whole path.