The padlock is the most widely recognised security indicator on the internet and one of the most widely misread. It makes two narrow guarantees, and everything outside them is a separate question.
What it does prove
The connection is encrypted. Nobody between the visitor and the server can read the traffic or alter it. On a public network that is a genuine and important protection.
The server controls the domain in the address bar. A certificate is issued only after the applicant demonstrates control of that name, so the visitor knows they reached the server for that domain instead of an impostor.
Both matter. Neither says anything about the site itself.
Why phishing sites have padlocks
Because the certificate proves control of the domain, and the attacker genuinely controls their deceptive domain.
A site at secure-yourbank-login.com can obtain a valid certificate in minutes, free, and display exactly the same padlock as the real bank. The certificate is honest. It correctly states that this server controls that name. The name is the lie.
Which is why "look for the padlock" is poor advice on its own, and why reading the domain is the check that matters.
It does not protect the data after it arrives
Encryption covers the journey. Once the data reaches the server it is decrypted, and what happens next is entirely up to the application.
A form submitted over HTTPS to a site that stores passwords in plain text, or writes card numbers to a log file, was transmitted securely and stored badly. The padlock was accurate throughout.
Protecting data at rest is a separate exercise. What your hosting provider can and cannot see goes into where encryption genuinely helps there.
It does not make the code safe
A vulnerable application is equally vulnerable over an encrypted connection. Injection, insecure uploads, weak authentication, none of them is affected by the certificate.
What HTTPS does is prevent the attack being observed in transit, which occasionally benefits the attacker as much as anyone.
The work that addresses this is separate and larger, securing WordPress against vulnerabilities and setting up a file upload directory safely cover two of the common paths.
It does not mean the site is not compromised
A hacked site keeps its certificate. Malicious code injected into a page is served over the same encrypted connection as everything else, with the padlock intact.
Visitors have no indication whatsoever from the certificate. For the actual symptoms, see cleaning up a hacked site.
What about the more expensive certificates?
Certificates that verify an organisation's identity do check something real: that a named company exists and requested it.
The difficulty is that browsers no longer display that distinction prominently. A visitor sees the same padlock either way, so the additional verification is not communicated to the person it was meant to reassure.
Whether that is worth paying for depends on whether anyone in your industry actually inspects certificates. Types of SSL certificates goes into the differences honestly.
What it is still required for
None of this is an argument against certificates. They are required, and for good reasons: browsers mark plain HTTP as insecure, payment handling requires encryption, and login credentials over an unencrypted connection are readable by anyone on the network.
The point is narrower. A certificate is one requirement among many, and treating it as evidence that security has been dealt with is how sites end up encrypted and exposed at the same time.
It is the first item on the list, not the list. Setting up security headers explains what belongs immediately after it.
It says nothing about where the data goes next
The encryption covers one hop. What the site does with what you typed is outside it entirely.
A form submitted over a secure connection can be forwarded by the receiving site in plain text, emailed unencrypted, written to a log, or sent to a third party analytics script running on the same page. Each of those is a normal, common arrangement.
curl -s https://example.com/checkout | grep -oE 'src="https?://[^"]+"' | sed 's|.*//||; s|/.*||' | sort -u
That lists which other companies receive a copy of the page and, depending on how they are configured, what is typed into it. The padlock covers your connection to the site and says nothing about that list.
Expired and revoked are not the same failure
Both produce a warning, and only one of them means what people assume.
An expired certificate is an administrative lapse. The site is almost certainly the same site and the operator forgot to renew. A revoked certificate means the issuer withdrew it, usually because the private key was exposed, and that is a materially more serious message.
openssl s_client -connect example.com:443 </dev/null 2>/dev/null | openssl x509 -noout -dates -serial openssl s_client -connect example.com:443 -status </dev/null 2>&1 | grep -A3 'OCSP Response Status'
Browsers check revocation inconsistently and frequently fail open, meaning an unreachable check is treated as acceptable. So a revoked certificate can continue to work in practice, which is worth knowing before treating revocation as a control you can rely on.
Encrypted does not mean private from your host
Where the certificate terminates is where the traffic becomes readable, and that place is usually not your application.
With a CDN or a load balancer in front, the connection is decrypted there and re-encrypted, or forwarded in the clear, to your server. The operator of that layer can read everything, by design, since that is how caching and filtering work.
This is not a flaw and it is a fact worth stating internally, particularly for anything handling health, financial or identity data. The question to answer is who holds the private key and where the plain text exists, not whether the visitor sees a padlock. What your hosting provider can and cannot see goes into the rest of that picture.
The name it validates is narrower than people read
A certificate is issued for hostnames, and a visitor reading a hostname is not reading an organisation.
Names that differ by a character, use a different extension, or place the real brand in a subdomain of an unrelated domain all obtain valid certificates without difficulty, because the check is control of the name rather than the right to the brand.
openssl s_client -connect example.com:443 </dev/null 2>/dev/null | openssl x509 -noout -subject -ext subjectAltName
Read the alternative names list rather than the subject alone. The practical defence for your own brand is watching what gets issued for names resembling yours, which is a monitoring task and not something the certificate itself can do. Why a certificate is trusted goes into the logs that make it possible.