how/network

HTTPS: verifying the certificate chain

How does the browser "know" that example.com is real? A chain of signatures from the leaf cert through the intermediate up to the root, which is already built into the OS.

In the TLS handshake the server sends a certificate: a public key plus a signature. But why should you trust that certificate at all? What if an attacker just makes their own certificate with CN=example.com?

The protection is a chain of signatures. The server's certificate is signed by an intermediate CA (Certificate Authority), that one is signed by a root CA, and the root is already built into the OS/browser during development. This chain of trust is what stops an attacker from forging anything without the private key of some CA.

On every HTTPS connection the browser runs 5 checks before it shows HTTPS. Press ▶ to see which ones.

step 1/7·00 · the server sent the chain, time to verify

§ steps

In the Certificate message (part of the TLS handshake) the server sends its own leaf certificate + intermediates (if any). The browser gets this stack and must make sure that:
1. The leaf cert is honestly signed by the intermediate
2. The intermediate is honestly signed by the root
3. The root is known to the OS (it is in the trust store)
4. The certificate has not expired
5. The name in the certificate matches what we are connecting to
If even one check fails, you get a big red warning and a block by default.

recap

What to remember:

A Root CA is a "trust anchor". There are about 150 of them in the standard OS trust store. If you trust them, you transitively trust everyone whose certificate they signed
A CA issues certificates only for limited domains: you get a leaf cert for your domain, not for "the whole internet". Signing something for someone else's domain is a violation, the CA revokes the certificate and loses its license (this is rare, but it happens)
Self-signed certificates are a leaf cert that is its own root. The signatures check out, but "nobody knows" this root, so the browser complains "not trusted". You can add it to the trust store manually (for localhost, an internal CA)
Let's Encrypt is a free CA that issues certificates automatically over the ACME protocol. It now sits on ~50% of all HTTPS sites in the world
If you want to poke at it by hand, openssl s_client -connect example.com:443 shows the whole chain, or openssl x509 -in cert.pem -text parses a single certificate
In mTLS (mutual TLS) the client also sends its certificate, and the server verifies it with the same logic. Used in a service mesh, in internal APIs, for machine-to-machine

Related to [[tls-handshake|TLS handshake]] (the handshake that triggers this check). Without the cert chain an encrypted channel would still be possible, but server authentication would not.

§ dig into the knowledge base

§ try it hands-on

intermediate-09-tls-handshake- TLS: look at a pcap by hand

§ steps

In the Certificate message (part of the TLS handshake) the server sends its own leaf certificate + intermediates (if any). The browser gets this stack and must make sure that:

The leaf cert is honestly signed by the intermediate
The intermediate is honestly signed by the root
The root is known to the OS (it is in the trust store)
The certificate has not expired
The name in the certificate matches what we are connecting to

If even one check fails, you get a big red warning and a block by default.