Certificate chains in PKI

Trust one root, and you can verify a stranger's identity by following signatures up the chain.

The idea

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.

See it work

Press play to walk the chain: start at the leaf the server sent and climb to a trusted root.

How it works

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

Cost

OperationWorkWhy
Walk the chainO(chain length)Typically 2–3 links: one signature check per hop
Trust-store lookupO(1)Small, pre-distributed set of roots on the device
Validity + name checkO(1)Compare dates to the clock, match host to subject
Revocation check1 network callOCSP / CRL is the slow, network-y part (often stapled)

Watch out for

Worked example

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.

Check yourself

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.