TL;DR: Browsers don’t trust your TLS certificate on its own. They trust a few dozen “root” certificates pre-installed in the operating system. Those roots sign “intermediate” certificates, intermediates sign your “leaf” certificate, and the browser walks that chain on every connection. Get the chain right and nobody thinks about it. Get it wrong and mobile clients break, API calls fail, and a single CA going bad can take thousands of sites down with it.

What is it?

The web runs on Public Key Infrastructure (PKI) — a fancy name for a simple idea: nobody can vouch for everyone, so we let a small number of trusted parties vouch for everyone else, and we layer the vouching.

There are three kinds of certificates in the chain:

  • Root certificates. A few dozen of them, baked into Windows, macOS, iOS, Android, and the browsers themselves at install time. Their private keys live in hardware security modules in physical vaults — sometimes literally air-gapped rooms — and are used as rarely as possible. A root might sign a few certs a year.
  • Intermediate certificates. Signed by a root. These are the workhorses. Mainstream CAs like Let’s Encrypt, DigiCert, and Google Trust Services rotate intermediates every couple of years and use them to sign millions of customer certs.
  • Leaf certificates. Signed by an intermediate. This is what your web server actually presents during the TLS handshake. It identifies your specific domain (yourdomain.com) and is good for, at most, a few months.

The hierarchy exists for one big reason: the root keys are too valuable to use day-to-day. If a root key ever leaks, every device in the world has to be updated to remove that root from its trust store — a process that takes years for old phones, IoT devices, and embedded systems. So roots stay offline, sign a small number of intermediates, and let the intermediates do the daily work. If an intermediate gets compromised, the CA can revoke just that intermediate without burning the root.

A real chain looks like this:

your cert  →  Let's Encrypt R3  →  ISRG Root X1  →  in OS trust store
  (leaf)        (intermediate)        (root)

Validating “this is yourdomain.com” means walking that chain from the leaf up until you hit something the OS already trusts.

Why does it matter?

When the chain works, you don’t think about it. The little padlock appears, the page loads, nobody calls support. That’s the goal.

When the chain doesn’t work, three things happen, and they all hurt at once:

Mobile and API clients fail first. Desktop browsers tend to be generous — Chrome and Firefox will sometimes patch over a broken chain by fetching missing intermediates themselves. Mobile browsers and non-browser clients (curl, mobile apps, server-to-server API calls, IoT devices) usually won’t. So an incomplete chain often shows up as “site works in Chrome but our iOS app can’t log in” or “webhooks from Stripe started failing.” Hard to debug if you don’t know where to look.

Retroactive distrust events. Browser vendors sometimes decide a CA can no longer be trusted, and they remove its root from the trust store in a future browser update. Every cert in that CA’s chain stops working overnight, even if the cert itself is fine. This has happened before, more than once:

  • Symantec / RapidSSL (2018). Google and Mozilla phased out trust in Symantec’s roots over 2017–2018 after a series of mis-issuances. Symantec sold its CA business to DigiCert, which re-issued affected certs — but operators who didn’t migrate in time saw their sites break in Chrome 70.
  • WoSign / StartCom (2016). Mozilla and Apple distrusted these CAs after they were caught back-dating certs to evade a SHA-1 deadline. Thousands of sites had to scramble for a new CA.
  • DigiNotar (2011). A Dutch CA was breached and used to issue fraudulent Google certs targeting Iranian users. Browsers pulled DigiNotar’s root within weeks. The Dutch government had used DigiNotar for half its public services; whole agencies went dark.

The takeaway: you don’t fully control your cert’s trustworthiness. You inherit it from the CA you picked. Picking a serious CA matters, which is exactly what WEBQ-97 grades.

Weak crypto in the chain. A leaf cert might be perfectly modern (ECDSA, 2048-bit RSA) but be signed by an intermediate that’s still using SHA-1 or a 1024-bit RSA key. Modern browsers refuse the whole chain in that case. The chain is only as strong as its weakest link — literally.

Real-world analogy

Picture an international notarized document.

You sign a contract in your own handwriting. That’s your leaf cert. Anyone who recognizes your handwriting can verify it’s you — but strangers can’t.

A notary in your city stamps the document confirming it’s really you. That’s the intermediate. The notary’s stamp is recognized by every notary in the country, but a foreign government doesn’t necessarily know your specific notary.

The country’s seal appears at the top of the notary’s authorization — the apostille. That’s the root. Foreign governments have a list of country seals they recognize. They don’t know your specific notary in your specific city, but they know the country, the country knows the notary, and the notary knows you.

A foreign official reading your contract walks the chain backwards: country seal (do I recognize this?) → notary stamp (does the country vouch for this notary?) → your signature (does the notary vouch for this person?). If any link is missing or forged, the document is worthless. If every link checks out, your handwritten signature is suddenly meaningful 6,000 miles away.

That’s exactly what a browser does on every HTTPS connection.

How a browser actually verifies a cert

The handshake walk is more interesting than it sounds:

  1. Browser receives the certs. Your server should send the leaf plus every intermediate in between (but not the root — the browser already has it). This part is just bytes over the wire.
  2. Browser parses the leaf. It reads the leaf’s “Issuer” field, which names the intermediate that signed it.
  3. Browser looks for that issuer. First in the certs your server sent. If it’s not there, the browser checks its own cache, then tries to fetch it via the leaf’s “Authority Information Access” (AIA) extension — a URL pointing to the missing intermediate. AIA fetching is a fallback, not a guarantee, and not all clients do it.
  4. Browser verifies the signature. Using the intermediate’s public key, the browser checks the math on the leaf’s signature. Then it does the same thing one level up: read the intermediate’s issuer, find that cert, verify the signature.
  5. Browser stops when it hits a root in its trust store. That’s the win condition. The chain is valid.

In the real world, path-building is genuinely complex engineering. A single intermediate might be cross-signed by multiple roots — meaning there are several valid paths to several trust anchors, and the browser has to pick one. ISRG (Let’s Encrypt’s parent) was cross-signed by IdenTrust for years so older Android devices that didn’t have the ISRG root yet could still trust Let’s Encrypt certs. When a chain has multiple possible paths, different clients can build different paths, and a chain that works in Chrome can fail on a 7-year-old Android phone.

Three things that go wrong in the real world

Incomplete chains. Your server sends only the leaf and forgets the intermediates. Modern Chrome will paper over this with AIA fetching; a Java HTTP client from 2018 will throw a SunCertPathBuilderException and your CI pipeline turns red. This is what WEBQ-90 — certificate chain completeness catches.

Expired or revoked certs. Certs are valid for a fixed window, and CAs can pull them back early if the private key leaks or the domain changes hands. An expired leaf is the classic outage that takes down a Fortune 500 site for an afternoon every few years. Revocation is harder to detect in real time — that’s what OCSP stapling solves, covered in OCSP stapling, explained.

Weak signatures. A cert in the chain (leaf, intermediate, or even cross-sign) uses a deprecated algorithm: SHA-1, MD5, or an RSA key shorter than 2048 bits. Modern browsers reject the whole chain. This is what WEBQ-89 — certificate key strength and signature algorithm grades.

Three factors in the WQI security category map directly to chain of trust:

Together those three answer: “is the chain modern, complete, and rooted in a CA the world still trusts?” If yes, you’re done.

Further reading