When the Registry Fell: How Hijacked Country Domains Became the New Attack Vector for Counterfeit TLS Certificates

In early October 2026, Google confirmed that attackers had hijacked three country-code top-level domain (ccTLD) registries — .gh (Ghana), .sl (Sierra Leone), and .as (American Samoa) — and used that control to obtain unauthorized HTTPS certificates for Google domains and those of several other major organizations. The certificates were not forged by breaking cryptography. They were issued legitimately by certificate authorities who had no idea they were being deceived, because the attackers had already seized control of the very DNS infrastructure those authorities rely on to verify domain ownership. This is not a story about broken encryption. It is a story about how the web's trust model has a soft underbelly, and why browser-level interventions are not enough to protect it.

The incident highlights a uncomfortable truth about the internet's security architecture: the entire TLS certificate system — the padlocks we have been trained to trust — depends on the integrity of dozens of small, often under-resourced domain registries around the world. When one of those registries falls, the cryptographic chain of trust can be exploited to produce perfectly valid-looking certificates for any domain the attacker chooses to impersonate.

What Happened: The Attack Chain Explained

The attack was elegant in its simplicity. Rather than attempting to break TLS encryption, compromise a certificate authority, or exploit a vulnerability in Google's infrastructure, the attackers targeted the weakest link in the domain validation chain: the ccTLD registries themselves.

Here is how the attack unfolded, step by step:

1. Attackers gained control of three ccTLD registries: .gh (Ghana), .sl (Sierra Leone), and .as (American Samoa). The exact method of compromise has not been publicly disclosed, but ccTLD registries are often operated by small teams with limited security budgets.
2. With registry control, attackers modified authoritative DNS records and nameserver delegations for selected domains belonging to Google and other major organizations.
3. Attackers then requested TLS certificates from legitimate certificate authorities. The CAs performed standard domain control validation (DCV) checks — but because the attackers controlled the DNS, the validation passed.
4. Certificate authorities issued valid, trusted HTTPS certificates for domains like google.com.gh and similar properties under the compromised ccTLDs.
5. Google detected the unauthorized certificates through Certificate Transparency log monitoring and blocked them in Chrome via CRLSets, but acknowledged that browser-level blocking cannot catch every affected domain.

The critical point is that the certificate authorities did nothing wrong. They followed every required validation procedure. The problem is that those procedures assume DNS is trustworthy — and when a registry is compromised, that assumption breaks at the foundation.

Why This Is Not Just Another Certificate Incident

Unauthorized TLS certificates are not new. The web has seen them before: DigiNotar's catastrophic 2011 breach allowed attackers to mint certificates for Google and over 200 other domains, affecting 300,000 users in Iran. Symantec, Comodo, and French agency ANSSI have all been caught issuing mis-issued certificates over the past decade and a half. But this incident is different in an important way.

Previous certificate incidents were almost always caused by failures within certificate authorities themselves — compromised CA infrastructure, rogue employees, or validation process errors. The response was always the same: tighten CA requirements, improve auditing, and eventually revoke the CA's trust. The CA/Browser Forum has spent years building an elaborate compliance regime to prevent these exact failures.

This attack bypasses all of that. The CAs were fully compliant. The validation procedures were followed correctly. The weakness was not in the certificate authority — it was in the DNS hierarchy that the validation process depends on. No amount of CA auditing or compliance tightening can fix a compromised registry.

This means the attack surface is fundamentally different. There are roughly 250 ccTLD registries worldwide, operated by a wide range of organizations — from well-funded national governments to small academic institutions and private companies with minimal oversight. Any one of them can be compromised, and the TLS ecosystem provides no mechanism to prevent certificate issuance during an active DNS hijack.

The Structural Weakness: When Trust Propagates Through Untrusted Infrastructure

To understand why this attack works, you need to understand the chain of trust that underpins HTTPS. When you visit a website, your browser checks the server's TLS certificate against a list of trusted certificate authorities pre-installed in your operating system or browser. For a CA to issue a certificate, it must verify that the requester actually controls the domain. The most common validation method is DNS-based: the CA checks whether the applicant can modify the domain's DNS records.

This creates a circular dependency: DNS is used to validate domain ownership for TLS certificates, but DNS itself is secured by... TLS certificates. When DNS is compromised, the entire validation chain collapses. An attacker who controls a domain's DNS records can pass any CA's validation check, no matter how rigorous, because the CA is querying DNS records that the attacker controls.

The system has several mitigations, but none are sufficient against a full registry compromise:

• CAA (Certification Authority Authorization) records allow domain owners to specify which CAs are permitted to issue certificates for their domains. But during an active DNS hijack, the attacker can modify CAA records too. CAA only helps after DNS control is restored, preventing attackers from using cached validation state to mint new certificates.
• Certificate Transparency (CT) logs provide a public record of all issued certificates, allowing domain owners to detect unauthorized issuance. But CT is a detection mechanism, not a prevention mechanism. It tells you that a bad certificate exists — it does not stop it from being issued.
• CRLSets and browser-level blocking can prevent known-bad certificates from being trusted by specific browsers. But as Google itself noted, this only protects users of that browser, and there is no guarantee that every affected certificate has been identified.
• DNSSEC (Domain Name System Security Extensions) could theoretically prevent unauthorized DNS modifications by cryptographically signing DNS records. But DNSSEC adoption remains fragmented, especially among ccTLDs, and many of the affected registries did not have it deployed.

The fundamental issue is that the web PKI system treats DNS as a trusted channel, but DNS is operated by hundreds of independent organizations with wildly varying security postures. A single registry compromise can undermine the trust model for every domain under that TLD — and potentially for any domain, if the attacker is creative enough with subdomain delegation.

What This Means for Organizations and Developers

