The Padlock Was Valid, the Site Was Fake: the .gh, .sl and .as Registry Hijacks Explained

On October 6, 2026, Google’s Chrome security team published a short post with a dry title and an alarming content: attackers had taken control of three country-code domain registries, Ghana’s .gh, Sierra Leone’s .sl and American Samoa’s .as, changed authoritative DNS records, and obtained valid HTTPS certificates for Google domains and for “several leading global brands” it did not name. Anyone who landed on one of the fake sites would have seen a browser padlock with nothing wrong about it.

The incident is worth understanding properly, because it sits at the exact point where most people’s mental model of web security is wrong. The padlock does not mean “this is the real site”. It means something much narrower, and in late September the gap between the two became an operational attack.

One definition carries this whole page: a domain-validated certificate proves one thing only, that at the moment of issuance the applicant controlled the domain’s DNS. When the registry above the DNS is stolen, the thief is, for every automated check on earth, the owner.

What Happened to .gh, .sl and .as?

A country-code registry is the organization that runs the master database for everything under its two-letter domain: .gh is operated by Network Computer Systems in Accra, .sl by the telecom Sierratel, .as by the AS Domain Registry. Compromise that database and you do not need to hack any individual website, because you can redelegate any name under the TLD to servers you control.

That is what happened, one registry at a time. Certificates appeared in public logs for .gh names on September 22, .sl on September 25 and .as on September 27, which reads like a crew working down a list. Google says the attackers “modified authoritative DNS records and obtained unauthorized HTTPS certificates covering several Google domains, as well as domains belonging to other organizations”, and that its own systems were not touched.

A remarkable amount remains undisclosed: how the registries were breached, who did it, whether any certificate was used against real users, and the full victim list. None of the three registry operators had published a statement as of this writing. We say “not disclosed” where that is the state of things, and so should every account you read.

How Did Attackers Get Valid Certificates for Google Domains?

By asking politely. The Hacker News, working from the public Certificate Transparency record, counted at least 12 certificates covering 7 Google and YouTube domains, google.com.gh, google.sl, google.as and variants among them: 11 issued by Let’s Encrypt and 1 by ZeroSSL, all domain-validated. A Let’s Encrypt staff member confirmed the issuance and the revocations on the project’s forum.

Here is the uncomfortable part: the CAs followed their rules. Google itself wrote that it has “no reason to believe the Certification Authorities (CAs) that issued the impacted certificates did anything wrong”. Domain validation asks the applicant to prove control of the domain’s DNS, typically by publishing a record. The attackers were the DNS. Every automated check they faced, they passed honestly, in the narrow sense that machines understand honesty.

One detail shows what vigilance looks like at this layer: in the logged records reviewed, going back to at least September 10, every other certificate for google.com.gh, google.sl and google.as had come from Google Trust Services, Google’s own CA. Twelve certificates from two unrelated CAs was itself the anomaly, sitting in a public log, waiting for someone to look.

Who Caught It, and How Was It Stopped?

Three mechanisms, in order of speed.

First, Certificate Transparency made the certificates visible at all. Since April 30, 2018, Chrome rejects any certificate not disclosed in public CT logs, so an attacker who wants a certificate that works in the world’s most used browser must also hand the world a signed confession that it exists. The ecosystem’s public counter stands at over 2.5 billion logged certificates, and Let’s Encrypt alone crossed ten million certificates issued in a single day in late September 2025; finding 12 bad ones in that haystack is exactly what the log infrastructure is for.

Second, Chrome blocked the certificates through CRLSets, its emergency blocklist, which ships through the browser’s component updater and takes effect without an update or restart. Chrome’s security team has argued for years that online revocation checks fail exactly when you need them, since the attacker in the middle can block the check itself; the blocklist travels with the browser instead. Google then mined CT data for further victims, blocked those certificates too, and says it contacted the affected organizations where it could.

Third, the slow path that covers everyone else: the CAs revoked all 12 certificates, the two .gh certificates and the single ZeroSSL certificate on September 26, the other nine on October 1. The shortest window between a certificate appearing in the log and dying was about a day and a half; the longest was nearly a week. Google’s own honesty clause deserves quoting: “we cannot guarantee that our analysis identified every affected domain, nor do Chrome interventions reliably protect non-Chrome users.”

Would DNSSEC or CAA Records Have Prevented This?

This incident is the cleanest demonstration in years of what these two acronyms do and do not buy you.

