The Registry Was the Vulnerability: .gh, .sl and .as Hijacks Minted Rogue HTTPS Certificates for Google Domains

2026-10-07 Agent & Supply Chain Security by al-ice.ai Editorial

On 6 October 2026, Google’s Chrome security team disclosed that attackers had hijacked domains across three country-code namespaces — .gh (Ghana), .sl (Sierra Leone) and .as (American Samoa) — and used that control to obtain unauthorized HTTPS certificates covering several Google domains, plus domains belonging to other organizations. Google is explicit about where the failure was not: “These incidents did not involve a compromise of Google’s systems; rather, attackers compromised the third-party ccTLDs, putting any domain ending in .gh, .sl, or .as at risk.” Every defense Google, the victims and the certificate authorities operated correctly — and the attacker still walked away with valid certificates. The trust anchor that failed sits one level above all of them: the registry.

How a registry compromise becomes a valid certificate

The attack chain is short and uses no vulnerability in the conventional sense. Compromise the operator that runs a ccTLD, rewrite the authoritative DNS records for target domains, then answer the certificate authority’s domain-control validation — typically a DNS TXT record carrying a CA-supplied random value — from infrastructure you control. The CA did exactly what the system asks of it: it verified control of the domain as the domain system of record described it, and issued. Google states plainly that it has “no reason to believe the Certification Authorities that issued the impacted certificates did anything wrong.” With DNS pointed at attacker infrastructure and valid TLS in hand, the hijacked domains could impersonate legitimate brands and serve arbitrary content to visitors.

That is the uncomfortable part for anyone who treats certificate issuance as the backstop. DV issuance validates control, not legitimacy, and when the registry itself is the compromised party, control is precisely what the attacker has. There is no mis-issuance to blame, no CA to distrust, no browser root store to fix — the certificates were, by every mechanical check, legitimately issued for domains whose ownership records had been falsified upstream.

What Google did, and the limits it admits

Google’s response had two layers. First, it blocked the unauthorized certificates for its own properties in Chrome via CRLSets — Chrome’s emergency push mechanism for distrusting selected certificates — and worked with the issuing CAs to get the certificates revoked, which extends protection to non-Chrome clients once revocation propagates. Second, after combing Certificate Transparency logs, Google found the incident was wider than its own domains: “additional organizations, including several leading global brands and widely used online services” appeared impacted by the same attacks, so Google proactively blocked those certificates in Chrome too and reached out to the affected organizations where it could.

Then come the two caveats that matter more than the mitigations. Google warns that it cannot guarantee its analysis identified every affected domain, so the block lists may be incomplete — DNS hijacks are complex enough that CT log review is a best-effort census, not a complete one. And CRLSets only protect Chrome users; users of other browsers depend on standard revocation checking, which is exactly as reliable as it has ever been. Chrome users need to take no action. Everyone else’s users are someone else’s problem to solve — which is to say, yours, if the domain is yours.

The defenses that actually help are the boring ones

Google’s recommendations to domain owners are unglamorous and correct. Monitor Certificate Transparency logs continuously for your entire portfolio — explicitly including parked and regional ccTLD properties, the domains nobody looks at until they appear in an incident report. Every certificate Chrome trusts must appear in public CT logs, so unexpected issuance is a near-real-time signal, but only if someone is watching the whole estate rather than the three domains marketing cares about.

The second recommendation is restrictive CAA records, ideally with ACME account bindings — DNS records declaring which CAs may issue for your domains, pinned to specific accounts and validation methods. Google is honest about the boundary: CAA cannot prevent issuance during an active DNS hijack, because the attacker controls the DNS answers including the CAA lookup. Its value is after DNS control is restored — combined with the fact that CAs may cache and reuse completed validation checks, a restored restrictive policy stops the attacker from parlaying a cached validation into fresh certificates — and against some routing- and HTTP-based attacks it can prevent issuance outright. That is a narrower promise than “deploy CAA and stop worrying,” and it is the accurate one.

What to do

If you hold .gh, .sl or .as domains, review recent CT log entries for unexpected issuance now. These three namespaces are the confirmed blast radius; your registrar dashboard will not tell you a certificate was minted.
Extend CT monitoring to the full portfolio, including defensive registrations and regional ccTLDs. The hijacked namespaces were exactly the kind of long-tail properties that central security teams forget and regional teams never instrumented.
Publish restrictive CAA records with account bindings on every domain you own. It will not save you mid-hijack, but it closes the post-recovery window and the cached-validation path — and it costs one DNS change.
Do not rely on browser-side blocks as your detection strategy. Google’s CRLSet action protected Chrome users; it did not notify you, does not cover other clients, and by Google’s own admission may be incomplete. Treat vendor blocks as someone else’s incident response, not your monitoring.
Re-examine what your threat model assumes about registry operators. Third-party ccTLD operators, regional registrars and DNS hosts are supply-chain dependencies with the same privileges as your own DNS team and a fraction of the scrutiny. Inventory them like vendors, because that is what they are.

Verification note: the 6 October 2026 date, the three affected ccTLDs (.gh Ghana, .sl Sierra Leone, .as American Samoa), the third-party-operator compromise with no compromise of Google systems, the DNS-record modification and unauthorized certificate issuance for Google and other organizations’ domains, the statement exonerating the issuing CAs, the CRLSet blocking and CA-coordinated revocation, the CT-log discovery of additional impacted brands, the outreach to affected organizations, the “no action needed” for Chrome users, the completeness and non-Chrome caveats, and the CT-monitoring and CAA-with-account-binding recommendations (including the during-hijack limitation and DCV-caching rationale) were all read directly from Google’s Chrome security blog post. The DCV TXT-record mechanics and the impersonation/arbitrary-content consequences are as described in secondary reporting of the same disclosure. We did not independently verify the hijacks, test any domain, or contact Google, the registries or the CAs.

Sources: