On October 6, 2026, Google disclosed that attackers exploited control of three country-code domain namespaces: Ghana’s .gh, Sierra Leone’s .sl, and American Samoa’s .as. They used that control to obtain unauthorized TLS certificates for several Google domains and, reportedly, domains belonging to other leading global brands and widely used online services. This is not a story about Google’s systems being breached. It is a story about something quieter and more consequential: the domain infrastructure that the entire certificate trust chain depends on.
How the Attack Worked
Controlling a domain’s DNS records is enough to pass the automated ownership checks that certificate authorities rely on.
Certificate authorities verify domain ownership through automated checks. Control a domain’s authoritative DNS records, and you can answer those checks convincingly, even without a legitimate claim to the domain.
Attackers altered authoritative DNS records inside the three compromised namespaces. That let them pass the domain-control validation that certificate authorities use to confirm ownership before issuing a certificate. A valid TLS certificate obtained this way can make an attacker-controlled server appear legitimate to any browser that trusts it.
Google said its own infrastructure was not compromised and that the certificate authorities involved apparently followed their established validation procedures. The failure was upstream, inside the domain registry infrastructure itself. That distinction matters: the certificate authorities had no evident basis to reject the requests, yet the outcome was unauthorized certificates.
For historical context, the 2011 DigiNotar breach produced fraudulent certificates for Google and more than 200 other domains. Those certificates were reportedly used against hundreds of thousands of users in Iran. That attack compromised a certificate authority directly; this one exploited DNS control instead, a different path to a similarly dangerous outcome.
What Google Did and What It Means for You
Chrome’s rapid certificate-blocking mechanism contained the immediate threat, but Google was candid about the limits of browser-side protection.
Chrome blocked the unauthorized certificates through CRLSets, a browser mechanism that distributes rapid certificate-blocking updates without requiring a full browser update. Google also worked with the issuing certificate authorities to revoke certificates covering its properties, extending protection to other clients that honor revocation data.
Chrome users did not need to take action for the specific certificates Google identified and blocked. Google was direct, however, about the limits of that response: browser-side blocking is not a complete defense.
Undiscovered certificates may still be active, and non-Chrome clients may not receive equivalent protection. The padlock, on its own, cannot tell you whether the DNS records behind a domain are still under legitimate control.
For domain owners and IT administrators, Google’s recommended defenses center on two practices. Continuous monitoring of Certificate Transparency logs can surface unexpected certificate issuances before they are exploited. Publishing restrictive Certification Authority Authorization records limits which certificate authorities are permitted to issue certificates for a domain.
CAA records cannot necessarily stop issuance during an active DNS hijack, but they narrow the window for additional damage once legitimate control is restored. Treat unexpected certificate issuances as a possible sign that something further up the chain has already been compromised. To stay safe, domain owners should audit their DNS configurations and CAA records regularly.
The Trust Problem No Padlock Can Solve
HTTPS confirms an encrypted connection; it does not confirm that every upstream layer of the trust chain remains under legitimate control.
HTTPS tells you your connection is encrypted. It does not tell you whether the domain registry, the nameserver operator, or the registrar standing behind that certificate is still under the right person’s control. The infrastructure that browsers trust runs deeper than any single lock icon can represent.