If you operate any internet-facing infrastructure — whether you are running a Fortune 500 company's web presence or a self-hosted homelab with a custom domain — this incident has direct implications for your security posture. Here is what you should be doing about it.

Monitor Certificate Transparency for Your Domains

Certificate Transparency logs are publicly queryable, and several services offer free monitoring. Google itself recommends this as the single most important defensive measure. Tools like CertSpotter, SSLMate's Cert Monitor, and Cloudflare's Certificate Transparency monitoring can alert you within minutes when a certificate is issued for any of your domains. If you are not monitoring CT logs for your domains today, you are flying blind — you will have no way to know if an attacker has obtained a certificate for your domain until after it has been used.

Deploy Restrictive CAA Records With Account Bindings

CAA records are DNS entries that specify which certificate authorities are allowed to issue certificates for your domain. A basic CAA record might say 'only Let us Encrypt can issue certificates for example.com.' But the real power comes from CAA account bindings (defined in RFC 8657), which restrict issuance to specific ACME accounts. This means that even if an attacker gains DNS control and tries to request a certificate from your authorized CA, they cannot use their own account — only yours. This does not prevent issuance during an active hijack, but it prevents attackers from using cached domain validation state to mint certificates after you regain control. Every domain owner should have restrictive CAA records in place today.

Be Wary of ccTLD Domains for Critical Infrastructure

If your organization uses ccTLD domains for critical services, consider the security posture of the registry operator. Some ccTLDs are operated by major registries with strong security practices (like .uk by Nominet or .nl by SIDN). Others are operated by small teams or government agencies with limited cybersecurity resources. If you are using a ccTLD domain for anything security-sensitive, you should have a plan for what happens if the registry is compromised — including rapid detection through CT monitoring and pre-established relationships with your CA for emergency certificate revocation.

Consider DNSSEC Deployment

DNSSEC adds cryptographic signatures to DNS records, making it much harder for an attacker to forge DNS responses even if they gain access to a registry's infrastructure. While DNSSEC adoption has been slow — particularly among ccTLDs — it is increasingly supported by major DNS providers and registrars. If your domain supports DNSSEC, enabling it adds another layer that attackers must defeat. It is not a silver bullet (an attacker with full registry control could potentially sign forged records), but it raises the bar significantly and provides tamper evidence.

The Bigger Picture: Trust Infrastructure Is Only as Strong as Its Weakest Node

This incident is a microcosm of a larger problem in internet security: the global trust infrastructure is only as strong as its weakest node. The TLS certificate system works because we trust certificate authorities to validate domain ownership. CAs validate domain ownership by checking DNS. DNS is operated by hundreds of independent registries. Any compromise at any point in that chain undermines the entire system.

The CA/Browser Forum has been working on solutions. A 2025 ballot (SC081v3) introduces schedules for reducing certificate validity periods and domain control validation reuse times — both of which would limit the window of opportunity for an attacker who obtains fraudulent certificates. Shorter certificate lifetimes mean stolen or fraudulent certificates expire sooner. Shorter DCV reuse periods mean that validation performed during a DNS hijack cannot be used to issue certificates after the hijack ends. These are meaningful improvements, but they reduce the blast radius rather than preventing the explosion.

Google is also pushing for post-quantum resilience in the web PKI through its Chrome Quantum-resistant Root Program (CQRP), which is a separate but related effort to future-proof TLS against quantum computing threats. But quantum-resistant cryptography does nothing to address the mundane, classical problem of a registry getting socially engineered or hacked.

The uncomfortable reality is that there is no clean fix for this class of attack. The web's trust model was designed in an era when DNS was assumed to be reliable, and while that assumption has been questioned before, the alternatives — like certificate pinning, DANE (DNS-based Authentication of Named Entities), or blockchain-based domain systems — have either been abandoned (HTTP Public Key Pinning was deprecated in Chrome 72 due to misuse risks) or failed to gain widespread adoption.

Looking Forward: What to Watch Next

Several developments are worth tracking in the aftermath of this incident:

• Registry security standards: ICANN and the country-code supporting organization (ccNSO) may face renewed pressure to establish minimum security requirements for ccTLD registry operators. Currently, ccTLDs are largely self-governed, with no mandatory security baseline.
• Shorter certificate lifetimes: The CA/Browser Forum's ongoing effort to reduce certificate validity from 398 days to potentially as low as 47 days would significantly limit the value of fraudulently obtained certificates.
• DNSSEC adoption momentum: High-profile incidents like this often drive adoption of existing security standards. Watch for major DNS providers and registrars to push DNSSEC more aggressively.
• CT monitoring as a standard practice: Expect to see CT monitoring become a default feature in cloud security platforms rather than a specialized tool. Google's explicit recommendation in its incident response suggests this will become a baseline expectation.
• Multi-factor domain validation: Some CAs are exploring validation methods that go beyond DNS — such as requiring verification through multiple channels (DNS plus HTTP-01 plus email) — to make it harder for a single-point compromise to enable fraudulent issuance.

For now, the immediate risk has been mitigated. Google has blocked the known unauthorized certificates in Chrome, and the affected CAs have revoked them. But as Google itself noted, there is no guarantee that every affected certificate has been identified. And the structural vulnerability remains: until the web PKI system reduces its dependence on DNS as a trust channel — or until DNS infrastructure becomes uniformly secure — this attack pattern will remain available to sophisticated adversaries.

The lesson is not that TLS is broken or that HTTPS is meaningless. It is that trust is a chain, and chains break at their weakest link. The padlock in your browser is only as trustworthy as the most underfunded registry operator on the planet. For most users, most of the time, the system works. But when it fails, it fails silently — and the only defense is vigilance, monitoring, and a willingness to accept that the infrastructure we rely on is more fragile than it appears.