DNSSEC first. Checking the published root zone: .gh and .sl are not signed at all, which puts them among the many ccTLDs that never deployed DNSSEC, a technology with 99 percent registry adoption in Europe but 65 percent in Africa. And .as is signed, and was hijacked anyway. DNSSEC lets a resolver verify that an answer matches what the registry published. When the registry itself is hostile, it publishes the attacker’s data, keys and all. The signature on a lie is still a valid signature.

CAA records, which let a domain owner declare which CAs may issue for it, have a subtler shape. During the hijack they are useless, because the CAA record lives in the very DNS the attacker controls; the CAA standard itself concedes an attacker who can edit DNS can remove the record. After the hijack they matter a great deal, because CAs may reuse a completed validation for up to 200 days under the current CA/Browser Forum rules, a window that falls to 100 days in March 2027 and 10 days in 2029, so an attacker who lost the DNS could still mint fresh certificates from cached checks. By October 7, all seven known Google victim domains carried CAA records naming only Google’s own CA. That is the lock you fit after this particular burglary, and it is a real one.

Has This Happened Before?

Registry and DNS-infrastructure attacks are a genre, not a novelty. The dated record:

There are 316 country-code TLDs among the roughly 1,400 domains in the root zone, each tied to a country or territory, each with its own budget, governance and security posture, and some run by private operators. Ghana’s own statutory domain authority has spent years in a public dispute over who should even operate .gh. The trust model of the web rests, in part, on the least funded of these organizations having a good security team.

What Would You Have Seen, and What Actually Protects You?

If you had been routed to one of the fake sites during the window, you would have seen nothing. A valid certificate, a normal padlock, no warning of any kind; as Ars Technica put it, possession of such certificates “allows attackers to cryptographically impersonate the affected infrastructure”. Whether anyone actually was routed there is one of the undisclosed facts.

What protected users was nothing a user did. The mandatory CT paper trail exposed the certificates, CRLSets killed them in Chrome with no action required, and revocation covered the rest. One more layer deserves mention: native apps that pin their keys. In the 2017 Togo case, Chrome’s pinning would have rejected the rogue google.tg certificate regardless, and Google’s own apps and many banking apps still pin today. Defense in depth is not a slogan here; it is a specific stack, and in late September every layer of it was load-bearing.

Does a VPN Protect Against This?

An honest security page answers this question precisely, so here is the precise answer: no for this attack class, yes for its more common cousins, and knowing which is which is the whole game.

A VPN does not participate in TLS. Your browser validates certificates against its trust store identically on any network, and these certificates were valid. Worse for any tool downstream of DNS: the attackers poisoned the authoritative records at the registry, so every honest resolver on the planet, including a VPN provider’s, served the attacker’s answers. No VPN, ours included, would have blocked this. What stopped it was the CT, CRLSet and revocation pipeline above.

What a VPN does defend is your side of the connection. On a hostile local network, a rogue hotspot or a tampering ISP, the attacker sits between your device and the internet, injecting DNS answers or redirecting traffic. A VPN moves your DNS resolution and your traffic path inside an encrypted tunnel, as the EFF’s guide puts it, hiding your traffic from “your ISP and the local network owner (like a coffee shop or hotel)”. That is the common, everyday attack surface, the one we cover in our guides to VPN encryption and public Wi-Fi security, and it is precisely the layer the registry attackers never needed to touch. The two protections are complementary, not interchangeable, which is also why we keep a separate honest page on what sites can still see with a VPN on.

What Should Domain Owners Do Now?

Google’s advice to organizations is two steps, and it applies just as well to a company with three domains as to one with three thousand. Monitor Certificate Transparency logs for every domain you hold, including parked and regional ones; the 12 rogue certificates sat in public logs for days, visible to anyone watching. And publish restrictive CAA records naming your CA, ideally with ACME account binding so even your own CA issues only to your account. The CA rulebook adds a third step: if an unrequested certificate appears, file a Certificate Problem Report, which the industry’s Baseline Requirements oblige the CA to investigate and report first findings on within 24 hours.

For everyone else, the takeaways are smaller but real. Keep your browser current, because the blocklist that saved Chrome users travels with it. Treat the padlock as what it is, a statement about encryption in transit, not about who is on the other end. And place each tool at its own layer: the certificate system authenticates sites, a VPN protects the path your traffic takes, and September’s incident needed the first to fail safe while the second was never in play.