Trust Has to Start Somewhere
A website's certificate says "this public key belongs to example.com." But anyone can generate a certificate making that claim — a self-signed certificate does exactly that, and your browser rejects it. What makes a certificate trustworthy is not its contents but who vouched for it. The chain is how that vouching is expressed and verified: a sequence of certificates where each one is signed by the next, ending at an authority your device trusts inherently.
That trusted endpoint is the key idea. Your operating system and browser ship with a trust store — a built-in list of certificate authority root certificates that are trusted by default. The whole purpose of the chain is to connect a site's certificate, which no one trusts on sight, back to one of those roots, which everyone does.
The Three Links
A typical chain has three levels, and each one signs the level below it using a digital signature:
Root CA certificate (in your device's trust store)
│ signs
▼
Intermediate certificate (sent by the server)
│ signs
▼
Leaf / end-entity certificate (the site's own — sent by the server)
│ belongs to
▼
example.com| Certificate | Belongs to | Role |
|---|---|---|
| Leaf (end-entity) | The website | Carries the site's name and public key; the certificate the site actually uses |
| Intermediate | The CA's signing arm | Signed by the root; signs leaf certificates so the root key never has to be used directly |
| Root | The certificate authority | Pre-installed and trusted directly; signs intermediates. Its private key is kept offline |
Why Bother With an Intermediate at All?
It would seem simpler for the root to sign website certificates directly. The reason it does not is security and damage control. A root certificate's private key is extraordinarily valuable — if it leaked, every certificate that traces to it would be compromised, and because the root lives in billions of trust stores, it cannot be quickly replaced. So CAs keep the root key locked away offline and use it only rarely, to sign a small number of intermediates.
The day-to-day work of signing millions of website certificates is delegated to those intermediates. If an intermediate key is ever compromised, the CA can revoke just that intermediate and issue a new one — a contained incident — without touching the irreplaceable root. The intermediate, in other words, is a firebreak between the precious root and the busy, exposed work of issuing certificates.
How the Browser Validates the Chain
During the TLS handshake the server sends its leaf certificate and the intermediate(s). The browser then works upward:
- Start at the leaf. Check that its name matches the site you asked for and that it has not expired.
- Find the certificate that signed the leaf — the intermediate — and verify the signature is valid using the intermediate's public key.
- Repeat up the chain: verify the intermediate was validly signed by the next certificate.
- Stop when you reach a certificate that is in the trust store. If the chain ends at a trusted root and every signature checked out, the certificate is trusted.
- Along the way, confirm none of the certificates has been revoked.
If any link is missing, any signature fails, or the chain ends somewhere other than a trusted root, the browser shows a certificate error and refuses to proceed.
The Classic Failure: An Incomplete Chain
Here is the bug that catches almost everyone at some point. A site's certificate "works fine in my browser" but a mobile app, a payment integration, or a command-line tool reports it as untrusted. The cause is nearly always a missing intermediate: the server was configured to send only the leaf certificate, not the intermediate that bridges it to the root.
Why does the browser not complain? Because browsers are forgiving — they cache intermediates seen on previous visits and can sometimes fetch a missing one automatically, quietly papering over the gap. Stricter clients do no such thing; they see a leaf with nothing connecting it to a trusted root and reject it outright. The connection was never actually complete; the browser just hid it. The fix is always the same: configure the server to present the full chain — leaf plus all intermediates — so every client can build the path on its own. Note what the server does not send: the root. The client already has the root in its trust store, and a root is trusted because it is pre-installed, not because a server offered it.
Frequently Asked Questions
What is a certificate chain?
The ordered sequence of certificates linking a website's certificate back to a trusted root. It usually has three links — the leaf for the site, one or more intermediates, and a root held by a certificate authority. Each certificate is signed by the one above it, forming a verifiable chain of trust.
What is the difference between a root and an intermediate certificate?
A root belongs to a CA and is pre-installed in browser and OS trust stores, so it is trusted directly. An intermediate is signed by the root and used to sign website certificates, letting the root key stay offline. The intermediate sits between the trusted root and the site's leaf.
Why does my certificate work in a browser but fail elsewhere?
Almost always a missing intermediate. Browsers cache intermediates and can fetch missing ones, hiding the gap; stricter clients like apps and command-line tools cannot, so they reject the certificate. The fix is to configure the server to send the full chain — leaf plus intermediates.
How does a browser validate a certificate chain?
It starts at the leaf and checks each certificate was signed by the next one up, following the chain until it reaches a root in its trust store. It also verifies each certificate is unexpired, not revoked, and that the leaf's name matches the site. If every link checks out at a trusted root, the connection is trusted.
Do servers send the root certificate?
No — and they should not. The server sends its leaf and the intermediates needed to reach the root, but not the root itself. The client already has the root in its trust store, so sending it adds nothing; a root is trusted because it is pre-installed.