Who Said You Could Trust That?¶

You typed a domain into your browser. A stranger's server answered. Your browser believed it — drew the little padlock, decrypted nothing of yours into the wrong hands, and let you type your password.

Why?

You've never met whoever runs that server. You have no way to recognize them. And yet your machine handed over a trust decision to a computer it had never spoken to before, and got it right. That isn't luck, and it isn't magic. It's a chain of vouching — a social structure that happens to be enforced with math.

This section is about that structure. Not the math. The structure.

So we're not going to teach you cryptography. We're going to teach you trust: who vouches for whom, why a browser believes a stranger, and what happens when one link in that chain of vouching goes stale.

Why this isn't "Cryptography for Developers"¶

Because the name promises a textbook, and the textbook is the wrong thing to hand you.

A course called "Cryptography for Developers" braces you for modular arithmetic, elliptic curves, and a quiz on AES modes. Then it teaches you to implement the thing you should never implement. You walk away feeling dumb about a skill you were never supposed to have, and no better at the decisions you actually face.

The thing you actually lack isn't crypto. It's a working model of trust. So that's what we build — outside-in, starting from the question you already have, introducing a primitive only when the story can't continue without it. By the time the word "asymmetric" shows up, you'll already understand why it has to exist.

Trust is vouching¶

Start with the package you already trust: your operating system, or your browser, ships with a list of a few dozen organizations it has decided to believe. These are Certificate Authorities — CAs. Apple, Microsoft, Mozilla, Google, and a handful of others curate these lists. You inherited that decision the day you installed the OS. You almost certainly never looked at it.

A certificate is just a notarized claim. It says, in effect:

"I, a CA you already trust, vouch that this public key belongs to example.com, and this vouching is good until March 2027."

That's it. A cert is a signed statement: this key belongs to this name, until this date. Nothing more mystical than a notary stamping a document — except the notary is a CA your browser already trusts, and the stamp is a signature your browser can check.

When example.com's server answers your browser, it hands over this certificate. Your browser reads the claim, checks who signed it, confirms the signer is on its trusted list, confirms the date hasn't passed, and — satisfied that someone it trusts is vouching — proceeds.

The chain: who vouches for the voucher¶

Here's the wrinkle. A CA does not sign your website's certificate with the same key it put in your browser. That root key is too precious to expose to daily use — if it leaked, every cert it ever signed would be suspect. So the root stays in a vault, almost offline, and signs exactly one kind of thing: intermediate certificates.

The intermediate then signs the leaf — your actual website cert.

Root CA          ← in your browser's trust store, lives in a vault
  └─ signs →  Intermediate CA   ← does the day-to-day signing
                  └─ signs →  Leaf cert   ← example.com, what the server hands you

So when your browser validates example.com, it doesn't check one signature. It walks the chain:

• The leaf says "trust me, the intermediate signed me."
• The intermediate says "trust me, the root signed me."
• The root is already in the browser's trust store — the chain terminates in something the browser decided to believe long ago.

This is the chain of trust, and it is the single most important idea in this section. Trust isn't a property of one certificate. It's a path — from a stranger's server, link by link, back to a root your machine already trusts. Break any link and the whole path fails: an expired intermediate, a leaf signed by a CA nobody trusts, a missing link the server forgot to send. "Certificate errors" are almost always a broken chain, not a broken cert.

The one primitive you can't skip¶

Now — and only now — the crypto. One paragraph. This is the entire math budget for this page.

A keypair is two numbers, mathematically linked: a private key you keep secret, and a public key you hand out freely. The link between them does two useful things:

• Anything encrypted with the public key can only be decrypted with the private key. (Secrecy.)
• Anything signed with the private key can be verified by anyone holding the public key. (Proof of possession.)

That second one is the whole game for certificates. A signature proves you possess a secret without revealing the secret. When a CA "signs" your cert, it uses its private key; when your browser "checks the signature," it uses the CA's public key — which it has, because it's baked into the trust store. The signature can't be forged without the CA's private key, and that key is in a vault. That's why the vouching means something.

That's all the cryptography you need to read the rest of this section. If you want more — how the keys are actually generated, why factoring large numbers matters, what elliptic curves buy you — that's a genuinely interesting rabbit hole, and it lives on the Crypto You'll Actually Call page as opt-in depth. It is never load-bearing for understanding trust.

Getting a cert is a separate problem¶

Here's where most people drown, and it's because two genuinely different questions get mashed into one.

1. What is a certificate? — answered above: a signed claim, validated by walking a chain.
2. How do I get one? — a completely different problem, and the one you'll actually wrestle with in practice.

To issue you a cert for example.com, a CA has to answer exactly one question first: do you actually control example.com? It would be a catastrophe to hand a cert for yourbank.com to whoever asked. So before signing, the CA demands proof of control. This is domain validation, and the modern, automated version of it is the ACME protocol (what Let's Encrypt, CertiNext, and most ACME clients speak).

The proof comes in two flavors, and choosing between them is a decision, not a protocol detail. The question is always the same: which thing do you actually control?

That single reframe — which thing do you actually control, the box or the zone? — dissolves the whole "HTTP-01 vs DNS-01, which do I want??" morass. If you're issuing certs on the fly for user-selected subdomains (say, a platform that hands each user their-name.example.com), DNS-01 with a wildcard or programmatic per-name issuance is almost always the answer, because you can't predict the names in advance and you may not have a public box answering for each one. The mechanics of how ACME orchestrates this — the challenge dance, automated renewal, what happens on failure — live on the ACME and Automated Issuance page.

The lesson that ties it to everything else¶

Every certificate carries an expiry. That isn't bureaucracy — it's the load-bearing safety feature. A cert that never expired would be a vouching that could never be revoked cleanly; expiry forces the trust to be renewed, which means it's continuously re-checked instead of granted once and forgotten.

Which leads to the two rules worth pinning above your desk:

That second rule is the whole bridge to the rest of the guide. The detonator pattern says don't trust external input. The trust-boundary lessons say audit what your trusted components trust. This section says know what your code trusts — and when that trust expires. Three legs of the same stool.

Where to go deeper¶

This page is the spine. The pages below exist because some of you are building real systems on top of this trust structure right now — issuing certs on the fly, deciding whether to pin, wiring up service-to-service auth — and you need to confirm or challenge assumptions you've carried for years. They're being built out; each is opt-in depth, never required to understand the spine above.