Chrome's Response to Recent ccTLD Registry Hijacks

Last week, we became aware of a series of domain hijacks in the .gh (Ghana), .sl (Sierra Leone), and .as (American Samoa) country-code top-level namespaces (i.e., ccTLDs). These incidents did not involve a compromise of Google’s systems; rather, attackers compromised the third-party ccTLDs, putting any domain ending in .gh, .sl, or .as at risk. During these hijacks, attackers modified authoritative DNS records and obtained unauthorized HTTPS certificates covering several Google domains, as well as domains belonging to other organizations. Due to the nature of the attacks, we have no reason to believe the Certification Authorities (CAs) that issued the impacted certificates did anything wrong.

As part of our usual incident response process, we immediately acted to protect users by blocking the use of unauthorized certificates for Google properties in Chrome via CRLSets. We also worked with the issuing CAs to ensure the certificates were revoked to protect users in clients other than Chrome.

Following our initial mitigation, Certificate Transparency (CT) log data revealed additional organizations, including several leading global brands and widely used online services, believed to have been impacted by the same attacks. To ensure users of those sites were kept safe as soon as possible, we proactively blocked these certificates in Chrome. Where possible, we reached out to impacted organizations to alert them to our findings and actions.

Chrome users do not need to take any action to be protected.

What domain owners should do to protect themselves and their users

While Chrome took steps during these incidents to identify and block suspected unauthorized certificates across the affected ccTLDs, browser-side intervention should not be relied on to protect your users. Due to the complexity of DNS hijacks, we cannot guarantee that our analysis identified every affected domain, nor do Chrome interventions reliably protect non-Chrome users.

Because domain owners are in the best position to know which certificates and CAs are authorized for their namespaces, we strongly encourage organizations to take the following steps:

• Perform ongoing monitoring of Certificate Transparency for all of your domains: Because every trusted-by-default certificate relied upon by Chrome must be disclosed in public CT logs, monitoring CT logs provides a near real-time alert whenever a certificate is issued for your domains. Organizations should ensure their monitoring covers their entire domain portfolio, including parked or regional ccTLD properties. If you operate a domain in .gh, .sl, or .as, review recent CT log entries for unexpected issuance.
• Publish restrictive CAA records (with ACME account bindings): Certification Authority Authorization (CAA) DNS records allow domain owners to declare which CAs are permitted to issue certificates for their domains. While CAA can not prevent certificate issuance during an active DNS hijack, it provides a critical safeguard after DNS control is restored, and can prevent some routing-based and HTTP attacks entirely. Because CAs are permitted to cache and reuse completed domain control validation (DCV) checks for subsequent issuance, restoring a restrictive CAA policy, especially one that restricts issuance to specific authorized accounts and validation methods, prevents an attacker from using cached validation state to mint new certificates after a hijack ends.

In parallel with domain-owner defenses, we will continue to work alongside the broader community to limit the impact of transient routing and DNS compromises on the safety of the web. To keep our users safe, we are committed to long-term HTTPS ecosystem improvements, such as reducing certificate validity and DCV reuse, through the Chrome Root Program and the new Chrome Quantum-resistant Root Program.