Certificate Chains

Your browser has never met this server before. It's presenting a certificate claiming to be amazon.com. Why should your browser believe it?

Because someone your browser does trust vouched for it. And someone vouched for them. This chain of vouching—each link cryptographically signed—is the certificate chain. Understanding it reveals how trust actually works on the Internet.

The Three Levels of Trust

A certificate chain typically has three levels:

Root Certificate: Pre-installed in your browser or operating system. Your browser trusts this certificate because the browser vendor decided to trust it—Mozilla, Apple, or Microsoft evaluated the Certificate Authority's practices and added their root to the trust store. This is where trust begins.

Intermediate Certificate: Signed by the root CA. This certificate can sign other certificates. It's the workhorse of the PKI system.

End-Entity Certificate: The actual certificate for amazon.com or your website. Signed by the intermediate. This is what the server presents.

Each certificate vouches for the one below it through a digital signature. The root vouches for the intermediate. The intermediate vouches for the end-entity. Your browser walks this chain backward until it reaches a root it trusts.

Why Not Just Use the Root Directly?

Why this complexity? Why doesn't the root CA just sign every website certificate?

Because a root CA's private key is extraordinarily valuable. If it's compromised, every certificate ever signed by that root becomes suspect. Browsers would remove the root from their trust stores—catastrophic for the CA and every site using their certificates.

So root keys are kept in air-gapped vaults. Some require multiple people with separate credentials to access, like launching nuclear missiles. A root key might sign certificates only a few times per decade—just often enough to create new intermediates.

Intermediates handle daily operations. They live on online systems that issue thousands of certificates per day. If an intermediate is compromised, you revoke that one intermediate. The root stays trusted. The CA issues a new intermediate. Life continues.

This is defense in depth applied to cryptographic trust.

How Verification Actually Works

When you connect to https://example.com, the server sends its certificate plus any intermediates. Your browser then:

1. Looks at the end-entity certificate and extracts who signed it (the Issuer field)
2. Finds that certificate in what the server sent (the intermediate)
3. Verifies the signature using the intermediate's public key—this proves the intermediate really did sign the end-entity certificate
4. Repeats: who signed the intermediate?
5. Keeps going until it finds a certificate that signed itself (self-signed) and is in the browser's trust store

If every signature checks out and the chain ends at a trusted root, the connection proceeds. If anything fails—bad signature, missing intermediate, unknown root—the browser rejects the connection.

The Incomplete Chain Problem

Here's where things go wrong in practice: servers must send the complete chain. Not just their certificate—all the intermediates too.

The root isn't sent because browsers already have it. But intermediates? The browser has no idea which intermediates exist. The server must provide them.

When a server sends only its end-entity certificate without intermediates, the browser can't verify the chain. Some desktop browsers try to download missing intermediates (slow, unreliable, and a privacy leak). Mobile browsers often just fail.

This is one of the most common TLS misconfigurations. The site works in Chrome on your laptop (which cached the intermediate from a previous visit) but fails on a customer's iPhone. Debugging this without understanding chains is maddening.

Configuring It Right

When you get a certificate from a CA, they provide two things: your certificate and the intermediate certificates (sometimes called a "chain file" or "CA bundle").

Your server needs both. The configuration depends on your server:

Nginx: Concatenate them into one file, your certificate first:

cat your-cert.pem intermediate.pem > fullchain.pem

Apache: Either concatenate like Nginx, or configure separate SSLCertificateFile and SSLCertificateChainFile directives.

The order matters. End-entity first, then intermediates in sequence toward the root. Wrong order breaks chain building.

Testing Your Chain

After installing a certificate, verify the chain is complete:

SSL Labs (ssllabs.com/ssltest): The gold standard. It checks your chain, identifies missing intermediates, and shows exactly what's being sent.

OpenSSL from command line:

openssl s_client -connect example.com:443 -showcerts

Count the certificate blocks. You should see your end-entity certificate plus all intermediates.

Multiple browsers: Test in Chrome, Firefox, Safari, and on mobile devices. Chain-building behavior varies.

Don't just test from your office network. Test from a fresh browser that hasn't cached any intermediates.

Cross-Signing: Multiple Paths to Trust

Sometimes there's more than one valid chain from a certificate to a trusted root.

This happens through cross-signing. When a new CA establishes itself, browsers don't yet have their root. So an established CA signs the new CA's intermediate with their existing root. Now there are two paths: one through the new root (for browsers that have it) and one through the old root (for browsers that don't).

Let's Encrypt used this strategy extensively. Their certificates could chain to their own ISRG Root or to IdenTrust's DST Root CA X3, ensuring compatibility with older devices.

When multiple paths exist, send the chain most likely to work everywhere—usually the one ending at the oldest, most widely-trusted root.

Common Failures

Missing intermediate: The server sends only the end-entity certificate. Some clients can work around this; many can't.

Expired intermediate: Your certificate is valid, but an intermediate in the chain expired. The whole chain fails.

Wrong order: Certificates sent out of sequence. Some clients can reorder them; others fail.

Untrusted root: The chain leads to a root the browser doesn't recognize. Common with private CAs or very new public CAs.

Chain too long: While rare, some systems reject chains deeper than 5-10 certificates. Keep chains short—most are just end-entity → intermediate → root.

The Deeper Pattern

Certificate chains are trust delegation made cryptographic. The browser vendors trust root CAs. Root CAs delegate trust to intermediates. Intermediates delegate trust to your website. Each delegation is a signature that can be mathematically verified.

This pattern—trust through vouching, verified through signatures, protected through isolation of high-value keys—appears throughout security engineering. Understanding it here means understanding it everywhere.