12 August 2026 · 3 min read
The padlock in the address bar proves one specific thing: the connection between the browser and your server is encrypted, and the server showed a certificate that binds the domain name to that connection. That is the whole job. Over the years the padlock has picked up plenty of other meanings, and some of them quietly cost people.
What it does
Encryption in transit. Everything that moves between the browser and the server, the form submission, the login, all of it, is unreadable to the networks the traffic passes through. That matters more than people assume, because a page’s traffic crosses a lot of networks it has nothing to do with, from a cafe’s Wi-Fi to a carrier’s gear.
A check on the name. A certificate authority signs a certificate that binds the domain name to the encryption keys in use, so the browser can be sure it is talking to the right server and not an impostor on the network. Be clear about how strong that check is. The common, inexpensive certificates verify that the applicant controls the domain, through a file on the site, a DNS record, or an email address on the domain. That is a real check of control, and a weak check of identity. Whoever holds the domain can get a certificate for it, which is exactly why the padlock does not tell you who the business behind it is.
It is the default now. Browsers mark pages without encryption as not secure, and a growing list of web features only works over a secure connection. Even if you never ask a visitor for anything, an unencrypted site is the odd one out.
What it does not do
It does not protect your data at rest. The encryption ends at the server. If the database is compromised, the certificate did nothing and will not save it now.
It says nothing about the server itself. There is nothing about encrypting the pipe that stops a denial of service, an exploited application, or a compromised host.
It does not vet the site. Phishing and scam sites run certificates. The padlock says “this connection is encrypted to this name,” and that is all.
It is not a speed fix. The handshake overhead is trivial next to page weight and server response. Turning it on will not make a slow site fast.
It is not a backup.
The side that actually fails
The cryptography is rarely the problem. The operation is. Three things come up over and over.
- Short validity, no automation. Modern certificates are issued for weeks to a few months, not years, and the model assumes renewal runs itself. An expired certificate is one of the most common causes of a site that suddenly stops, and the failure is loud: the browser shows a full-page warning instead of the site.
- Hosts that were never added. A certificate for the main domain rarely covers staging, or app, or the domain you bought six months ago and forgot to include. Every new hostname is a new coverage question.
- Mixed content. A page served over an encrypted connection that still pulls something in over plain HTTP. The browser blocks or flags it, and the page shows as partly insecure. It usually appears after a migration, when some links in a database never got updated.
What to actually ask
If you are on managed hosting, the certificate should be someone else’s operational problem, and that is what you are paying for. Ask how renewal is handled and what happens when it fails. If the answer is “we renew it manually each time,” you now know exactly where the risk is, and you can decide what to do with it.
If you run your own stack, the bar is simple: make sure the renewal job runs, get an alert if it fails, and make sure every hostname in use is covered by a live certificate. None of it is hard. It is just easy to forget.
The certificate is plumbing. Done right, nobody ever mentions it. That is the point.