On 6 October 2026, Google disclosed that attackers had hijacked three country-code top-level domain (ccTLD) registries: Ghana's .gh, Sierra Leone's .sl and American Samoa's .as. By altering authoritative DNS records, they obtained unauthorized HTTPS certificates for Google domains and for other organizations' domains. Google's own systems were not compromised. iTnews counted 32 certificates in public Certificate Transparency (CT) logs issued between 22 and 27 September, mainly from Let's Encrypt and Sectigo's ZeroSSL, plus one from Cloudflare's CA. Google itself did not give a certificate count or name the issuing CAs.
The incident is a reminder of how internet trust is built. Browsers trust a certificate because a certificate authority (CA) checked that the applicant controlled the domain. That check usually reads DNS. Whoever controls a registry's DNS controls the check.
The case for stronger rules
The argument for intervention is serious. A ccTLD registry is critical infrastructure, and a single compromise let attackers pass validation for names they had no claim to. The IANA record for .gh lists Network Computer Systems Limited in Accra as manager and, at the time of writing, shows an "Insecure Delegation": no DNSSEC DS record is published. Regulators could reasonably say that operators of national namespaces should meet baseline security standards, such as DNSSEC signing, mandatory multi-factor authentication and breach notification, and that governments should enforce them.
That argument is right about the problem. It is weaker on the remedy.
Why mandates are the wrong lever
The operators involved are small, and the attack surface goes beyond the registry. Google reports the ccTLDs were run by third parties, and it has not said how they were compromised. iTnews could not get a response from the registry operators. Without knowing the intrusion path, we cannot say whether DNSSEC or any specific control would have stopped it. A national law requiring DNSSEC would also be hard to enforce across more than 200 ccTLDs with very different resources. It might push cash-strapped operators in Africa and the Pacific to outsource to larger providers, which concentrates the risk it was meant to reduce.
What has worked is the layered, voluntary and technical response visible in this incident:
- Public transparency. CT logs let anyone see every certificate issued. That is how the fake certificates were found, and it is how Google identified other affected brands beyond its own.
- Fast browser-side revocation. Chrome blocked the certificates through CRLSets. Firefox covers revoked certificates through CRLite, which downloads a compact local list built from CT data, so it needs no live query to a CA.
- CA cooperation. Google worked with the issuing CAs to revoke the certificates and says it has no reason to believe the CAs did anything wrong.
The gap that remains
The weak point is uneven protection. Google says Chrome users need take no action, but it also warns that Chrome's interventions do not reliably protect non-Chrome users, and that it cannot guarantee its analysis found every affected domain. Revocation is only as good as the client that checks it. Users of browsers or apps that do not check revocation data may stay exposed until the certificates expire.
This is a governance gap, but a narrow one. It is about whether every major client implements revocation checking the way Chrome and Firefox do. It does not call for a new treaty.
What domain owners and CAs can do now
Google recommends that organizations monitor CT logs across all their domains, including parked and regional ones, and publish restrictive DNS Certification Authority Authorization records. Under RFC 8659, CAA lets a domain holder name the CAs allowed to issue for it. Google adds that CAA bound to specific ACME accounts and validation methods helps, though it cannot stop issuance during an active hijack, because the attacker controls the DNS that holds the record.
For CAs, the more consequential change is on the validation side. Google says it is pursuing shorter certificate lifetimes and limits on how long a completed domain control validation can be reused, through the Chrome Root Program. This matters because a cached validation could let an attacker mint certificates after the hijack ends. Shortening both windows limits the damage from any registry compromise without regulating registries.
History says this is a recurring pattern
The attack fits a long line. iTnews recalls the 2011 DigiNotar breach, which produced 531 fraudulent *.google.com certificates, as well as Sea Turtle in 2019 and a 2012 breach of the .pk registry. Each time, the ecosystem answered with transparency and better revocation, not a licensing regime. The result is that this incident was detected from public logs within days and contained by browsers and CAs.
A proportionate response
Policymakers should resist treating this as a case for mandates on registries. Better targets are ones that scale: funding technical assistance for small ccTLD operators through bodies such as ICANN and regional registry associations, encouraging DNSSEC adoption and incident disclosure as shared norms, and pressing browser vendors and app developers to ship revocation checking. The open internet's trust model survived this attack because it is observable and replaceable in parts. Regulation that freezes today's architecture would weaken the property that made the response possible.
The open questions are real: how the registries were breached, whether any fake certificate was used against real users, and how many unreported victims exist. Until Google or the registries answer them, calls for sweeping rules are premature, while calls for CT monitoring, CAA records and revocation support are not.