Certificates
Trust that scales — a signature vouching for a signature.
What it does
Signatures left one question open. A signature proves a message came from the holder of a particular key — but how do you know that key belongs to saltworks.dev and not an impostor who generated their own? You've never met the server. You can't have exchanged keys in advance.
A certificate is the answer: a signed statement that says “this name owns this public key,” vouched for by someone you already trust. Stack those statements into a chain and you get public-key infrastructure — trust that scales to every server on the internet.
The chain of trust
Trust is delegated, in three links:
- Root CAs sit at the top. A few dozen of them are trusted by default — their keys ship inside your browser and operating system. They are guarded obsessively and used rarely.
- Intermediate CAs are signed by a root. (“I vouch for them.”) They do the day-to-day work, so the precious root key can stay offline in a vault.
- The leaf is the server's own certificate, signed by an intermediate. (“And I vouch for
saltworks.dev.”)
Verifying a site means walking that chain upward — checking each signature against the key above it — until you reach a root you already trust. No trusted root at the end, or any broken link along the way, and the certificate is rejected.
Walk it — then break a link
The chain below is real: three ECDSA key pairs, each certificate genuinely signed by the one above it, all verified in your browser. It starts valid. Inject a flaw and watch exactly where, and why, the verification fails:
Each flaw fails differently. A swapped key breaks the leaf's signature, because it no longer covers the key being presented. A broken signature fails at that exact link. An untrusted root is the subtle one: every signature is mathematically valid, yet the chain is still rejected — because a self-signed certificate proves nothing unless its root is one your browser was told to trust. Anyone can mint a root; the trust store is what makes a handful of them special.
Why a chain, instead of trusting every key?
Two reasons. Scale: nobody could ship a list of every server's key, so trust is delegated down from a small, fixed set of roots. Safety: the high-value root keys stay offline and almost never sign anything, while disposable intermediates do the daily issuing — and can be revoked and replaced without reshipping every browser on earth.
The padlock means private, not honest
A valid certificate proves you're really talking to the domain in the address bar, over an encrypted channel — nothing more. A phishing site at saltw0rks.dev can hold a perfectly valid certificate for that name. The chain authenticates the connection, not the character of whoever's on the other end. Read the name, not just the lock.
What it's for
- HTTPS — this chain is the Certificate step of the TLS handshake. It's what lets your browser trust a server it's never met.
- Code & document signing — the same PKI proves software updates and signed PDFs come from who they claim.
- Mutual TLS & device identity — certificates also identify clients: services, devices, and employees authenticating to each other inside a network.