If you want the structural reference for what an SSL certificate actually is, that is its own page: What is SSL. This one is about a specific, persistent misconception that the cert is a trust signal.

01What the padlock actually means

When a browser shows the padlock, it is asserting two things: the connection is encrypted using TLS, and the certificate the server presented chains back to a CA in the browser’s trust store. The cert is bound to a specific hostname, and the hostname matches the URL bar. That is what the padlock asserts. Nothing more.

What the padlock does not assert:

• That the site is operated by who you think it is. The cert binds a public key to a hostname, not to a company. A domain-validated cert for paypa1.com is just as cryptographically valid as a cert for paypal.com; the CA never checked who registered either domain.
• That the site is legitimate, safe, or honest. Those are content questions; cert issuance is a domain-control question.
• That the site is not a phishing page. The CA’s job is to verify the requester controls the DNS, not to adjudicate whether the resulting site will be honest.

This was always how DV certs worked. What changed in 2015-2017 was scale: Let’s Encrypt automated the issuance and offered it for free, attackers picked up ACME clients alongside everyone else, and the share of phishing sites with valid certs went from rare to majority within a couple of years.

02Why the green-padlock-means-safe heuristic broke

Three things had to go wrong simultaneously, and they all did:

First, the user-education campaigns of the 2000s explicitly trained users to look for the lock. “Look for the padlock before entering your password” was the canonical advice. That advice was correct in a world where DV certs were $99 and OV certs were $300 – the price floor created a weak proxy for legitimacy. When the floor went to zero, the proxy stopped working but the user training did not get retracted.

Second, browser UI doubled down on the metaphor. Address bars went green for EV certs, padlocks were visually emphasised, “Not Secure” warnings appeared for HTTP. All of this reinforced “padlock = trustworthy” rather than “padlock = encrypted connection to whoever owns this domain.”

Third, automation made certs as cheap as DNS. Anyone who can set up a phishing site on a lookalike domain can also automate a Let’s Encrypt cert for it. The marginal cost is zero. The threshold for “looks legitimate” collapsed.

The Krebs piece from 2018 – “Half of all phishing sites now have the padlock” – is the canonical citation for when this stopped being a niche concern. APWG’s quarterly reports (apwg.org/trendsreports) have continued to track the trend; HTTPS adoption among phishing sites is now functionally universal.

03How browsers walked back the trust signal

Around 2019-2020, the major browsers quietly stopped emphasising the cert as a trust signal:

• Chrome dropped the EV name display in the URL bar in 2019. The justification (in the Chromium URL display guidelines) was that EV did not actually distinguish legitimate sites from phishing sites at the rate users believed it did, and the visual prominence in the address bar was a misleading affordance.
• Firefox did the same in 2020. Same reasoning.
• “Not Secure” warnings on HTTP became universal, which has the side effect of making every HTTPS site – phishing or otherwise – look “secure” by default in the address bar.
• The padlock icon itself was dropped or replaced in Chrome 117 (2023) with a more neutral “tunable” icon, again because the lock was reading as “this site is trustworthy” when it only ever meant “this connection is encrypted.”

The browser vendors are not pretending the cert is a trust signal anymore. The user-education layer has not caught up. That gap is where modern phishing lives.

04What CAs do and do not police

The Certification Authority’s job is to verify that the requester controls the domain. That is the entire scope of DV. OV adds a check that the requesting organisation exists in a public registry. EV adds documented procedures for verifying the applicant’s identity. None of those tiers ask “is this domain going to be used to phish?” because that question is not answerable at issuance time.

CAs do, however, revoke certs after the fact:

• Let’s Encrypt’s stated position – laid out in their 2015 blog post on phishing and malware and unchanged since – is that they do not block issuance based on suspected phishing, but they will revoke certificates the Google Safe Browsing or Microsoft SmartScreen lists flag. They are explicitly not a content-policing entity.
• Paid CAs vary. Sectigo, DigiCert, and SSL.com have abuse-handling teams that will revoke on a credible report; the response time is hours to days. None will pre-screen.
• The CA/B Forum’s Baseline Requirements give CAs latitude to revoke for “any reason,” but the operational practice is to wait for an external signal (Safe Browsing entry, abuse report, customer complaint) rather than scan the cert pipeline themselves.

The realistic mental model: the CA is not gatekeeping for legitimacy. The browser is not gatekeeping based on the cert alone. The user is not in a position to evaluate the cert chain at sign-in time. The defense has to live somewhere else.

05What actually defends users in 2026

The trust signals that matter are not on the cert. They are everywhere else:

