Certificate Authorities
Chapter 4 said a certificate is trustworthy because a Certificate Authority signed it. But that just moves the question: why trust the CA? This chapter answers it by following the chain all the way up to its anchor — and explains the one thing your device actually has to trust to begin with.
The Bootstrapping Problem
A certificate's signature is only as good as your trust in whoever signed it. If you have to verify the signer with another certificate, and that one with another, the chain has to stop somewhere — otherwise it's turtles all the way down. The chain stops at a root certificate that your device trusts inherently, not because something else vouched for it.
Three Tiers: Root, Intermediate, Leaf
Real-world certificates form a chain of (usually) three levels. Each certificate is signed by the one above it:
| Tier | Signed by | Role |
|---|---|---|
| Root CA | itself (self-signed) | the trust anchor; lives in the trust store; key guarded offline |
| Intermediate CA | the root (or another intermediate) | issues leaf certs daily, shielding the root key from exposure |
| Leaf / end-entity | an intermediate | the actual certificate for a website's domain |
How Verification Walks the Chain
When your browser receives the server's certificate, it builds and verifies the chain link by link. The server is expected to send its leaf cert plus the intermediate(s) — but not the root, which the client already has:
At each step the browser also re-checks everything from Chapter 4: validity dates, that the issuer's certificate is allowed to act as a CA, and (at the leaf) that the SAN matches the site. The chain is only trusted if every link verifies and it terminates at a root in the trust store.
What a CA Actually Verifies (and Doesn't)
Before issuing a leaf certificate, a CA validates the request — but how much it checks defines the validation level:
| Level | What the CA verifies | Used for |
|---|---|---|
| DV (Domain Validation) | only that you control the domain (Chapter 9) | the vast majority of sites; free via Let's Encrypt |
| OV (Organization Validation) | domain control + the organization's real existence | business sites wanting vetted identity |
| EV (Extended Validation) | a rigorous legal-identity check | once gave the "green bar"; now visually de-emphasized |
Crucially, even the strictest level only verifies identity, never honesty. A DV certificate proves "the holder controls this domain" — nothing about whether the site is safe. This is the Chapter 1 point made concrete: the chain of trust authenticates who you're talking to, not whether they deserve your trust.
yourbank.com to someone who doesn't control that domain. It is not an endorsement of any site the CA issues to. This is also why a single misbehaving CA is dangerous: a CA that wrongly issues a cert for a domain it shouldn't can enable impersonation of that site — which is what Certificate Transparency (Chapter 12) exists to catch.
Self-Signed Certificates
A self-signed certificate is its own issuer (Subject = Issuer) with no chain to a trusted root — exactly what a root CA is, except nobody pre-trusts yours. Browsers reject it with a warning because it provides encryption but no third-party-verified authentication. They're fine for local development and internal testing (where you control both ends), but never for the public web. You can create one in a single command, which the exercises explore.
Hands-On Exercises
Use openssl s_client -connect ... -showcerts to dump the full chain a server sends, and identify each certificate's Subject and Issuer. Confirm the leaf's Issuer equals the intermediate's Subject (the links match up), and note whether the root is included in what the server sent.
Generate a self-signed certificate with a single openssl req -x509 command, inspect it to confirm Subject == Issuer, and explain in your own words exactly why a browser refuses to trust it even though the connection it provides is fully encrypted.
Find your system/browser trust store (list the installed root CAs), and reason through two scenarios: (a) a company installs its own root CA on employee laptops to inspect traffic — why does that work and what does it imply; (b) a server omits its intermediate cert — why do some clients succeed while others fail?
📄 View solutionChapter 5 Quick Reference
- Trust must bottom out somewhere — at a root certificate trusted inherently, not via another signature
- The trust store (root store) is the pre-shipped list of root CAs your OS/browser trusts by default
- Three tiers: Root (self-signed, offline) → Intermediate (daily issuing) → Leaf (the site's cert)
- Intermediates exist to keep the root key offline and make compromise recoverable without re-shipping trust stores
- Verification walks the chain: each cert's signature checked with the issuer's key, ending at a trusted root
- Server must send leaf + intermediates (not the root) — a missing intermediate is the #1 setup bug
- Validation levels: DV (domain control) / OV (org) / EV (legal identity) — all verify identity, not honesty
- Self-signed cert = its own issuer, no trusted chain → browser warning; fine for local dev only
- Next chapter: the TLS 1.2 handshake — putting keys, certs, and the chain together step by step