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.

Why it exists

Here’s 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.

Imagine you go to https://yourbank.com. Your laptop opens a TCP connection, which gets routed across a dozen hops you’ve never heard of. At any one of those hops, 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

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

The trick is a chain of signatures rooted in a list your operating system or browser ships with.

1. The root store. Your browser comes preloaded with the public keys of maybe a few dozen to ~150 root CAs (the exact number depends on the vendor and changes over time — I’m not going to pin a number I can’t currently verify). These are the trust anchors. Every other piece of trust on the public web is derived from them.

2. The certificate. 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.

3. The handshake binds the cert to this connection. This is the subtle bit. Just owning a certificate isn’t enough — an attacker could copy the bank’s public certificate file, it’s public. 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 the entity that the CA vouched owned yourbank.com.

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

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 it’s the only claim the green-padlock UI ever really meant.

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. I don’t have a strong claim on which mechanism currently dominates in practice in 2026.

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. Most of the modern web’s HTTPS coverage rides on this.
• Self-signed certificate — self-signed cert = cert + signed by its own key, no CA — encrypts fine, authenticates nothing, which is why browsers shout at you.
• Certificate pinning — an app hard-codes which cert(s) it’ll accept for a given domain, ignoring the system’s 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 8446 — TLS 1.3. Surprisingly readable for an RFC; the handshake section makes the cert-binding step concrete.
• The Let’s Encrypt “How It Works” page — the clearest short explanation of domain validation in practice.
• Any postmortem of a major CA incident (DigiNotar 2011 is the classic) — reading one is the fastest way to internalize why Certificate Transparency had to be invented.