Why a padlock does not mean a site is trustworthy

Many people were taught, reasonably at the time, to look for the padlock before typing a password. The advice was good in 2010. It is incomplete now, and in some cases it is misleading, so it is worth being clear about what the padlock really tells you.

What it does say: the connection between your browser and the server is encrypted, so someone sitting on the same coffee-shop wifi cannot read or alter the traffic. It also says that the certificate presented matches the domain name in the address bar and was issued by an authority your browser trusts.

That is a real and useful guarantee. It is also a narrow one, and the gap between what the padlock promises and what people hear is where phishing sites live. This article sets out what the padlock covers, what it leaves out, how certificates are issued, what to look at instead, and what site owners need to do to keep the plumbing working.

What the padlock does not say

It says nothing about who owns the domain, whether they mean well, or what they will do with the information you give them. A site called secure-login-yourbank.example can have a perfectly valid certificate. Issuing a certificate only requires showing control of the domain name, and anyone can register a domain.

Think of it as the difference between a sealed envelope and a trustworthy recipient. The padlock tells you the envelope was sealed in transit and arrived unopened at the address printed on it. It does not tell you that the person at that address is who they claim to be. A fraudster can have a mailbox with a lock on it, too.

How certificates came to be easy

This changed gradually. The first generation of certificates involved paperwork: company registration, phone calls, sometimes a notary. Today, the most common type is domain validated, issued automatically in seconds, often free. That is a good thing for the web as a whole, because it pushed encryption from a few percent of sites to nearly all of them. It just means the padlock stopped being a trust signal and became a plumbing signal.

There are three levels of validation. They differ in what the authority checked before issuing, not in how strong the encryption is, which is identical.

Control of a domain is shown by answering a challenge: placing a file at a given web address, or adding a given record in DNS. The ACME protocol automates this, which is how certificates now renew themselves every couple of months with no human involved. Software cannot tell whether the person asking is honest. It only knows they can change the site or the DNS, and that is all a DV certificate says.

The icon itself has been changing

Browsers noticed this, too. Chrome replaced the padlock with a neutral settings icon in 2023, partly because people had started reading it as a mark of safety. Meanwhile the old green address bar for extended validation certificates has disappeared from mainstream browsers, since almost nobody noticed when it was absent. Where a browser now speaks up, it is to warn about the opposite case: a page without HTTPS is marked "Not secure", and a page whose certificate has expired or does not match gets a full-screen warning.

The direction of travel is that encryption is assumed, and only its absence is flagged. That matches the real situation. A padlock on a page is the normal state of the web, so it carries about as much information as a roof on a building.

A worked example

An accounts clerk at a small firm receives an email that appears to come from the company's bank: the account will be suspended unless she confirms her details. The link goes to https://bankname.secure-verify.example/login. The page has a padlock, the logo is right, and the layout is a faithful copy.

What gives it away is the address. Read the domain from right to left up to the first single slash: the part that counts is secure-verify.example, and bankname is merely a subdomain that the owner of that domain was free to create. The bank's real name would sit directly in front of its own top-level domain. The attacker registered a throwaway domain for a few pounds, obtained a free DV certificate in under a minute, and copied the page.

The clerk's password manager is what stops the damage. It offers the saved login only on the real bank's domain, and stays silent here. When the manager does not offer to fill, that is information, not a nuisance.

What the browser actually checks

When you connect, the server presents a certificate, and the browser runs through a short list before showing anything. Does the name in the certificate match the address typed? Is today's date inside the validity period? Was it signed by an authority the browser or operating system trusts, either directly or through a chain of intermediate certificates? Has it been revoked? If every answer is yes, the connection proceeds and the padlock appears. None of those questions involves the content of the site.

This is why a missing intermediate is a classic site-owner mistake. The site works in a desktop browser that has cached the intermediate from elsewhere, and fails in a phone app or a command-line tool that has not. Install the full chain file your authority provides, not just the single certificate.

Other signals that mislead

The padlock is not the only symbol people have been trained to trust. Several others deserve the same scepticism.

• "Secure site" badges and trust seals in a page footer are just images. Anyone can paste one into a page. A genuine seal links to a verification page on the issuer's own domain, and even then it describes a scan or a payment arrangement, not the honesty of the seller.
• A professional design says nothing. Copying a site's look takes minutes, including its fonts, wording and legal pages.
• A high search ranking is not an endorsement. Paid adverts can appear above genuine results, and attackers do buy them for banking and delivery brand names.
• A familiar sender name in an email is trivially faked. The address behind the name, and the checks the receiving mail system makes, are what count. The DMARC builder explains how site owners stop their own domain being forged in that way.
• A website claiming a long list of reviews, with no verifiable source for them, is worth no more than any other text on the page.

The common thread is that every cue on the page itself can be copied. The cues that cannot be copied are the ones outside the page: the domain you typed or bookmarked, the response of your password manager, the warning lists your browser fetches, and your own bank's statement of what it will and will not ask by email.

Walkthrough: fixing "not secure" after a move

A village cricket club moves its site to a new host over a weekend. On Monday, the committee reports that the address bar says "Not secure" on some pages and that the home page "sometimes shows a warning". The diagnosis goes in four steps.

