Skip to content

Back to the catalog

Chrome's Response to Recent ccTLD Registry Hijacks
blog.googlearticle

Chrome's Response to Recent ccTLD Registry Hijacks

Google describes a series of registry-level hijacks affecting the .gh (Ghana), .sl (Sierra Leone), and .as (American Samoa) ccTLDs, in which attackers modified authoritative DNS records to obtain unauthorized HTTPS certificates for Google domains and, via Certificate Transparency monitoring, several other major organizations. Chrome mitigated impact by blocking the fraudulent certificates through CRLSets and coordinating revocation with issuing CAs, then urges domain owners to continuously monitor CT logs and publish restrictive CAA records with ACME account bindings, since cached domain-control-validation state can let attackers mint new certs even after DNS control is restored.

TL;DR Attackers hijacked the .gh, .sl, and .as ccTLD registries to get unauthorized HTTPS certs for Google and other domains; Chrome blocked them via CRLSets and recommends CT log monitoring plus restrictive CAA records as the real fix.
Open original ↗
Document

What to do

Two concrete, actionable defenses the page specifies beyond generic CT monitoring:

  • CT monitoring scope: coverage must include "parked or regional ccTLD properties" — not just actively-used domains. If you own anything in .gh, .sl, or .as, specifically review recent CT log entries for unexpected issuance.
  • CAA records with ACME account bindings: publish CAA records that restrict issuance to specific authorized accounts and validation methods, not just specific CAs. The stated reason is a mechanism the summary compresses: CAs are permitted to cache and reuse completed domain-control-validation (DCV) checks, so a generic CAA record (naming only allowed CAs) does not stop an attacker from minting new certs post-hijack if they still hold cached DCV state. Account-bound CAA is what closes that gap.

Preconditions / Affected

Relevant to anyone owning a domain in the three affected ccTLDs (.gh, .sl, .as) during the incident window, or any domain owner generally, since the CAA/DCV-caching gap is a standing weakness, not specific to this incident. Chrome users themselves need take no action — protection was browser-side via CRLSets.

Caveats

  • CAA cannot prevent issuance during an active DNS hijack — it only matters after DNS control is restored, closing the window an attacker would otherwise have via cached DCV.
  • Chrome's blocking is not a substitute for domain-owner action: Google states it cannot guarantee its analysis caught every affected domain, and Chrome interventions don't protect non-Chrome browser users.
  • No CAs were found at fault — the compromise was at the ccTLD registry level, outside CA or browser control.

Technologies named here

Techniques named here

  • ccTLD registry hijack / DNS record modification
  • Unauthorized HTTPS certificate issuance via DCV exploitation
  • Cached DCV reuse after hijack

Related in Threat Intel