Attackers hijacked .gh, .sl, and .as ccTLDs to pass domain validation and mint unauthorized TLS certificates for Google and other major services.
DNS Hijack Turns Domain Validation Against Certificate Authorities
Google said Tuesday that attackers hijacked three top-level domains and used that control to mint counterfeit TLS certificates for Google and other large organizations. The targeted namespaces were the .gh, .sl, and .as country-code top-level domains (ccTLDs). After compromising those ccTLDs, the attackers modified authoritative DNS records for selected domains within those namespaces.
That DNS control was not an end in itself. It became the mechanism for passing automated domain control validation checks. Certificate authorities rely on those checks to confirm that an entity requesting a certificate actually controls the domain in question. By manipulating authoritative DNS records, the attackers could satisfy the validation requirements and obtain unauthorized certificates for “several Google domains” and “several leading global brands and widely used online services,” according to Google.
Why TLS Certificates Are the Weak Link in the Chain
TLS certificates are cryptographic credentials that underpin authentication and encryption protections for websites, mail servers, and other Internet infrastructure. These x.509 certificates use a digital signature to bind a domain name such as google.com to a public key. The public key is publicly available, while the private key is held only by the website operator. When a connection shows that the keys match, the visiting party knows it is connected to the authentic site rather than an impostor.
Possession of unauthorized certificates allows attackers to cryptographically impersonate the affected infrastructure.
That is why certificate issuance is often described as a weak link in the chain of trust. The entire model depends on certificate authorities issuing credentials only to legitimate domain controllers. If an attacker can briefly control DNS records, they may be able to convince an automated validation system that they own the domain. The resulting certificate can then be used to impersonate the affected infrastructure, potentially enabling man-in-the-middle attacks, traffic interception, or credential theft. The risk is especially severe when the certificates cover high-profile domains belonging to Google or other widely used services.
Google's Response and the Scope of the Incident
Google said it updated Chrome to block all certificates it identified as unauthorized. The company also worked with the issuing certification authorities to ensure the unauthorized certificates for Google properties were revoked. These two steps are critical: browser-level blocking prevents Chrome users from trusting the fraudulent certificates, while revocation limits the window in which other relying parties might still accept them.
The incident affected more than Google alone. Google described unauthorized certificates for “several leading global brands and widely used online services.” That breadth illustrates how a compromise at the DNS layer can cascade across the certificate ecosystem. An attacker does not need to break the cryptographic algorithms behind TLS. They only need to exploit the validation and governance processes that decide who is allowed to receive a certificate for a given name.
What the .gh, .sl, and .as Hijack Reveals About PKI Dependencies
- ccTLD governance matters: Country-code top-level domains are operated by a range of registry operators, and their security practices can vary. When a ccTLD is compromised, every domain beneath it can become a potential vector for abuse.
- Authoritative DNS is a high-value target: Modifying authoritative records for selected domains was enough to influence automated domain control validation. This shows how much trust certificate authorities place in DNS-based proofs.
- Revocation and browser blocking are reactive but necessary: Google's Chrome update and coordination with certificate authorities helped contain the damage, but the attack still demonstrated the speed at which unauthorized certificates can be issued.
- Public-key infrastructure is only as strong as its weakest dependency: TLS, x.509, and certificate authorities form a chain that depends on DNS, registrars, registries, and validation systems all behaving correctly.
Broader Implications for the Web's Trust Model
The hijacking of .gh, .sl, and .as is a reminder that the web's trust model is not purely mathematical. Cryptography binds public keys to domain names, but humans and automated systems decide whether that binding is legitimate. When attackers can hijack top-level domains and alter authoritative DNS records, they can turn the certificate issuance process against the very organizations it is meant to protect.
For defenders, the incident reinforces the need for continuous certificate monitoring, rapid revocation, and browser-level enforcement. For certificate authorities, it highlights the importance of hardening domain control validation against DNS manipulation. For registries and registrars, it underscores the security obligations that come with controlling a top-level domain. Google's decision to block the unauthorized certificates in Chrome and coordinate with issuing CAs to revoke them is a textbook containment response, but the underlying lesson is that certificate security depends on the integrity of the DNS and registry layers beneath it.