1. Run curl -I http://example.com/. The answer is a 200, not a 301. Plain HTTP is served directly, with no redirect to HTTPS, because the redirect rule lived in the old host's configuration and was not copied across.
2. Run the certificate command from the checking section against www.example.com. The subject lists only example.com, so the www name produces a name mismatch warning.
3. Open the browser's developer console on the home page. It lists blocked and warned items: two images referenced as http://example.com/wp-content/..., left over from a database that still holds the old address.
4. Fix each one. Request a certificate covering both names. Add a permanent redirect from HTTP to HTTPS. Update the stored site address and search-and-replace the old image links in the database, on a backup.

Nothing in this list involved trust. It was all plumbing, which is exactly the point: the padlock reflects whether the plumbing is correct, and a site owner owes visitors that much.

Certificates on different kinds of hosting

Where you stand determines how much of this you handle. On shared and managed hosting, the host usually issues and renews certificates for you from the panel, often with one click or by default. You still need to check that every hostname is covered, and that a DNS change has not broken the validation. On a VPS, you run the ACME client yourself (usually a small tool set to run from a scheduler), and you own the failure when the scheduled job stops. Check that renewals appear in its log, and test with a dry run before a deadline rather than after it. On dedicated servers the arrangement is the same as a VPS, though more sites mean more certificates to track, and a wildcard certificate, which covers every first-level subdomain, may reduce the count.

In every case, set an alert for a date about two weeks before expiry. Automation fails more often than people expect, usually after a DNS or server change that nobody connected with certificates.

What to check instead

• Read the domain name carefully, especially the part immediately before the first single slash. Attackers rely on look-alike spellings: a letter swapped for a similar one, rn standing in for m, an extra hyphenated word, or a different ending such as .example where the real one is something else.
• Be wary of links arriving by email or message, even if they appear to go to a familiar company. Type the address yourself or use a bookmark.
• Use a password manager. It will refuse to fill your login on a site whose address differs, which is one of the best phishing defences available to ordinary people.
• Browser warnings about a site being deceptive are worth heeding. They are driven by live lists, not by the certificate.
• If a message creates urgency (your account will close today, a parcel will be returned), slow down. Pressure is the attacker's main tool.
• For anything involving money, go to the organisation's site by your own route and look for the same message there.

For site owners: keep the plumbing working

For site owners, the lesson runs the other way. HTTPS is not a trophy. It is the minimum, and it needs to be kept working: renewed on time, covering every hostname you use, and configured so that old insecure links redirect cleanly.

Failures here are mundane and common. A certificate issued for example.com but not www.example.com, so one of the two shows a warning. An automatic renewal that silently stopped after a DNS change. A page that loads over HTTPS but pulls one image or script over plain HTTP, which browsers block or flag as mixed content. An old marketing link to the http:// address that ends on a blank page because no redirect exists.

A clean setup has these properties:

1. Every hostname you publish is covered by a certificate, including www and any subdomains in use.
2. Renewal is automatic, and something alerts you if it fails, well before expiry.
3. Plain HTTP requests are redirected permanently to the HTTPS version of the same page, in one hop.
4. Pages load all their resources over HTTPS.
5. Optionally, an HTTP Strict Transport Security header tells browsers to use HTTPS for your domain without even trying plain HTTP. Switch it on with a short lifetime first; a long one is hard to undo if you later break HTTPS.

The SSL expiry tool shows the remaining life of a certificate, and the redirect generator builds the HTTP-to-HTTPS rules for common servers.

Try it on your own site

To see what a certificate actually claims, ask for it directly:

echo | openssl s_client -connect example.com:443 -servername example.com 2>/dev/null | openssl x509 -noout -subject -issuer -dates
curl -I http://example.com/

The first command prints the subject (the name or names it covers), the issuer, and the start and end dates. For a DV certificate, the subject will be little more than the domain name, with no organisation. The second shows whether plain HTTP redirects: you want a 301 and a Location header pointing at the HTTPS address. In a browser, clicking the icon beside the address and opening the certificate details shows the same information. The status code list explains the codes.

For a site you do not own, check how old the domain is with a registration lookup, and be suspicious of anything created a few days ago that claims to be a long-established company. The certificate will not tell you this; the registration record will.

Smaller questions

Is a site without a padlock always dangerous?

Not dangerous in itself, but you should not enter passwords or card details on it, because anyone on the path can read them. Browsers warn on such pages for that reason.

Do paid certificates offer more protection than free ones?

The encryption is the same. Paid products may add validation of the organisation, support, or warranties, which suit some businesses. They do not make a site more trustworthy to visitors, because the browser shows no difference.

Can a padlock appear on a hacked genuine site?

Yes. If an attacker takes over a real site, the certificate remains valid, and the padlock stays. The browser's warning lists and a vigilant host are what catch this, not the certificate.

What should I do if I entered my password on a fake site?

Change it at once on the real site, and anywhere else you reused it. Turn on two-factor authentication, and tell the real organisation, which may be able to block the fake.

Why does my browser say "not secure" on my own site?

The page was loaded over plain HTTP, or it has mixed content, or the certificate is expired or wrong for that name. Run the checks above to find which.