In October 2026, Google disclosed that three country-code top-level domain registries had been compromised, allowing attackers to obtain valid HTTPS certificates for Google-owned domains. The affected ccTLDs were .gh (Ghana), .sl (Sierra Leone), and .as (American Samoa). Whilst Google's own infrastructure remained secure, the incident exposed a fundamental vulnerability in how domain certificate issuance is secured at the registry level.
How Registry Compromise Leads to Certificate Fraud
A country-code top-level domain registry is the authoritative source for all domain registrations under that suffix. When an attacker gains administrative access to a registry's systems—whether through credential theft, unpatched vulnerabilities, or social engineering—they can manipulate the DNS records and WHOIS data for domains within that TLD.
Certificate authorities (CAs) rely on domain control verification to issue TLS certificates. Traditional verification methods include DNS challenges, where the CA checks for a specific DNS record the domain owner has supposedly placed. If an attacker controls the registry's DNS infrastructure, they can respond to these verification requests on behalf of any domain under that TLD, convincing the CA that they legitimately control, for example, accounts.google.com.gh or similar constructs used in attack scenarios.
The attacker then possesses a valid, browser-trusted certificate for a domain they don't own. With this certificate, they can intercept encrypted traffic, perform man-in-the-middle attacks, and present a convincing replica of the target domain to users. The padlock icon in the browser—the visual indicator of HTTPS security—gives the fraudulent site an air of legitimacy.
Why Smaller Registries Are Vulnerable
Large, well-resourced registry operators (like those managing .com, .org, or country registries for wealthy nations) typically employ robust security practices: multi-factor authentication, intrusion detection, regular penetration testing, and incident response teams. Smaller registries, particularly those operated by developing nations or under-resourced government bodies, often lack these defences.
The .gh, .sl, and .as registries may have been selected precisely because they represent lower-security targets. An attacker conducting reconnaissance might identify outdated management interfaces, weak credentials, or unpatched systems more easily in these environments than in the infrastructures of major registries.
Implications for Domain Security and Infrastructure Operators
This incident has several implications for anyone managing domains or infrastructure. First, the compromise revealed that certificate pinning and stricter CA controls are not yet universally enforced. Google likely detected the unauthorized certificates through its own monitoring systems, but smaller organisations might not have equivalent detection capabilities.
For infrastructure operators, the lesson is stark: trusting a single DNS authority—especially one with weaker security posture—introduces systemic risk. If you operate domains under any ccTLD, particularly smaller or less-developed ones, consider these mitigations:
- DNSSEC validation. Enable DNSSEC signing and validation where the registry supports it. This cryptographically authenticates DNS responses, making it harder for attackers to inject forged records.
- Certificate transparency monitoring. Use CT log aggregators to watch for unexpected certificates issued for your domains. Services like
crt.shor dedicated monitoring tools alert you if a certificate is issued without your knowledge. - CAA records. Configure Certification Authority Authorization (CAA) DNS records that explicitly whitelist which CAs are permitted to issue certificates for your domains. Even if a registry is compromised, a CA honouring CAA records should refuse to issue unauthorised certificates.
- Registry selection. When choosing a domain suffix or registrar, evaluate the security posture and incident response reputation of the registry operator. Established registries with published security audits and SLAs are generally safer choices.
What Happened to Trust in DNS
The root cause is a structural one: HTTPS certificate issuance ultimately trusts DNS as the source of truth for domain ownership. If DNS is compromised, the entire chain of trust collapses. This is why DNSSEC, certificate transparency, and CAA records exist—to add layers of verification that don't rely solely on a potentially compromised registry.
The .gh, .sl, and .as compromise underscores that certificate security is only as strong as the weakest registry in the ecosystem. Infrastructure teams should assume that smaller or less-monitored registries will be targeted, and should implement defensive mechanisms—especially CAA records and CT monitoring—for any domains they operate outside tier-one registries.
