Nobody Hacked Google. They Hijacked Three Countries' Domain Registries Instead.

What happened

On October 6, Google's Chrome security team published an unusually blunt disclosure: attackers had compromised the third-party operators of three country-code domain registries — .gh (Ghana), .sl (Sierra Leone), and .as (American Samoa) — modified authoritative DNS records, and used that control to obtain real, browser-trusted HTTPS certificates for Google and YouTube domains. Not just Google's, either: certificate-transparency data pointed at "several leading global brands and widely used online services," which Google would not name.

Two things the attackers did not do. They did not breach Google's systems — the company was explicit about that. And the certificate authorities that issued the rogue certificates did nothing wrong. Google said it has "no reason to believe" any CA acted improperly. That is the part worth sitting with: the machinery worked exactly as designed, and the padlock still ended up attesting to the wrong people.

The timeline, pieced together from Certificate Transparency logs by The Hacker News: the first two rogue certificates were logged on September 22 for google.com.gh and youtube.com.gh. On September 25, the attackers moved to .sl, collecting certs for google.sl, www.google.sl, google.com.sl, and youtube.sl. On September 27, they took google.as and youtube.as. In total: 12 certificates for 7 domains, logged one ccTLD at a time. Eleven came from Let's Encrypt, one from ZeroSSL. Every one was domain-validated — issued after a check that the applicant controls the domain.

That last detail is the whole story in miniature. The check passed because, during the hijack, the applicant did control the domain.

Why registry control beats every check below it

Here's how certificate issuance normally works. Before a CA signs a certificate, the applicant has to prove control of the domain — usually by publishing a DNS TXT record containing a random value the CA provides, or by serving a token from the site. No human reviews whether the request makes sense. Pass the check, get the certificate.

That system assumes one thing: DNS itself is trustworthy. A registry operator sits above all of it. Whoever controls a top-level domain's registry controls every nameserver delegation underneath it. According to Google's write-up, the attackers modified authoritative DNS records and nameserver delegations for selected domains inside the three namespaces, pointed them at their own infrastructure, and then sailed through domain-control validation like any legitimate owner. The CAs did exactly what the rules tell them to do.

With DNS control plus a valid certificate, the attacker could impersonate the real site over an encrypted connection and read the private data sent to it. The padlock in your browser would have been genuine: the connection was encrypted, the certificate was signed by a trusted CA, the identity it certified was simply wrong.

Compare that to DigiNotar in 2011, the last incident in this weight class: a breached Dutch CA minted rogue certs for google.com and 200+ other domains. That was a CA failure, and DigiNotar was expelled from the trust ecosystem. This time there is no CA to expel. The certificate system behaved correctly. The input it trusted was poisoned one level up.

What the response covers — and what it doesn't

Google's response was fast and layered, and it is still, by the company's own admission, incomplete. It blocked every rogue certificate it could find in Chrome through CRLSets, Chrome's emergency mechanism for blocking revoked or untrusted certificates in the background — no user action required. It worked with the issuing CAs to revoke the certificates so other browsers and apps are protected. A Let's Encrypt staff member confirmed on the CA's community forum on October 7: "certificates for Google and YouTube were issued, and have been revoked." Google also blocked the certificates it found for other affected organizations and contacted those companies where it could.

Now the honest gaps, which Google did not bury. First: "we cannot guarantee that our analysis identified every affected domain." The Hacker News only searched a small set of Google and YouTube names, so the real total is almost certainly higher. Second: Chrome's blocks do not reliably protect people using other browsers. Third: Google's post says nothing about whether any of the rogue certificates were actually used to intercept traffic or steal data, nothing about who did it, nothing about how the registries were compromised — and nothing about whether they have been secured.

And there is a quieter time bomb in the standards. Under the rules CAs follow, a completed domain-control check can be reused for up to 200 days — an attacker who passed validation during the hijack could request more certificates after it ends. The limit tightens to 100 days in March 2027 and 10 days in March 2029; Let's Encrypt already reuses checks for only 30 days and plans to cut that to 7 hours by 2028. The window is shrinking, but for now it exists.

What domain owners should do this week

Google gave domain owners two instructions, and the CA rules add a third. All three are worth following even if you don't run anything under .gh, .sl, or .as — because nothing in this story is specific to those registries.

Watch Certificate Transparency logs for your entire domain portfolio. Free monitors — Cert Spotter and ctlogs.dev, the tools reporters used on this story — alert you the moment a certificate is issued for a domain you own, including parked and regional names you forgot you registered. A certificate you didn't request is a problem; one for a domain you never use is a bigger one.

Publish a strict CAA record. A Certification Authority Authorization record is a DNS record that names the CAs allowed to issue certificates for your domain, and a CA must check it before issuing. Google recommends tying it to your own account at the CA where the CA supports it. All seven affected Google domains now carry a strict CAA record naming only pki.goog. But the honest limit: a CAA record cannot stop issuance during an active DNS hijack — an attacker who controls your DNS can remove or falsify it. It matters after you regain control, because it closes the validation-reuse window the standards leave open.

File a Certificate Problem Report. Under the Baseline Requirements, anyone can report a suspicious certificate to the CA that issued it, and the CA must investigate and report its first findings within 24 hours.

The counter-argument to all of this alarm is fair: Chrome blocked everything Google found, the named certificates are revoked, and there's no public evidence anyone actually intercepted a session. That may mean the real damage was near zero. But Google's own caution is the correct calibration — it cannot confirm it found every certificate, and non-Chrome users were never covered by its browser-side fix. The incident's significance isn't in a body count; it's in what it proved. The trust hierarchy of the web has a single point of failure at a layer most of us never think about: small, thinly resourced registry operators who hold the keys to every domain under their country's suffix. Nothing in the certificate machinery is designed to detect when that layer lies.

The padlock was real. The certificates were real. The trust was the only fake thing.