• Phishing-resistant MFA. WebAuthn / FIDO2 / passkeys bind the credential to the origin (hostname). A user phished into typing their credentials at paypa1.com still cannot complete a passkey-based sign-in there, because the passkey is bound to paypal.com‘s origin and the browser will not release it to a different one. This is the single biggest defensive shift since 2020.
• Password managers that auto-fill on origin match. 1Password, Bitwarden, browser password managers – all of them refuse to auto-fill credentials on a hostname that is not exactly the saved one. A user trained to “let the password manager fill it” is implicitly verifying the domain.
• Safe Browsing / SmartScreen / Brave Shields. Real-time URL block-listing catches the long tail of known-bad domains within minutes to hours of report. Not perfect, but much faster than waiting for a CA to revoke.
• Email path defenses. SPF + DKIM + DMARC limit who can send mail purporting to be from a domain. They do not stop the user from clicking a link in a malicious email, but they do reduce the volume of spoofed-from-trusted-domain mail in the first place.
• HSTS preload. If your domain is on the HSTS preload list (per RFC 6797), browsers refuse to connect to it over HTTP. This does not stop phishing on a different domain, but it eliminates one specific attack on the legitimate domain (downgrade-to-HTTP-then-strip-credentials).

None of these are SSL-cert-based. The cert is now a participation certificate; it gets you into the encrypted-connection club, and the club lets in everyone.

06What to tell users (and what not to tell them)

The training materials need updating. The advice that was correct in 2010 is wrong now:

• Stop saying “look for the padlock.” It is not a phishing signal. It will be present on most phishing sites. The advice trains users on the wrong thing.
• Stop saying “look for the green bar.” There is no green bar. EV does not visually distinguish itself in the address bar in any current browser.
• Do say “verify the hostname in the URL.” Letter by letter, including the TLD. paypal-secure.com, paypa1.com, paypal.com.example.net are all different from paypal.com. This is the actual signal users can act on.
• Do say “use a password manager and let it fill credentials.” The auto-fill match is the verification step. If the password manager will not fill, the domain is wrong.
• Do say “use phishing-resistant MFA.” Hardware keys and passkeys are origin-bound by design. Even a user who falls for the URL spoof cannot complete the auth.

The hard part is that “look for the padlock” was a specific, actionable, easy-to-train heuristic. The replacement – “use phishing-resistant MFA, trust your password manager’s auto-fill, read the URL carefully” – is more correct but lower-bandwidth. Security awareness teams that have not updated their training in three years are still reinforcing the old heuristic.

07What this means for site operators

If you run a site users sign in to:

• Add your domain to the HSTS preload list. Cheap, well-documented, eliminates downgrade attacks on your hostname. The form is at hstspreload.org.
• Implement DMARC at p=reject. If your domain is being spoofed in phishing email, DMARC is what stops the bulk of it from delivering. Watch the aggregate reports for a quarter, fix legitimate misalignments, then move from p=none to p=quarantine to p=reject.
• Offer phishing-resistant MFA (passkeys, hardware keys). Treat SMS and TOTP as legacy. Users who get phished still cannot complete auth on the wrong origin.
• Monitor for lookalike domains. Tools like Cert Transparency monitors (search crt.sh for substring matches on your brand) will flag certs being issued for hostnames that ought to look suspicious. The CA is not pre-screening, but you can post-screen.
• Keep your own cert hygiene tight. A short-lived DV cert via ACME on every public hostname, automated renewal, OCSP stapling. None of that prevents phishing of your users, but it removes you from the population of “legitimate site with a misconfigured TLS that drove the user to ignore warnings.”

The cert was never the defense. The cert is the table-stakes protocol artefact. The defenses are credential-binding, URL-reading, and email-path hygiene. Train users accordingly, and stop telling them the padlock means the site is safe.

08Working notes for 2026

Three concrete moves that are reasonable to do this quarter:

• Audit your security training materials. If they say “look for the padlock” or “look for the green bar,” strike both. Replace with URL-verification, password-manager auto-fill, and phishing-resistant MFA guidance. Most LMS-delivered training has not been updated since 2018; it shows.
• Set up CT-log monitoring for your brand. Subscribe to crt.sh RSS for substring matches on your domain or brand name. Newly-issued lookalike-domain certs surface within minutes of issuance and are a leading indicator of campaigns being prepared.
• Submit your domain to the HSTS preload list if it is not already on it. Verify with the form at hstspreload.org; check the eligibility criteria carefully (max-age, includeSubDomains, no mixed content) before submission, since removal takes months.

Reference material: the Krebs piece from 2018, APWG quarterly reports for the current statistics, Let’s Encrypt’s policy on phishing and malware for the CA’s perspective, and the Wikipedia overview if you need a serviceable summary.