Trust one root, and you can verify a stranger's identity by following signatures up the chain.
When your browser connects to a server, the server presents a certificate that binds its public key to its name (e.g. shop.example). You don't trust that certificate directly — you verify it was signed by an intermediate CA, whose certificate was signed by a root CA that your device already trusts.
Each link is checked by verifying a digital signature with the issuer's public key, plus the validity dates, the name match, and revocation. Trust flows down from a small set of pre-installed roots: anchor the chain to one of them and a complete stranger becomes verifiable.
Start at the leaf the server sent and climb. At each link, verify the certificate's signature with the issuer's public key, confirm the clock is inside the validity window, and (at the leaf) confirm the host name matches. Stop when you reach a certificate already in the device trust store.
def verify_chain(leaf, intermediates, trust_store, host, now):
cur = leaf
pool = [leaf] + intermediates
while True:
issuer = find_issuer(cur, pool, trust_store)
if issuer is None:
return False # no path to an anchor
if not verify_sig(cur, issuer.pubkey): # signed by this issuer?
return False
if not (cur.not_before <= now <= cur.not_after):
return False # expired / not yet valid
if revoked(cur): # OCSP / CRL
return False
if cur is leaf and not name_matches(cur.subject, host):
return False # wrong name = refuse
if issuer in trust_store:
return True # anchored to a trusted root
cur = issuer # climb one link
| Operation | Work | Why |
|---|---|---|
| Walk the chain | O(chain length) | Typically 2–3 links: one signature check per hop |
| Trust-store lookup | O(1) | Small, pre-distributed set of roots on the device |
| Validity + name check | O(1) | Compare dates to the clock, match host to subject |
| Revocation check | 1 network call | OCSP / CRL is the slow, network-y part (often stapled) |
shop.example presents its leaf plus the Acme Intermediate certificate. The browser verifies the leaf was signed by Acme Intermediate, confirms the dates are valid and the name matches shop.example, then verifies the intermediate was signed by Acme Root. Acme Root is already in the OS trust store → the chain is anchored and the handshake proceeds.
Now the contrast: an attacker presents a certificate with a flawless signature chain to a trusted root — but its subject is evil.test while you asked for shop.example. Name mismatch → the connection is refused, no matter how clean the chain.
A presented certificate has a perfect signature chain all the way to a trusted root. But its subject is bank.test and you connected to shop.example. Accept the connection?
Coach note: if this didn't click yet, press "Reset & break it" and watch where the walk stops — a good chain to the wrong name is still the wrong name.