In late September, attackers took control of three country-code top-level domain registries and used that control to get browser-trusted certificates for Google domains and other large brands. Google's Chrome security team disclosed the incident on 6 October 2026. It affected Ghana's .gh, Sierra Leone's .sl and American Samoa's .as. The certificates have since been revoked, and Google says its own systems were not compromised. The episode matters beyond those three registries because it shows how the web's trust model can fail without any CA misbehaving.
What happened
According to Google's post, the attackers modified authoritative DNS records and obtained unauthorised HTTPS certificates for several Google domains and for other organisations' domains. Google says it has no reason to believe the issuing certificate authorities did anything wrong. The reason is simple: automated domain validation asks whether the requester can control DNS or web content for a name. If you control the registry, you can answer yes for every name beneath it.
iTnews reported the timeline. Ghana's registry was compromised on 22 September, Sierra Leone's on 25 September and American Samoa's on 27 September, with most certificates for each issued inside a 90-minute window. iTnews counted 32 certificates issued to the attackers by checking public Certificate Transparency logs against Chrome's blocklist. It reported free wildcard certificates from Let's Encrypt and Sectigo's ZeroSSL, plus one from Cloudflare's CA. Google has not said how the registries were breached, and iTnews said none of the three registry operators responded to its requests for comment.
The strongest case for a heavier response
The case for tougher rules is a serious one. Certificates are issued in seconds by automated systems, so a short compromise window is enough. Registries are often small organisations holding critical infrastructure. Google itself warns that Chrome's interventions do not reliably protect users of other browsers or clients. Anyone who wants mandatory security standards for registries, or a formal international audit regime, is responding to a real gap.
But that case runs into a practical problem. Registries are sovereign or quasi-sovereign operators. A top-down mandate from ICANN or a treaty body would be slow to negotiate and hard to enforce, and the open, multistakeholder governance that has kept the internet interoperable would be put at risk. Registries are not the only weak point in any case. Registrars, DNS hosting providers and CAs all sit in the same chain.
What worked, and what the incident shows
The detection and response model worked as designed. Certificate Transparency, an open, auditable log of issued certificates, let Google and journalists find the bad certificates in public. Chrome blocked them through CRLSets, and Google used the logs to find other affected brands and block those certificates as well. Privacy Guides notes Firefox handles revocation through its CRLite mechanism.
The weakness is the gap between issuance and revocation. During that gap, a valid certificate plus control of DNS allows a convincing man-in-the-middle attack on anyone whose client does not check revocation well. That is why the most useful fixes shrink the window of exposure rather than adding bureaucracy.
Proportionate fixes already exist
Three measures stand out.
- Restrictive CAA records with account binding. RFC 8657 lets a domain owner restrict issuance to specific CA accounts and to specific validation methods. Google recommends exactly this. It does not stop issuance during an active hijack, but it stops attackers from reusing cached validation after control is restored. It only works where the CA supports the parameters.
- Certificate Transparency monitoring. Google advises owners to watch logs across their whole portfolio, including parked and regional ccTLD names. A company that owns google.com but ignores google.sl has an unwatched door.
- Shorter validity and validation reuse. The CA/Browser Forum's Ballot SC-081v3 phases in reductions from March 2026 to March 2029. Maximum certificate validity falls from 398 days to 47 days, and reuse of validation data for subject alternative names falls from 398 days to 10 days. Shorter reuse means a validation obtained during a brief hijack goes stale quickly.
None of these requires a new law, and all of them are voluntary, technical and interoperable. Their cost falls mainly on large operators who can afford it. The less obvious cost falls on small registries and domain owners, who must now automate monitoring.
Where policy should focus
Governments should resist two temptations. The first is to treat this as a reason to force certificate authorities to restrict issuance for ccTLDs, which would punish Ghana, Sierra Leone and American Samoa for being victims. Those registries now have a credibility problem through no fault of the domain holders beneath them. The second is to use the incident to justify state control over certificate trust, a recurring theme in national proposals to mandate government-approved root certificates, which would trade a rare criminal risk for a permanent surveillance one.
Useful policy is quieter. Fund registry security support and incident-sharing, especially for small and developing-country operators. Encourage DNSSEC and registry-lock adoption. Require prompt public disclosure when a registry is compromised, because Google had to piece this one together from certificate logs rather than hearing it from the registries. And give CAs and browsers room to keep tightening validation without legal obstacles.
History points the same way. iTnews notes earlier cases of registry and CA compromise, including the 2011 DigiNotar breach and the 2012 compromise of Pakistan's .pk registry. Each time, the ecosystem answered with transparency and shorter-lived trust rather than central control. This incident should get the same answer, with one added lesson: the registries at the bottom of the namespace are part of critical infrastructure and deserve support, not blame.