Attackers did not need to breach Google, or any of the other organizations caught up in this incident. They needed DNS. Last month, someone compromised the third-party operators behind the .gh (Ghana), .sl (Sierra Leone), and .as (American Samoa) country-code top-level domains, changed authoritative DNS records, and quietly walked through domain control validation to collect trusted HTTPS certificates for several Google and YouTube domains plus a number of other global brands. Google disclosed the whole thing in a post about Chrome’s response to the ccTLD registry hijacks on October 6.
The mechanics are worth sitting with, because they expose how much of the web’s trust chain rests on a layer most organizations never think about. Certificate authorities validate domain control by checking DNS. If the DNS records for google.gh say an attacker controls the domain, the CA has no way to know anything is wrong, and it issues a perfectly legitimate-looking certificate. Ars Technica’s report makes the uncomfortable summary explicit: no Google systems were compromised, and the CAs that issued the certificates followed their own rules correctly. The weak link was the registry.
What the attackers actually got
The numbers are small but the pattern is not. Independent digging through Certificate Transparency logs found 12 domain-validated certificates covering seven Google and YouTube names, including google.com.gh, google.sl, and google.as. Eleven came from Let’s Encrypt, one from ZeroSSL, and staff on the Let’s Encrypt community forum confirmed the Google and YouTube certificates were issued and have since been revoked. iTnews counted 32 certificates issued across the campaign between September 22 and 27, several belonging to international brands outside Google, and noted that the issuers appeared to be free wildcard certificates from Let’s Encrypt and ZeroSSL, plus one from Cloudflare’s CA.
The issuance pattern suggests planning rather than opportunism. The .gh registry appears to have been compromised first, around September 22, then .sl on the 25th, then .as on the 27th, with most certificates minted inside a 90-minute window on each day. Nobody has said how the registries were breached, who did it, or whether any of these certificates were ever used to intercept real traffic. Google’s disclosure does not answer those questions either, which is itself worth noting: the biggest certificate incident this month has an unattributed attacker and an unknown scope.
Chrome blocked it, and that is both good and not enough
Chrome pushed emergency blocks through CRLSets, the browser’s built-in certificate blocklist, and worked with the issuing CAs to revoke everything so other clients would catch up. That is the system working as designed. It is also a reminder of where the design frays: CRLSets protects Chrome users, and browser-side intervention only covers one browser. Google says as much in its own post, warning that it cannot guarantee every affected domain was identified and that Chrome interventions do not reliably protect non-Chrome users.
The genuine success story here is Certificate Transparency. CT logs caught the extra issuance beyond Google’s own domains, revealing that other leading brands and widely used services had been hit by the same campaign, and Chrome blocked those proactively before any victim reported anything. This is the first big incident where CT monitoring functioned as the primary detection layer across an entire attack campaign, not just a research curiosity.
The history rhymes
None of this is unprecedented; it is an escalation along a familiar path. The 2011 DigiNotar breach produced 531 fraudulent certificates, including a wildcard for google.com that was used in a man-in-the-middle attack against roughly 300,000 users in Iran, and it bankrupted the CA. In 2019, Cisco Talos documented the Sea Turtle campaign, a state-sponsored operation that hijacked domains across 13 countries by compromising registrars. Each step moved the attack one level up the hierarchy: from the CA, to the registrar, and now to the registry itself. The trend line is not subtle. The higher you go, the fewer organizations control the outcome, and the more domains each compromise endangers.
What domain owners should actually do
Google’s guidance is concrete and applies whether or not you own a .gh domain:
- Monitor Certificate Transparency for every domain you own, including parked, regional, and ccTLD properties. CT gives near real-time alerts on unexpected issuance, and neglected namespaces are exactly where attackers hunt.
- Publish restrictive CAA records. CAA cannot stop issuance during an active DNS hijack, but it matters enormously afterwards, because CAs are allowed to cache completed domain validation checks. A restrictive CAA policy with ACME account bindings stops an attacker from minting fresh certificates from cached validation state once DNS control is restored.
- If you operate anything under .gh, .sl, or .as, review recent CT entries for your names now.
- File a Certificate Problem Report with the issuing CA when you find suspicious issuance. CA/Browser Forum rules make investigation mandatory.
After the disclosure, the affected Google domains all carried strict CAA records naming only pki.goog, Google’s own CA infrastructure. That is the shape of the fix: declare your CAs, bind them to specific accounts, and make cached validation worthless to the next attacker.
The part I keep turning over is the scope question. Google flagged “several leading global brands and widely used online services” as also impacted, and those names have not been published. Until they are, assume the campaign reached further than the CT analysis caught. If your domain portfolio includes anything you have not checked a CT monitor for, this is the week to fix that.