Certificates & the Chain of Trust

In the handshake, the server proves its identity with a certificate. But why should your browser believe it? The answer is a chain of trust.

Anatomy of a certificate

A certificate is a signed document with fields like:

• Common Name (CN), the primary domain it is issued for.
• SAN (Subject Alternative Name), the full list of valid domains (modern browsers rely on this).
• Expiry date, certificates are deliberately short-lived.
• Issuer, who vouched for it.

Inspect a real certificate

Here is a leaf certificate dumped with openssl x509 -noout -text. Read it like a tester: who is it for, who issued it, when does it expire, and which names are valid?

Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number: 04:a2:9f:1c:8e:55:6b:d0
        Signature Algorithm: sha256WithRSAEncryption
        Issuer: C=US, O=Let's Encrypt, CN=R3
        Validity
            Not Before: Mar  1 00:00:00 2026 GMT
            Not After : May 30 23:59:59 2026 GMT
        Subject: CN=shop.example.com
        Subject Public Key Info:
            Public Key Algorithm: rsaEncryption
                Public-Key: (2048 bit)
        X509v3 extensions:
            X509v3 Subject Alternative Name:
                DNS:shop.example.com, DNS:www.shop.example.com
            X509v3 Extended Key Usage:
                TLS Web Server Authentication
    Signature Algorithm: sha256WithRSAEncryption

• Subject is who the cert is for, here shop.example.com.
• Issuer is who signed it, here Let's Encrypt's intermediate, R3.
• Validity is the Not Before / Not After window, outside it, browsers reject the cert.
• SAN lists every hostname the cert is valid for. www.shop.example.com is covered; api.shop.example.com would not be.

The chain of trust

No single certificate is trusted on its own, trust is delegated down a chain:

• Root CA, a small set of authorities your browser ships with and trusts implicitly. The Root uses its private key to sign an Intermediate.
• Intermediate CA, now authorised to issue certificates to everyday websites on behalf of the Root. This keeps the precious Root key offline.
• Leaf certificate, the website's own certificate, presented during the handshake.

Your browser checks each signature up the chain until it reaches a Root it already trusts. If every link verifies, you get the padlock.

Common failures

Misissuance / validation failures, the browser warns and (rightly) scares the user:

• Expired certificate, past its expiry date.
• SAN mismatch, the name you visited is not listed in the certificate.
• Untrusted issuer, the chain does not lead to a known Root.

Pinning failures, certificate pinning means an app hard-codes the exact certificate (or public key) it expects, instead of trusting any valid CA. Apps do this when they do not fully trust the CA system. If the served certificate does not match the pinned one, the app refuses to connect, even if a CA says it is valid.

Behind the scenes

Creating a CA is just key generation and self-signing, the same primitives, used to issue trust rather than consume it:

openssl genrsa -out ca.key.pem 4096
openssl req -x509 -new -nodes -key ca.key.pem -sha256 -days 3650 -out ca.cert.pem
openssl x509 -in ca.cert.pem -noout -text

Takeaway

A certificate states identity; the chain of trust (Root → Intermediate → Leaf) is why you believe it. Most TLS warnings come down to a broken link in that chain: expired, wrong name, or unknown issuer.