What an SSL certificate does, and what it does not protect
The padlock means the connection is encrypted and the domain is genuine. It does not mean the site is safe or well built. Where protection stops.
The short answer
The padlock in the browser means two things: what travels between the visitor and the site is encrypted, so nobody on the network can read or alter it, and the site is being served by whoever controls the domain name in the address bar. That is real and necessary. It is also all it means. A hacked site has a padlock. A phishing site has a padlock. A site that stores passwords in plain text and leaks its customer database has a padlock. Certificates are free and automatic now; the padlock is the floor of security, and it says nothing about the rest of the building.
What it protects, and what it does not
| Threat | Protected by the certificate? |
|---|---|
| Someone on the café wifi reading the form you submit | Yes |
| Someone on the network altering the page in transit | Yes |
| A fake site pretending to be yours on your domain | Yes, they cannot get a certificate for your domain without controlling it |
| A fake site on a similar domain with its own certificate | No |
| Your site compromised through an outdated plugin | No |
| Vulnerable code that leaks data or allows injection | No |
| Weak admin passwords and no two-factor | No |
| A leaked database or backup | No |
| Malicious third-party scripts loaded by your page | No |
| Data mishandled after it arrives | No |
Where the real work is
- Redirect every http request to https, so nobody lands on an unencrypted version.
- Enable HSTS, so browsers refuse to connect insecurely even if asked.
- Cover every subdomain: the forgotten one with an expired certificate is the one that warns.
- Remove mixed content: every image, script and style loaded over https, or the padlock is qualified.
- Automate renewal and monitor it: expiry is the most common certificate incident, and it is entirely preventable.
- Then do the actual security work: updates, access control, secure code, headers, monitoring.
Free versus paid
The encryption is identical. Paid certificates historically offered organisation or extended validation, which browsers used to highlight and no longer do in any prominent way. For a business website, an automated free certificate with correct surrounding configuration is the right answer, and the money is far better spent on the things the certificate does not cover.
What this means for you
Have the padlock on every page and every subdomain, with redirects, HSTS and clean content; that is the floor and it is free. Then stop treating it as proof of anything else. The security of your site lives in its code, its updates, its access control and its monitoring, none of which the certificate touches. And when a customer says a site must be safe because it has a padlock, you now know what to tell them.
Frequently asked questions
The site has a padlock, so it is secure, right?
The connection is encrypted and the domain is genuine. That is all. The site behind it can be compromised, poorly coded, leaking data or entirely fraudulent, because anyone who controls a domain can get a certificate for it in minutes. Security is everything else: the code, the configuration, the access control, the maintenance.
Do we need an expensive certificate?
For an ordinary business website, no. Automated certificates from free authorities provide the same encryption and are standard across the modern web. Higher-priced types add organisation validation, which browsers no longer display prominently. Spend the money on maintenance and monitoring instead.
Why does the browser still warn sometimes on a site with a certificate?
Usually because a page loads something over plain http, a subdomain is not covered, the certificate expired, or the redirect from http to https is missing. The certificate is present; the configuration around it is not. Each of those is a quick fix once found.
Sources
- MDN: Transport Layer Security (accessed 2026-09-11)