HTTPS: Explanation & Insights

HTTP wrapped in a sealed envelope — private, untampered, and proven to be the right server.

What It Is

HTTPS is HTTP spoken inside an encrypted tunnel. That's the whole idea in one sentence: take the exact same request-and-response language the web already runs on — the GETs, the 200 OKs, the headers — and run it through TLS (Transport Layer Security) so that nobody between you and the server can read it, change it, or impersonate the far end. The "S" stands for Secure, and what it secures is the channel, not the content's correctness. Hold that thought; it's the muddy part everyone gets wrong, and we'll nail it below.

Concretely, HTTPS slides one layer between HTTP and the TCP connection it normally rides on. Your browser opens TCP to port 443 (instead of plain HTTP's port 80), performs a TLS handshake to establish a shared secret, and then sends ordinary HTTP through the now-encrypted pipe. The server reads it, answers in plain HTTP, and TLS encrypts the reply on the way back. Everything HTTP does still happens — the methods, the status codes, the cookies — it just happens behind glass that only the two endpoints can see through.

You'll sometimes still hear "SSL" used as a synonym. SSL was TLS's predecessor; every version of it is now obsolete and broken, and what actually runs today is TLS. The word survives out of habit — "SSL certificate," "the SSL is expired" — the way people still "dial" phones that haven't had dials in fifty years. When someone says SSL, they mean TLS.

Why It Matters

Two reasons, pulling in opposite directions, which is exactly why the topic trips people up. First, HTTPS is no longer optional: browsers mark plain HTTP pages "Not Secure," search engines rank them lower, and any login or payment over plain HTTP is negligence you'll answer for. In production it's table stakes. Second — the part that bites teams who did set it up correctly — its very reliability lulls you: the cert "just works" for ninety days, falls off everyone's radar, and the channel being secure gets quietly mistaken for the application being healthy. The most expensive HTTPS incidents aren't attacks; they're a forgotten renewal and a misdiagnosed 502. Knowing what HTTPS does, and what it does not do, keeps both off your incident log.

What TLS Actually Adds

TLS buys you three distinct things, and it's worth pulling them apart because people lump them into a vague "it's secure":

Encryption (confidentiality). Everyone on the path between you and the server — your coffee-shop Wi-Fi, your ISP, every router in between — sees only ciphertext. The URL path, the headers, the cookies, the form you submitted, the page you got back: all unreadable. This is the property most people mean by "secure," and it's the reason logging into your bank over open Wi-Fi is fine.
Integrity. Nobody can modify the data in transit without detection. Without it, an ISP could inject ads into a page, or an attacker could flip a transfer $10 into transfer $10000. TLS seals each chunk with a cryptographic check; tamper with one byte and the connection breaks rather than delivering a forgery.
Server identity (authentication). You're talking to the real example.com, not someone who hijacked the DNS or sits between you and the server. This is the certificate's job, and it's the part that's easy to take for granted — until it fails and your browser throws up a full-page red warning.

That third one is the quiet hero. Encryption without identity would be worthless: you'd have a perfectly private conversation with an impostor. A man-in-the-middle could offer you their encryption keys, you'd encrypt your password beautifully, and hand it straight to them. The certificate is what stops that — it's a signed claim, "this public key really belongs to example.com," vouched for by someone your browser already trusts.

The Certificate Chain

When the handshake starts, the server presents a certificate: a small signed document binding a public key to a hostname. Your browser doesn't trust that certificate on its own — it trusts a short chain that leads back to a root it already holds.

It's a chain of vouching. Your OS and browser ship with a built-in list of a few dozen Certificate Authorities (CAs) — the roots, baked in, trusted by fiat. A root almost never signs a server's certificate directly; it signs an intermediate CA, and the intermediate signs the server's leaf certificate. So the chain reads root → intermediate → leaf (example.com). Your browser walks it backwards — leaf signed by intermediate, intermediate by root, root on the trusted list — and only if every link checks out does the padlock appear. Break any link and trust collapses for the whole chain.

Note

A surprisingly common production outage isn't an expired leaf — it's the server forgetting to send the intermediate certificate. It often works in a browser (which may have cached the intermediate from another site) but fails in curl, API clients, and mobile apps that don't. If a site loads in Chrome but your script gets "unable to verify the first certificate," the leaf is fine — the chain is incomplete. Bundle the intermediate with the leaf in your server config.

The CA is vouching for identity, not honesty — a perfectly valid certificate can front a phishing site. Free, automated CAs like Let's Encrypt made HTTPS universal precisely by stripping the cost and friction out of getting that vouching, which is why the green padlock is no longer a trust signal in itself, just table stakes.

SNI — And What Leaks Anyway

Here's a subtlety that trips up people who assume HTTPS hides everything. One server at one IP routinely hosts many HTTPS sites — but there's a chicken-and-egg problem: the server needs to know which site you want so it can present the right certificate, and that decision happens before the encrypted tunnel exists. The fix is SNI (Server Name Indication), a field in the opening handshake that names the hostname you want, so the server can pick the matching cert.

The catch: classic SNI is sent in the clear. So even though TLS encrypts the path, the headers, and the content, the hostname you're reaching is visible to anyone watching the handshake — and so is the destination IP address, which can never be hidden because routers need it to deliver packets. The honest summary: HTTPS protects what you do on a site and which page you read, but not which site you visited or which server you reached. An observer sees you connected to example.com at 203.0.113.5; they cannot see you read /account/secret-document. (Encrypted SNI / ECH is slowly closing even that gap, but assume the hostname leaks.)

The Muddy Thing — HTTPS Secures The Channel, Not The App

This is the misunderstanding worth burning out for good: a valid certificate does not mean the application works. HTTPS guarantees the pipe is private, untampered, and connected to the right server. It guarantees nothing about whether the thing on the other end actually does its job.

You can get a 500, a 404, or — most tellingly — a 502 over a flawless, freshly-issued certificate. The TLS handshake succeeds, the padlock is green, the channel is impeccable... and the reverse proxy behind it still couldn't reach the application, so it hands you a 502 Bad Gateway through a perfectly secure tunnel. HTTPS sealed the envelope; it had no opinion about the bad news inside. When you're debugging, keep these two questions strictly separate: "is the channel secure?" (a TLS/certificate question) and "did the app succeed?" (an HTTP status-code question). Conflating them sends you tuning ciphers when your real problem is a crashed backend.

So when an HTTPS site misbehaves, read the layers in order. Did the TLS handshake complete? If not — cert error, protocol mismatch, expired cert — it's a channel problem. If it completed and you got a status code back, the channel is fine and the number is telling you the app's verdict. The padlock and the status code answer different questions; never let one reassure you about the other.

The Expired Certificate — The Outage You'll Actually Have

Of all the ways HTTPS goes wrong in the real world, one dwarfs the rest: a certificate quietly expires and the whole site goes dark. Every certificate has a hard expiry date (notAfter). The day it passes, every visitor's browser throws a full-screen security warning, API clients refuse to connect, and your monitoring lights up — not because anything was attacked, not because the server crashed, but because a date rolled over and nobody was watching.

The maddening part is how silent it is right up to the cliff. The cert works perfectly at 11:59 and is a hard error at 12:00 — no warning shot, no gradual degradation, just a working site, then a dead one, on a clock you set yourself. It has felled household-name companies and, briefly, parts of governments. And it is entirely preventable, which is what makes it so galling when it happens.

Danger

Never let certificate renewal be a manual, calendar-reminder, somebody's-job task. People change jobs, reminders get snoozed, and the one cert nobody automated is the one that takes down production at 2 a.m. on a holiday. Automate renewal end to end — certbot with Let's Encrypt renews and reloads your server without anyone touching it — and then monitor the expiry date anyway as a backstop, because automation occasionally fails silently too.

You can check any cert's dates yourself with openssl:

echo | openssl s_client -connect example.com:443 -servername example.com 2>/dev/null \
  | openssl x509 -noout -dates

notBefore=Apr 12 00:00:00 2026 GMT
notAfter=Jul 11 23:59:59 2026 GMT

That notAfter line is the one that ends careers when ignored. Know it, automate against it, and watch it.

How To Do It Right

You know how HTTPS works; here's how to run it without drama, strongest first:

Always HTTPS in production. No exceptions. Plain HTTP is postcards through every router on the path. Redirect all HTTP to HTTPS with a 301, and turn on HSTS so browsers refuse to even try plain HTTP next time.
Automate renewal. certbot + Let's Encrypt, set-and-forget. The expiry outage is a self-inflicted wound; automation is the cure.
Send the full chain. Bundle the intermediate with your leaf cert so non-browser clients can verify (see the Note above).
Keep TLS current. Disable obsolete SSL and old TLS versions; prefer TLS 1.2 and 1.3. Your web server's modern defaults are usually right — don't hand-roll cipher lists you don't understand.
Read the status code before you guess. Separate the channel question from the app question every single time.

How I Inspect It

My first move on any HTTPS oddity is curl with -v, because it narrates the handshake: curl -v https://example.com prints the certificate chain it received, the TLS version negotiated, and then the HTTP status code. In one command you see whether the failure is in the channel (handshake errors, cert verification) or above it (a 502, a 404). For the certificate specifically, the openssl s_client snippet above is my go-to.

If the handshake won't even start, I drop a layer: ss to confirm something's listening on 443, dig to check DNS resolves the hostname (a stale record sends you to a dead IP), and a ping to confirm the host is reachable at all. A clean handshake from the server itself but failures from outside usually means a firewall or NAT rule is blocking 443.