You see it a thousand times a day and never think about it: the little padlock in your browser's address bar. Behind that tiny icon is one of the most important pieces of plumbing on the internet — and a surprisingly elegant little dance happens every single time you load an https:// page.
Let's pull back the curtain, in plain English, no maths degree required.
What HTTPS actually is
HTTPS is just HTTP + TLS. Plain HTTP sends everything in the clear — anyone between you and the server (your ISP, someone on the café Wi-Fi) could read or tamper with it. TLS (Transport Layer Security — the modern successor to SSL) wraps that traffic in encryption.
It gives you three guarantees:
| Guarantee | Means |
|---|---|
| Privacy | Nobody in between can read the traffic |
| Integrity | Nobody can secretly modify it in transit |
| Authenticity | You're really talking to the site you think you are |
That third one — authenticity — is what stops someone from impersonating your bank. And it's powered by certificates.
The handshake, step by step
Before any real data flows, the browser and server do a quick negotiation called the TLS handshake. Simplified, it goes like this:
- ClientHello. The browser says hello and lists what it supports — TLS versions, cipher options, a random number.
- ServerHello + certificate. The server replies with its choices and presents its TLS certificate — a document, signed by a trusted authority, that proves "I really am example.com."
- Verify the certificate. The browser checks the certificate: is it signed by a trusted authority? Is it for this domain? Is it still valid (not expired)? If anything's off, you get that scary warning instead of the padlock.
- Key exchange. Using the certificate's public key, both sides securely agree on a shared secret key — without ever sending that key across the wire where someone could grab it.
- Secure. From here, everything is encrypted with that shared key. The padlock appears, and your actual request finally flows — safely.
The clever part: steps 1–4 let two strangers agree on a secret in public, in milliseconds, every time you connect.
The certificate is the linchpin
Notice how much rides on that certificate in step 3. It's what proves the server is who it claims to be. Which is why two certificate problems break HTTPS entirely:
- Expired certificate — browsers stop trusting it and block the connection. (It's so common and so preventable we wrote a whole guide on avoiding it.)
- Wrong/invalid certificate — name mismatch, untrusted issuer, or a broken chain → the same blocking warning.
To a normal visitor, both look identical to "this site got hacked" — which is why a lapsed certificate is a full outage, not a minor glitch.
Common HTTPS issues
| Symptom | Likely cause |
|---|---|
| "Your connection is not private" | Expired or invalid certificate |
| Padlock with a warning | Mixed content (some assets loaded over plain HTTP) |
| Works in one browser, not another | Incomplete certificate chain |
| Fails only sometimes | One server in a pool has a bad/old cert |
The bottom line
| Concept | In one line |
|---|---|
| HTTPS | HTTP wrapped in TLS encryption. |
| The handshake | Hello → certificate → verify → agree a key → encrypt. |
| The certificate | Proves the server's identity — the trust anchor. |
| The risk | An expired/invalid cert breaks the padlock entirely. |
The padlock represents a tiny, fast negotiation that gives you privacy, integrity and proof of identity — every time, automatically. The main thing that breaks it is a certificate problem, and those are almost always preventable with monitoring.
Check any site's certificate and chain with the free SSL checker, and never get surprised by expiry with certificate monitoring.