Chain of Trust

When you connect to a website over HTTPS, your browser faces a fundamental question: how do I know this server is actually who it claims to be?

The answer is the chain of trust—a sequence of digital certificates where each one vouches for the next, leading from the website's certificate to a certificate authority your browser already trusts. It's the mechanism that makes Internet-scale encryption possible without requiring you to personally verify every website you visit.

The Architecture of Trust

A chain of trust typically has three levels:

End-entity certificates belong to websites, email servers, and other services. When you connect to a site, this is what you receive. It contains the server's public key and proves the server controls a particular domain.

Intermediate certificates sit in the middle. They're issued by root CAs and authorized to sign end-entity certificates. Most chains include one or two intermediates.

Root certificates are the trust anchors. They're self-signed—no one vouches for them. Instead, they're trusted because browser and operating system vendors explicitly decided to trust them. Your browser ships with a few hundred root certificates baked in, each representing an organization that has convinced browser vendors it can be trusted to only vouch for the truth.

This is the architecture of Internet trust: a few hundred organizations, vetted by browser vendors, authorized to issue certificates that your browser will believe.

How Verification Works

When your browser connects to an HTTPS site, the server sends its end-entity certificate plus any intermediates needed to complete the chain. (It doesn't send the root—your browser already has it.)

The browser then works backward:

1. Check the end-entity certificate's signature using the public key from the intermediate certificate. If the math checks out, the intermediate CA definitely signed this certificate.

2. Check the intermediate certificate's signature using the public key from the next certificate up—either another intermediate or the root.

3. Reach a trusted root. When the chain connects to a certificate in the browser's trust store, verification succeeds. The root is the anchor that makes everything below it trustworthy.

At each step, the browser also checks that certificates haven't expired, haven't been revoked, and are authorized to sign what they've signed.

Why Intermediates Exist

Why not just have root CAs sign every website certificate directly? Because root private keys are irreplaceable.

If a root CA's private key is compromised, every certificate it ever signed becomes suspect. The root must be removed from every browser's trust store—a catastrophic event that invalidates potentially millions of certificates overnight.

So root keys stay offline, locked in hardware security modules in physically secured facilities. They come out only to sign intermediate certificates, maybe a few times per year. The intermediates handle day-to-day certificate issuance from online systems.

This architecture contains damage. If an intermediate is compromised, you revoke just that intermediate. The root survives. The CA issues a new intermediate and continues operating. Painful, but not catastrophic.

When Chains Break

Chain verification can fail in several ways:

Missing intermediate. The server doesn't send a required intermediate certificate. Some browsers can work around this by fetching the intermediate from the Internet, but it's slow and unreliable. Many browsers—especially on mobile—simply fail.

Expired intermediate. Intermediates have expiration dates too. Even if your end-entity certificate is valid, an expired intermediate breaks the chain. This catches operators who forget that intermediates need renewal.

Untrusted root. The chain leads to a root certificate that isn't in the browser's trust store. This happens with private CAs or lesser-known public CAs.

Wrong order. The server sends certificates in the wrong sequence. End-entity must come first, then intermediates in order toward the root.

Constraints That Limit Damage

Intermediate certificates can include restrictions that limit what they're allowed to sign:

Name constraints restrict which domains an intermediate can issue certificates for. An intermediate constrained to *.example.com can only sign certificates for that domain and its subdomains. Even if that intermediate is compromised, the attacker can't issue certificates for other domains.

Basic constraints specify whether a certificate can sign other certificates at all. End-entity certificates are marked as non-CAs—they can't sign anything. The path length constraint limits how many more levels of intermediates can appear below this one.

These constraints provide defense in depth. A compromised intermediate with tight constraints is dangerous; a compromised intermediate with no constraints is catastrophic.

Cross-Signing: Multiple Paths to Trust

Sometimes the same intermediate certificate is signed by multiple root CAs. This cross-signing creates multiple valid paths from an end-entity certificate to different trusted roots.

Why do this? Compatibility. When a new root CA launches, older systems don't trust it yet. By having an established root cross-sign the new CA's intermediate, certificates can validate through the old root while the new root builds trust.

Browsers perform path building—exploring possible chains until they find one that reaches a trusted root. Good servers send the most compatible chain, but sophisticated browsers can sometimes find alternative paths.

Inspecting Chains

You can examine any site's certificate chain. Click the padlock in your browser's address bar and view certificate details. You'll see the complete chain from end-entity to root.

From the command line:

openssl s_client -connect example.com:443 -showcerts

This displays all certificates the server sends and attempts verification.

Online tools like SSL Labs' Server Test analyze chains in detail, catching missing intermediates, wrong ordering, and other configuration mistakes.

The Foundation

The chain of trust is how cryptographic verification scales to billions of devices and millions of websites. It's elegant in its simplicity: each certificate vouches for the next until you reach something you already trust.

But it's only as strong as its weakest link. A compromised intermediate, a misconfigured server, an expired certificate anywhere in the chain—and the whole thing fails. The browser shows a warning, the connection doesn't proceed, and trust isn't established.

That's the system working as designed. The chain exists precisely so that when something goes wrong, you find out immediately rather than trusting something you shouldn't.