Why does HTTPS need certificates if encryption already works?

Encryption alone gets you a private channel — to whoever's on the other end. Certificates are how the browser decides that 'whoever' is the bank you meant to reach, not someone sitting in the middle pretending to be.

The picture version

Five pictures for a reader who has never wondered what the padlock checked. The prose below fills in the seams the pictures skip.

Why it exists

You’re in a café, on Wi-Fi named something like Free_Guest_2, and you open https://yourbank.com to check a balance. Padlock, no warning, page loads. You’ve done this a hundred times. But think about what your laptop just decided: on a network run by a stranger, it concluded that the machine answering was really the bank. Encryption can’t have told it that — a stranger’s router can encrypt too. That café connection to yourbank.com is the example this post follows.

Which raises the question that almost never gets answered cleanly: if TLS already does encryption, why do we also need this whole circus of certificates, certificate authorities, expiry dates, and the occasional Friday-night outage when one expires? Encryption is the hard math part. Why isn’t it enough?

The answer is the part the padlock icon never explains. Encryption gives you a private channel — to somebody. It does not, on its own, tell you who that somebody is. And on a network you don’t control (every coffee-shop Wi-Fi, every ISP, every airport hotspot), “who you’re actually talking to” is not a question you can wave away.

Back to the café. Your laptop opens a TCP connection that leaves through someone else’s router and crosses a dozen hops you’ve never heard of. At any one of those hops — starting with the router two metres away — someone could intercept the traffic, pretend to be the bank, do a key exchange with you, and separately do a key exchange with the real bank. Now there are two encrypted tunnels — laptop ↔ attacker, and attacker ↔ bank — and the attacker reads everything in cleartext in the middle. This is a man-in-the-middle attack, and pure encryption does nothing against it. You set up a private channel, beautifully — to the wrong person.

Certificates exist to answer the missing question: is the public key I’m about to encrypt to actually owned by yourbank.com, or by some hop in between?

Why it matters now

Every API call your service makes, every login, every OAuth redirect, every package install over https://, every model API call from your app to api.<provider>.com — all of them rest on the same trust step. If certificates didn’t exist, “encrypted” would mean “encrypted to whoever managed to reply first,” which is a near-useless guarantee on the open internet.

This is also why certificate-related outages are so spectacular when they happen: the entire web’s trust model funnels through a small set of CA operators and a clock. When a cert expires unnoticed, or a CA has an incident, the failure isn’t graceful — clients refuse to connect. The fragility is the price of having any meaningful identity guarantee at all.

The short answer

HTTPS = TLS encryption + certificate-based identity from a trusted CA

Picture to keep: a sealed tube between you and someone in the dark, plus an ID card that a notary your browser already knows has signed — and a live challenge that makes the person at the far end demonstrate the card is theirs and not a photocopy. The picture breaks where it matters most: the notary never met the person. It only checked that they controlled the address on the card.

Encryption builds a private tube between two endpoints. The certificate is the part that says which endpoint is on the other end of the tube — a signed statement, from a party your browser already trusts, that this public key really does belong to this domain name.

How it works

Start from the naive fix and let each failure force the next piece.

Naive attempt: the bank sends its public key, you encrypt to it. In the café this fails immediately — the router in the corner can strip the bank’s key out and substitute its own. You’d encrypt perfectly, to it. So the key needs to arrive with a statement about who it belongs to.

Fix: have someone sign that statement — but you have to already trust the signer. Your browser comes preloaded with the public keys of on the order of a hundred root CAs. The exact count is vendor-specific and moves as roots are added and distrusted, so it isn’t a number to memorise — what matters is that the set is small, curated, and chosen by whoever ships your browser. These are the trust anchors. Every other piece of trust on the public web is derived from them.

But signing every certificate directly with a root key would be reckless, so the trust gets chained. The root key is what everything else rests on, so you want it used rarely and kept offline. Intermediates let a CA delegate day-to-day issuance, scope it by policy, and retire a compromised intermediate without having to burn the root out of every browser on earth. When you connect to yourbank.com, the server sends you a certificate. A certificate is, roughly, a structured document saying “the public key 0xABC... belongs to the domain yourbank.com, valid between these dates,” signed by some intermediate CA. That intermediate CA’s own certificate is signed by another CA, and so on up to a root CA in your browser’s store. The browser walks the chain and verifies each signature along the way. If it terminates in a known root, the chain is trusted.

