As reported by The Hacker News, attackers compromised three country-code top-level domain registries—.gh (Ghana), .sl (Sierra Leone), and .as (American Samoa)—and used their control of authoritative DNS to obtain fraudulent TLS certificates for Google and YouTube domains. Google detected the issuance via Certificate Transparency logs and blocked the certificates in Chrome through CRLSets. The certificates, 11 from Let's Encrypt and one from ZeroSSL, have been revoked.

Key Takeaway: As reported by The Hacker News, attackers compromised three country-code top-level domain registries—.gh (Ghana), .sl (Sierra Leone), and .as (American Samoa)—and used their control of authoritative DNS to obtain fraudulent TLS certificates for Google and YouTube domains.

This incident is significant not because Google was breached—it wasn't—but because it demonstrates a structural weakness in the WebPKI trust model that every organization should understand: domain-validated certificates are only as trustworthy as the DNS infrastructure that backs them. When an attacker controls DNS at the registry level, every CA in the world becomes a potential tool for obtaining seemingly legitimate certificates.

Why the Trust Model Failed Here

TLS certificates validate one thing: that the applicant demonstrated control over a domain at the moment of issuance. The CAs involved—Let's Encrypt and ZeroSSL—followed their validation procedures correctly. The failure was upstream, at the ccTLD registry level, where attackers modified authoritative DNS records to pass HTTP-01 or DNS-01 challenge responses.

This is not a CA failure. It's a supply chain failure. And it's one that most organizations aren't prepared to detect, because the assumption baked into PKI is that DNS is trustworthy.

Who Is at Risk

Any organization holding domains under ccTLDs managed by smaller or under-resourced registries is at elevated risk. While gTLDs like .com and .net are operated by large, heavily regulated registries, many ccTLDs are run by national telecommunications authorities, universities, or small private operators with varying security postures. If you hold country-code domains for brand protection, local presence, or regulatory reasons, this attack vector applies to you.

Google noted that other well-known brands and services were also targeted, though they weren't named. This suggests the attackers were casting a wide net, not pursuing Google specifically.

What Actually Stopped the Attack

Three layers of defense converged to limit damage:

  • Certificate Transparency logs exposed the unauthorized issuance within days, enabling rapid detection.
  • CRLSets, Chrome's out-of-band certificate blocklist, allowed Google to push emergency blocks faster than normal revocation channels.
  • CA cooperation enabled same-day revocation across browsers and applications.
The critical takeaway: Google caught this because it actively monitors CT logs for its own domains. Most organizations do not. If you're not watching for certificates you didn't request, you won't know when an attacker obtains one.

Shield53 Recommendations

  • Deploy CAA records on every domain you control to restrict certificate issuance to specific CAs. While compromised DNS can modify CAA records, this raises the bar and creates an additional monitoring signal.
  • Monitor Certificate Transparency logs for all your domains using tools like crt.sh, Cert Spotter, or commercial CT monitoring services. Alert on any certificate issued by a CA you don't use.
  • Enable DNSSEC where the registry supports it. DNSSEC prevents DNS spoofing at the protocol level, though it requires both registry and registrar support.
  • Preload HSTS on critical domains to prevent certificate downgrade attacks and ensure browsers reject unauthorized certs.
  • Audit your ccTLD portfolio and assess the security maturity of each registry operator. Consider whether domains under weakly governed ccTLDs are necessary or can be consolidated.
  • Implement DNS change monitoring at the authoritative level so you're alerted when records change outside your change management process.
  • Use short-lived certificates where operationally feasible to minimize the exposure window if fraudulent issuance occurs.

This incident should prompt every security team to ask a simple question: if someone obtained a valid TLS certificate for one of our domains right now, how long would it take us to notice? For Google, the answer was days. For most organizations, it would be never.