Three hijacked country registries minted counterfeit TLS certificates for Google

6 October 2026. Google disclosed that attackers had compromised three country-code top-level domains — .gh (Ghana), .sl (Sierra Leone) and .as (American Samoa) — and used that control to mint counterfeit TLS certificates for Google and several other major brands. No compromise of Google’s own systems or of any certificate authority. The week of 29 September. Chrome’s security team says it learned of the hijacks “last week,” i.e. in late September. Why it matters: HTTPS trust rests on a single link — domain control validation — and that link broke not at a software vendor, but at national registries on which thousands of sites depend.

What actually happened, and what it does not mean

A TLS certificate binds a domain name to a public key through a signature. Issuance depends on one check: domain control validation (DCV), in which a certificate authority asks the applicant to prove control of the domain, usually by publishing a DNS record or answering on a URL. Control the DNS, and you pass DCV without breaking anything.

That is exactly what unfolded. By seizing the .gh, .sl and .as registries, the attackers were able to modify authoritative DNS records and nameserver delegations for the domains they chose. With DNS under their control, they completed certificate requests that were perfectly valid from a procedural standpoint. Google put it plainly: “we have no reason to believe the Certification Authorities (CAs) that issued the impacted certificates did anything wrong.”

The result is not a cryptography flaw. It is a trust flaw: a forged certificate lets an on-path attacker cryptographically impersonate a site — the modern equivalent of a fake passport. Google did not say how many certificates were issued or name every victim, but it noted that “several Google domains” and “several leading global brands and widely used online services” were affected.

The mechanics of domain validation, step by step

To issue a certificate, an authority verifies domain control by one of three methods: answering on a dedicated URL (HTTP-01), publishing a TXT record in the zone (DNS-01), or receiving an approval email at an address on the domain. The last two lean on DNS. An attacker who controls a domain’s records can therefore satisfy validation without owning any of the domain’s servers: request the certificate, publish the expected TXT, receive the certificate, then erase the trace. That is what makes a registry compromise so severe — it yields DNS control of thousands of domains at once, without touching any of them individually. Certificate Transparency logs, for their part, record every issued certificate publicly and near-immutably — which is why they are both the detection tool and the evidence that lets you measure the scope of a hijack after the fact.

Why the browser is not enough

Chrome moved fast: it immediately blocked the unauthorized certificates via CRLSets, coordinated revocation with the issuing CAs, and then used Certificate Transparency (CT) logs to proactively identify other victims. For a Chrome user, nothing to do — blocking is automatic.

But Google warns that this protection has limits. “Browser-side intervention should not be relied on to protect your users,” the team wrote. Two reasons. First, Chrome’s analysis cannot guarantee it found every affected domain; an undiscovered certificate remains dangerous. Second, Chrome’s interventions do not protect users of other browsers, nor clients that are not browsers at all — API clients, agents, mobile apps, and command-line tools that verify certificates against their own trust store.

The historical parallel is instructive. In 2011, the compromise of the Dutch authority DigiNotar let attackers mint forged certificates for google.com and more than 200 other high-traffic domains, used against at least 300,000 people linked to Iran. The lesson of both 2011 and 2026 is the same: DCV is the weakest link in the chain, and it is weaker still because it leans on DNS, which itself depends on registries and registrars rarely treated as attack surfaces.

The two countermeasures that remain in the domain owner’s hands

Google offers two concrete recommendations, and neither depends on the browser.

The first is CT log monitoring. Every trusted-by-default certificate accepted by Chrome must be published in a public Certificate Transparency log. Monitoring those logs across your whole portfolio — including parked domains and regional ccTLDs you registered and forgot — gives near-real-time alerting on every issuance. If you operate a domain under .gh, .sl or .as, Google advises reviewing recent CT log entries for unexpected issuance now.

The second is publishing restrictive CAA records (Certification Authority Authorization, RFC 8659), ideally with ACME account bindings to restrict issuance to specific accounts. The nuance matters: CAA cannot prevent issuance during an active DNS hijack — the attacker controls DNS, so they can rewrite CAA too. But it protects after DNS control is restored: because CAs are allowed to cache and reuse completed DCV checks, a restored restrictive CAA policy stops an attacker from replaying cached validation to mint new certificates once the hijack ends.

Where this is heading

The incident fits into a broader hardening of the HTTPS ecosystem. Google explicitly cites reducing certificate validity and DCV reuse — ballot SC081v3 of the CA/Browser Forum — along with Chrome’s new quantum-safe root program. The logic is simple: the longer a certificate lives and the longer a validation can be reused, the wider the exploitation window after a transient DNS hijack.

At the network level, the episode confirms that Web PKI security is decided as much at registries as at certificate authorities. A ccTLD registry is not an ordinary vendor: it is the trust root of an entire namespace, and its compromise propagates to every domain that lives under it, none of which did anything wrong.

What it means for network operators

For a network operator, the incident is a signal that DNS security is a perimeter problem, not a namespace problem. The attackers did not touch Google’s infrastructure; they walked in through the registries of three small countries. Operators who run their own resolvers cannot detect this class of attack by watching their own logs — the forged certificates were minted upstream, in registries and certificate authorities they do not control. What they can do is treat Certificate Transparency monitoring and CAA publication as part of the same discipline as BGP and DNSSEC hygiene: a domain’s trust depends on infrastructure owned by others, and the only early warning is the public record of issuance.

Verdict

If you own domains — especially a large portfolio with regional ccTLDs or parked names — set up CT log monitoring covering the entire portfolio this week, and publish restrictive CAA records with ACME account bindings. It is the only defense that stays under your control when DNS is hijacked. If you operate a domain under .gh, .sl or .as, the check is not optional: review recent CT log issuances immediately. If you depend on a non-browser client — an API, an agent, a mobile app — do not count on Chrome’s blocking: audit your clients’ trust stores and treat any unexpected certificate on your domains as an incident. The lesson in one line: the green padlock is a promise, not a proof — and its strength depends on registries you do not control.

References

• Google — Chrome’s Response to Recent ccTLD Registry Hijacks (6 October 2026)
• Ars Technica — Hackers obtain counterfeit TLS certificates for Google and other large services (October 2026)
• RFC 8659 — DNS Certification Authority Authorization (CAA) Resource Record
• RFC 8657 — CAA Record Extensions for Account URI and ACME Method Binding