But certificates are public documents, so the café router can just replay one. This is the subtle bit, and the reason a certificate alone proves nothing: the attacker can copy the bank’s certificate file verbatim. What the attacker can’t do is prove they have the matching private key. During the TLS handshake, the server has to perform an operation that only the holder of the private key could do (a signature over handshake data, in modern TLS). That’s what ties the certificate to the actual party on the other end of this specific connection.

So the chain of reasoning the browser is doing is:

1. I trust this root CA (because it’s in my store).
2. That root signed this intermediate CA’s cert (signature checks out).
3. That intermediate signed this leaf cert for yourbank.com (signature checks out, dates valid, hostname matches).
4. The party on the other end of this TCP connection just proved they hold the private key for that leaf cert (handshake signature checks out).
5. Therefore the encrypted channel I’m about to use leads to whoever demonstrated control of yourbank.com to the CA.

Drop any one step and you’re back to “encrypted, to who knows.”

flowchart TD
    R[Root CA<br/>in browser's store — trusted by default] -->|signs| I[Intermediate CA cert]
    I -->|signs| L[Leaf cert<br/>'this key belongs to yourbank.com']
    L -.->|server proves it holds<br/>the matching private key| H[This TLS connection]

The solid arrows are signatures the browser verifies offline against keys it already has. The dashed arrow is the live step: only the holder of the leaf cert’s private key can complete the handshake, which is what binds the static certificate to this connection.

What CAs actually verify. A public CA like Let’s Encrypt does domain validation: they ask you to prove you control the domain (place this file at this URL, or set this DNS record). They are not certifying that you are a real company, that the site is honest, or that the operators are who they claim to be — only that whoever requested the cert demonstrably controlled the domain at request time. That’s a much narrower claim than people often assume — and narrower than the padlock icon ever managed to communicate, which is part of why Chrome eventually replaced it: it was consistently read as “this site is safe” rather than “this channel goes where it says.”

The seams. The whole system has known soft spots. Any trusted CA can, in principle, issue a cert for any domain — so the security of yourbank.com depends on every CA in your root store behaving and not getting compromised. Mechanisms like Certificate Transparency logs exist specifically because that assumption has failed in the past; they make misissuance detectable after the fact. And revocation — telling the world a previously-valid cert is now bad — has historically been the weakest part of the stack, with a tangle of mechanisms (CRLs, OCSP, OCSP stapling, short-lived certs) and no single clean answer — the industry never converged on one, which is itself the finding.

You started with HTTPS = TLS encryption + certificate-based identity from a trusted CA. What did the café walkthrough add? — + a live proof of private-key possession. The certificate is a public document anyone can copy; the only thing the router in the corner can’t fake is the handshake signature, and that single step is what turns “a private tube to somebody” into “a private tube to the bank.”

Famous related terms

• TLS handshake — TLS handshake = key exchange + cert verification + proof-of-private-key — the opening dance that both encrypts the channel and authenticates the server.
• Certificate Authority (CA) — CA = entity browsers trust + ability to sign certs for domains — the trust anchor the whole web hangs off.
• Let’s Encrypt — a free, automated CA whose existence collapsed “HTTPS is too expensive for small sites” as an excuse. It issues at very large scale, and it changed the economics for small sites permanently.
• Self-signed certificate — self-signed cert = cert + signed by its own key, no CA — encrypts fine, and authenticates nothing to a browser, because no chain leads to its root store. Inside a system where you distributed that cert out of band yourself, it can authenticate perfectly well.
• Certificate pinning — pinning = "for this domain, only accept this key/issuer" — an app narrows trust to a specific key or issuer rather than accepting the whole system CA list. Stronger guarantee, much more brittle when keys rotate.
• Certificate Transparency — CT = append-only logs + everyone can audit issued certs — turns a CA misbehaving from invisible into noisy.

Going deeper

• RFC 9846 (TLS 1.3, which obsoleted RFC 8446 in July 2026) — the primary source for the question “what exactly does the server sign to prove it holds the private key?”; the handshake section makes the binding step concrete.
• Let’s Encrypt, “How It Works” — the practical answer to “what does a CA actually check before issuing,” in the form the modern web mostly uses.
• The DigiNotar case (2011) — the rabbit hole for “what happens when a trusted CA is wrong?”, which is the fastest route to understanding why Certificate Transparency exists; the technical postmortems it links out to are the meat.