Real Certificates, Fake Control: Hijacking ccTLD Registries to Mint Trusted TLS Certs for Google

In late September 2026, someone obtained genuine, browser-trusted TLS certificates for Google domains. They did not breach Google. They did not breach a certificate authority. They did not forge anything or break any cryptography. Every certificate was issued correctly, by the rules, to someone who proved control of the domain.

They proved it by hijacking the registries behind three country-code top-level domains and rewriting the DNS. On 6 October 2026 Google published its account and Chrome's response. The interesting part is not that it happened; it is that nothing in the certificate system malfunctioned. The system did exactly what it was designed to do, and that was the problem.

//What Happened

Attackers gained control at the registries operating three ccTLDs: .gh (Ghana), .sl (Sierra Leone) and .as (American Samoa). How they compromised the registries themselves has not been disclosed by anyone.

With registry control comes control of authoritative DNS for names under those domains. The attackers modified DNS records for targeted names and requested certificates. Let's Encrypt was among the issuing authorities; one of its engineers confirmed on the community forum that certificates for Google and YouTube were issued and have since been revoked, and that they appear in Let's Encrypt's certificate revocation lists. Google described the affected names as several of its own domains plus domains belonging to other organisations, which it has not named.

//Why the CA Did Nothing Wrong

A domain-validated certificate answers exactly one question: does the requester control this domain right now? That is the entire assurance a DV certificate provides. It says nothing about who the requester is, only that at the moment of issuance they could demonstrate control.

The only way to demonstrate control, in practice, is through DNS and the services reachable via DNS. Add a TXT record the CA asks for. Repoint a name to an HTTP server the CA will fetch from. Answer a TLS challenge on the host the name resolves to. Every one of these methods resolves through authoritative DNS. So the whole chain of trust reduces to a line: registry, then authoritative DNS, then domain-control validation, then certificate. Each link trusts the one above it.

Compromise the registry and you own every link below. The attacker did not need to defeat the CA's checks; they satisfied them legitimately, because from the CA's vantage point the requester genuinely did control the domain. This is the same structural lesson as other DNS-trust failures: a surprising amount of internet security is DNS integrity wearing a different hat.

//CAA Did Not Help, and Could Not

The real google.sl carried a CAA record - a DNS record that tells CAs which authorities are allowed to issue for the name. It pinned issuance to pki.goog, Google's own certificate authority. And a Let's Encrypt certificate was issued anyway.

There is no contradiction. CAA is a DNS record, and the attacker controlled the DNS. You can delete or rewrite the CAA line as easily as any other record before asking for the certificate. CAA defends against a CA issuing without authorisation; it does nothing against an attacker who has already taken the zone, because they simply rewrite the authorisation first. A lock on the door does not help when the attacker owns the building.

//Certificate Transparency Caught It - Afterwards

Every publicly trusted certificate must be logged to append-only Certificate Transparency logs. That requirement is the only reason this was discovered. Google, and any domain owner monitoring CT for its own names, could see certificates it never requested appear in the logs.

That is worth sitting with. In the entire chain, the one effective control is CT - and it is a detection, not a prevention. It fires after the certificate exists, not before. Chrome then revoked and blocked: Let's Encrypt revoked the certificates, Chrome blocked the Google ones via CRLSets, and Google used CT to find other affected organisations and block theirs too. CRLSet protection is specific to Chrome; other browsers depend on ordinary revocation checking, which is weaker.

So the defensive reality is detect-and-contain, not prevent. CT catches it, revocation and CRLSets clean it up, and the window between issuance and discovery is the exposure. For anyone who relies on the certificate system - which is everyone - that is the honest shape of the guarantee.

//What Defenders Can Actually Do

Monitor Certificate Transparency for your own domains. It is the control that worked here. If a certificate appears for your name that you did not request, you want to know in minutes, not when a customer reports a phishing site.

Set restrictive CAA with ACME account binding. Google's own recommendation is CAA records that pin not just the CA but a specific ACME account (RFC 8657). Google is candid about the limit: CAA cannot prevent issuance during an active DNS hijack, because the attacker can rewrite it, and CAs may cache and reuse a completed validation. It raises the bar for the ordinary case and does nothing for the registry-compromise case. Both of those things are true at once.

Treat registry and registrar security as tier-zero. The uncomfortable conclusion is that the integrity of your TLS depends on organisations you do not control and rarely think about - the registry operating your TLD, your registrar, your DNS provider. This incident hit ccTLD registries specifically. Registrar account takeover would achieve the same thing for any domain.

//Sourcing and Uncertainty

The event, the three ccTLDs, the root cause (registry/DNS compromise rather than CA misissuance), the Let's Encrypt issuance and revocation of Google and YouTube certificates, the Chrome CRLSet and CT response, and the CAA guidance all come from Google's security blog and the Let's Encrypt engineer's forum statement. The two revoked google.sl certificates dated 25 September were independently visible in Certificate Transparency.

What could not be confirmed against a primary source. The exact certificate count and the "seven domains" figure - Google said only "at least," and explicitly that it could not guarantee completeness. ZeroSSL as a second issuing CA, which appears only in one outlet's table with no ZeroSSL incident report to support it. The twelve SHA-256 fingerprints circulating, which are not reproduced here because they could not be reconfirmed. The specific validation method the attackers used - DNS, HTTP or otherwise - was not stated by anyone, which is why this piece says all DNS-dependent validation collapses rather than naming one. And the initial access vector into the registries, which no source explains, along with whether any certificate was used in an actual interception.

The interpretation is mine: that the central fact is the system working as designed rather than failing, that CAA offering no defence here is a feature of where the compromise sat rather than a flaw in CAA, and that Certificate Transparency being a detection rather than a prevention is the practical limit worth internalising.