Every browser padlock rests on the same mechanism: the TLS handshake. Most explanations stop at “it encrypts traffic”, which is true but incomplete, and the incomplete version leads people to trust things they should not. Here is what a certificate actually does, step by step, plus the parts it deliberately leaves unprotected.
## The handshake in plain terms
When your browser connects to a site over HTTPS, the server presents a certificate: a small structured document containing a domain name, a public key, a validity window, and a signature from a certificate authority (CA). The browser checks three things. Does the domain on the certificate match the domain you asked for? Is the current date inside the validity window? And can it trace the CA’s signature back through a chain of intermediates to one of roughly 150 root certificates that ship with the operating system or browser?
If all three pass, the browser and server perform a key exchange, deriving a shared session key. From that point the traffic is encrypted and tamper-evident. The whole exchange takes a handful of round trips, and with modern session resumption a return visit costs almost nothing.
The critical insight is what the certificate proves: control of the private key held by whoever requested the certificate, at the time the CA checked, for that specific domain. Nothing more. It is not an identity document for the organisation behind the site. It says nothing about whether the business is legitimate, honest, or even real.
## What the padlock does not tell you
This is where people get burned. A phishing site can obtain a valid certificate in minutes. Since the arrival of automated authorities like Let’s Encrypt, issuing a certificate requires only proving you control the domain, which a scammer with a freshly registered lookalike domain obviously does. The padlock means the connection is protected from eavesdroppers, not that the party on the other end deserves your credit card number. Browser vendors removed the company name from the address bar for exactly this reason: extended validation told users almost nothing actionable and the visual signal was being misread as an endorsement.
Equally, the certificate says nothing about the server’s security. A fully valid TLS setup protects data in transit while doing nothing about an outdated CMS, a leaked database password, or malware served over that perfectly encrypted connection.
## Revocation, expiry, and why outages still happen
Certificates expire, typically within 90 days for automated issuers. When one lapses, browsers show a full-page warning that most users cannot bypass, which turns a forgotten renewal into an outage. Large organisations still make this mistake regularly; the failure is almost always process, not cryptography. Automated renewal agents such as certbot, Caddy, or the ACME integration built into load balancers exist precisely so that expiry becomes a non-event.
Revocation is messier. When a private key is compromised, the CA can revoke the certificate, but checking revocation on every connection would be slow, so browsers use aggregated lists that update on a delay. In practice, revocation is best effort. The system assumes compromise is rare and detection slower, which is one reason key hygiene on the server matters more than the theoretical existence of a revocation mechanism.
## Where TLS sits in the wider picture
Encryption in transit is one layer among several, and it is worth knowing which layer handles which threat, and which physical path the traffic actually rides under the ocean. TLS protects data crossing the network. It does not protect data at rest on the server, does not authenticate users, and does not stop the server itself from being malicious. Other infrastructure faces analogous trade-offs: the same reasoning explains why an LLM API gateway can add rate limits and failover on top of an encrypted connection without changing what the encryption itself guarantees, and why a service can be perfectly encrypted end to end and still leak data through its own logs.
A useful mental model: TLS answers “can anyone between these two computers read or alter this conversation?”. Every other security question, from who runs the server to what it does with your data, needs a different answer.
## Practical checklist for anyone running a site
– Use automated renewal so expiry cannot take you down.
– Redirect all HTTP traffic to HTTPS and set HSTS so browsers stop attempting the plain version.
– Keep TLS 1.2 enabled only for legacy clients if you must, and prefer 1.3. Old protocol versions and outdated cipher suites are the most common finding in free SSL scans.
– Protect the private key file permissions, and never copy keys between machines over insecure channels.
– Remember that the padlock is table stakes. Trust decisions belong to the domain name and the entity behind it, which no certificate can vouch for.
The system is not magic and it is not broken. It solves one narrow problem, transport security, with remarkable reliability. Confusing it for a trust seal is the mistake, and no amount of cryptography can fix that.