Theo's Corner
dev / irl / thoughts
← Back
tech

How HTTPS works under the hood

Theo|Jul 2026|~5 min read

You see the padlock in your browser on every secure site. But what's actually happening when you connect to an HTTPS site? It's one of those things that looks like magic from the outside and is actually fascinating once you look at the mechanism.

The problem HTTPS solves

Regular HTTP sends data as plain text. If you're on a public network and someone is listening, they can read everything — your passwords, your messages, your banking details. HTTPS encrypts that data so even if someone intercepts it, they can't read it without the decryption key.

TLS — the actual mechanism

HTTPS is HTTP with TLS (Transport Layer Security) on top. TLS is the protocol that handles the encryption. When you connect to an HTTPS site, before any page data is sent, your browser and the server go through a handshake to establish an encrypted connection.

The handshake happens in milliseconds and you never see it. But it's doing a lot — verifying the server's identity, agreeing on encryption methods, and exchanging keys.

Certificates and trust

For HTTPS to work, the server needs an SSL/TLS certificate. The certificate does two things — it contains the server's public key, and it's signed by a Certificate Authority (CA) that your browser trusts. When you connect, the browser checks the certificate is valid and signed by a trusted CA. If it is, the padlock appears. If it isn't, you get a scary warning.

Let's Encrypt is a free CA that Certbot automates. That's how most self-hosted sites get their certificates — run Certbot, it verifies you own the domain, issues a certificate, and sets up auto-renewal. The whole thing takes a few minutes.

Public key cryptography

The clever part is how the encryption keys are exchanged safely over a connection that isn't yet secure. TLS uses asymmetric cryptography — a public key that anyone can use to encrypt data, and a private key that only the server has to decrypt it. You can send data encrypted with the public key knowing only the server can read it. From that secure channel, a shared symmetric key is established for the rest of the session, which is faster for bulk data.

Why it matters for self-hosting

If you're running anything on the internet — a website, an API, a panel — it needs HTTPS. Not just for security, but because browsers actively warn users about HTTP sites, and some features (service workers, certain APIs) flat out refuse to work without it. Certbot makes it free and mostly automatic. There's no reason not to.