Control of the registry behind a country's internet domains brings more than the power to redirect websites. In a notice published on October 6, Google said attackers had broken into the third party operators of three national top level domains, those of American Samoa (.as), Ghana (.gh) and Sierra Leone (.sl), altered authoritative DNS records for domains beneath them, and used that position to get certificate authorities to issue HTTPS certificates for a number of Google domains and for names owned by other organizations.
The certificates were genuine. Public certificate authorities issued them after the attackers passed the standard ownership checks, which is why Google said it had no reason to believe the issuers did anything wrong. Chrome blocked the certificates through CRLSets, its emergency revocation list, and Google had the issuers revoke them. Let's Encrypt confirmed it had issued, and then revoked, certificates covering Google and YouTube names. As of the October 6 notice, Google had not said who was behind the hijacks, how the registries were breached, how many certificates were involved, or whether any had been used against visitors to the affected sites.
What a certificate authority actually checks
Before issuing a certificate for a domain, an authority has to confirm that the applicant controls it, usually by having the applicant publish a supplied value in a DNS record or on a web page and then looking it up. The check assumes the DNS hierarchy is telling the truth, and at the top of that hierarchy for every name under the three endings sits the registry, which publishes the name servers for each domain in its zone.
An intruder who controls the registry can point a domain's name servers at infrastructure of their own, feed the authority's lookup the value it expects, and walk away with a certificate no browser can tell apart from a legitimate one. Since 2025, publicly trusted authorities have had to corroborate their checks from several network vantage points, a CA/Browser Forum rule aimed at routing attacks that mislead a single vantage point, but every vantage point receives the same forged answer when the authoritative data itself has been rewritten. CAA records, which let a domain owner declare which authorities may issue for it, sit in the very zone the attacker controls. DNSSEC is no guarantee either: the registry publishes the delegation signer records that anchor a domain's signatures, so an attacker at that level could sign a forged chain that validates correctly.
How the certificates were found
The attackers could not hide what they had minted. Every certificate that Chrome trusts by default has to be disclosed in public Certificate Transparency logs, which are append only and built on Merkle trees. Google said that after its first round of blocking, log data pointed to further victims of the same hijacks, including household name brands and heavily used web services, and that it blocked those certificates too and alerted the companies where it could. The logs have recorded more than 2.5 billion certificates since 2013, and a domain owner watching the entries for its own names gets close to a real time alert whenever one is issued.
Logging is detection, not prevention, and the blocking had limits of its own. Chrome does not normally perform online revocation checks; CRLSets, a list the browser downloads in the background, are its emergency tool. Google warned that this protects Chrome users only and that it could not promise it had identified every affected domain.
What domain owners can do
Google's advice puts the burden on domain owners, because only they know which authorities and certificates are legitimate for their names. Its advice, plus a change the industry had already scheduled, comes down to three things:
- Monitor Certificate Transparency for the whole domain portfolio, including parked and regional country code names, and go through entries from late September onward for issuance nobody requested.
- Publish restrictive CAA records, ideally bound to specific ACME accounts and validation methods, and watch NS and DS records for changes. CAA cannot stop issuance during a hijack, but authorities may reuse a completed validation for later certificates, and a tight policy restored afterwards stops an attacker from turning that cached check into fresh certificates. Registry lock, where offered, adds a change control step before a delegation can be altered.
- Prepare for shorter lifetimes. A schedule the CA/Browser Forum approved in April 2025 shrinks maximum certificate validity from 398 days to 47 days in stages between March 2026 and March 2029, and cuts the reuse of validation data from 398 days to 10 days, limiting how long a fraudulently obtained certificate or a cached check stays useful.
None of that would have stopped the first issuance in late September. The three registries fell within roughly a week of one another, and as of early October nobody had publicly explained how they were breached, which leaves every organization with a name under a small national registry depending on a layer of the system it has probably never audited.
