Chaîne métallique en gros plan sur fond bleu, image de la chaîne de confiance des certificats TLS

Counterfeit TLS certificates for Google: why the padlock isn’t a guarantee

On October 6, 2026, Google’s Chrome security team revealed that attackers had taken control of the registries for three country-code domains: .gh (Ghana), .sl (Sierra Leone) and .as (American Samoa). From there, they modified DNS records and obtained counterfeit TLS certificates for several Google domains, as well as for domains belonging to other organizations, including “several leading global brands”.

The unsettling part: these certificates were technically valid. A browser that received one could show the little padlock as if everything were fine. Google says its own systems were not breached and that it has no reason to believe the certificate authorities that issued these certificates did anything wrong. It was the chain of trust around them that was fooled.

In short

The padlock does not prove who runs the site. It proves the connection is encrypted with a certificate that a trusted authority issued for that domain name. Whoever controls the domain’s DNS can obtain that certificate.
.ca and .com domains are not among the hijacked extensions. But the same outcome (a “valid” counterfeit certificate for your domain) can happen in a far more ordinary way: a poorly protected registrar account.
Google can’t guarantee it found everything, and its blocks in Chrome do not reliably protect people using other browsers.

The chain of trust, and where it broke

When you open a site over HTTPS, several links must hold for the padlock to mean anything. Here they are, in order, with what happened in the incident Google described.

LINK 1 · THE COUNTRY-CODE REGISTRY

The organization that runs an entire extension (.gh, .sl, .as, or .ca here in Canada) and says which DNS servers answer for each domain.

⚠ Where the attack got in

Attackers compromised these three registries, putting any domain ending in .gh, .sl or .as at risk.

↓

LINK 2 · AUTHORITATIVE DNS SERVERS

They answer the question “where is this site?”. Everyone, including certificate authorities, relies on their answer.

⚠ Forged answers

Attackers modified the DNS records of selected domains so requests ended up on their servers.

↓

LINK 3 · THE CERTIFICATE AUTHORITY

Before issuing a certificate, it checks that the applicant controls the domain, often through a DNS or web test.

Fooled, not at fault

Because DNS was answering for the attackers, the test passed. Google has “no reason to believe” the authorities did anything wrong.

↓

LINK 4 · CERTIFICATE TRANSPARENCY (CT) LOGS

Certificates that Chrome trusts by default must be recorded in public logs that anyone can search.

✓ Where it becomes visible

These logs let Google spot other affected organizations. They are also where you can watch your own domain.

↓

LINK 5 · THE BROWSER AND ITS PADLOCK

The browser checks that the certificate is valid for the requested name and comes from a trusted authority. If so, it shows the padlock.

Misleading padlock

With a valid certificate in hand, an impostor can pose as the real site. Chrome now blocks the certificates Google has identified.

The lesson for an SMB: the weakest link isn’t the encryption, it’s control of your domain name. Anyone who can change your domain’s DNS answers can, in principle, get counterfeit TLS certificates in your name.

How Google responded, step by step

Week of September 28: Google learns of a series of domain hijacks in the three extensions.
Immediate block in Chrome: unauthorized certificates for Google properties are blocked through CRLSets, a Chrome mechanism for quickly blocking specific certificates.
Revocation by the authorities: Google works with the issuing certificate authorities to have these certificates revoked, to also protect users of software other than Chrome.
CT log review: Certificate Transparency logs reveal other organizations believed to be affected. Google blocks those certificates in Chrome too and alerts the organizations where possible.
October 6: Google publishes its post. Chrome users don’t need to do anything. Domain owners, on the other hand, have work to do.

Google did not name the affected domains, the other organizations or the number of certificates. Nor did it say whether the certificates were used to intercept real traffic. And it is blunt about it: “Due to the complexity of DNS hijacks, we cannot guarantee that our analysis identified every affected domain, nor do Chrome interventions reliably protect non-Chrome users.”

What Google recommends to domain owners

Google gives just two recommendations. They apply to any SMB with a website or email on its own domain.

1. Monitor Certificate Transparency (CT) for all your domains

Every trusted certificate must be published in CT logs. Monitoring them gives you a near real-time alert when a certificate is issued for one of your domains. Google insists: cover your entire domain portfolio, including parked domains and regional extensions. For a free first look, type your domain into crt.sh.

2. Publish restrictive CAA records, bound to your account

A CAA DNS record states which authorities may issue certificates for your domain. Google acknowledges that CAA can’t prevent issuance during an active DNS hijack. But once DNS control is restored, a CAA policy that limits issuance to your account and to specific validation methods stops an attacker from reusing a completed validation to mint new certificates.

Example CAA records for a domain whose certificates come from Let’s Encrypt (adapt to your setup; the account number is fictitious):

yourcompany.ca.  CAA 0 issue "letsencrypt.org; accounturi=https://acme-v02.api.letsencrypt.org/acme/acct/123456789; validationmethods=dns-01"
yourcompany.ca.  CAA 0 iodef "mailto:security@yourcompany.ca"

Before you turn on CAA: your web host, Microsoft 365, your content delivery network (CDN) or a marketing tool may issue certificates on your behalf. Take inventory first, or the next automatic renewal will fail and your site will show an error.

NeoTech’s recommendations, on top of Google’s

A hijacked national registry is out of your hands. But the same scenario (someone changes your DNS and gets a certificate in your name) happens far more often through your registrar account or your DNS provider. The measures below don’t come from Google: they are our recommendations for SMBs.

MFA on your registrar and DNS provider accounts. Ideally a physical security key or an authenticator app, not a text-message code. That account is worth as much as your website and your email.
Registrar lock and, where offered, registry lock. The first blocks unauthorized transfers and changes; the second requires manual verification before any name server change. It won’t protect against a compromised registry, but it closes the most common door.
DNSSEC where your registrar and DNS provider support it. It signs your DNS answers and makes tampering in transit harder. To be clear, it doesn’t protect against a compromise of the registry itself, but it’s part of good hygiene.
An inventory of your domains, with who has access, expiry dates and auto-renew turned on. Forgotten old domains are easy targets.
A recovery email address that doesn’t depend on the domain itself. If your domain is hijacked, you still need to be able to reach your registrar.

Has your web provider had an incident recently? Our article on the questions to ask your web host after the Pantheon incident pairs well with this list. An unmonitored domain is also one of the 5 signs your SMB is an easy target.

What about your employees and the padlock?

This message is worth repeating to your team: the padlock means “encrypted connection”, not “honest site”. Most phishing sites have a padlock too. Keep browsers up to date (that’s how blocks like Chrome’s reach you), take certificate warnings seriously instead of clicking past them, and open sensitive sites (banking, Microsoft 365) from a bookmark rather than from a link you received.

How NeoTech can help

For SMBs in Laval, Montreal and the North Shore, we can inventory your domains, secure access to your registrar with MFA, review your CAA records and set up Certificate Transparency monitoring. Our automated 24/7 monitoring with an on-call technician response helps you react quickly when something changes. See also our cybersecurity services.

Book your free cyber check

Not sure who controls your domain’s DNS, or whether a certificate has been issued in your name without your knowledge? In a short meeting, we review it with you and prioritize the fixes.

👉 Book your free cyber check

Call us at 438-476-2322 or email info@neotechcloudsolutions.com.

Sources

Photo: JJ Ying (Unsplash), via Wikimedia Commons, CC0.