Chrome blocks certificates after .gh, .sl, and .as registry hijacks

Google’s Chrome team intervened last week to block unauthorized HTTPS certificates issued for domains under the .gh, .sl, and .as extensions. The browser vendor acted after attackers compromised these specific country-code top-level domain (ccTLD) registries, allowing them to modify DNS records and request valid certificates for targeted sites. This incident highlights the fragility of the global domain name system and the critical need for proactive certificate monitoring by domain owners.

What happened

The security breach originated not within Google’s infrastructure, but at the level of third-party ccTLD registries for Ghana (.gh), Sierra Leone (.sl), and American Samoa (.as). Attackers gained control over these registries and modified authoritative DNS records. With control over DNS, they were able to pass domain validation checks required by Certification Authorities (CAs). Consequently, the attackers obtained unauthorized HTTPS certificates for several Google domains as well as domains belonging to other organizations.

Upon detecting the anomaly, Chrome’s Secure Web and Networking Team immediately deployed CRLSets to block the use of these unauthorized certificates within the Chrome browser. CRLSets are a mechanism Chrome uses to revoke certificates that are still technically valid but known to be compromised or misissued. The team also coordinated with the issuing CAs to ensure the certificates were formally revoked, protecting users on other browsers. Chrome stated that there was no indication the CAs themselves acted incorrectly; they issued certificates based on the manipulated DNS data provided by the attackers.

Further analysis of public Certificate Transparency (CT) logs revealed that the attack surface was wider than initially thought. Several leading global brands and widely used online services were also impacted by the same registry compromises. Chrome proactively blocked certificates for these additional entities to protect users while reaching out to the affected organizations where possible. The browser vendor emphasized that Chrome users did not need to take any manual action, as the protections were applied automatically.

Key details

• Affected namespaces: The hijacks specifically targeted the .gh (Ghana), .sl (Sierra Leone), and .as (American Samoa) ccTLDs.
• Attack vector: Compromise of third-party ccTLD registries allowed attackers to modify authoritative DNS records.
• Outcome: Attackers obtained unauthorized HTTPS certificates for Google and other organizational domains.
• Chrome response: Unauthorized certificates were blocked via CRLSets, and issuing CAs were contacted for revocation.
• Broader impact: Certificate Transparency logs showed additional global brands and services were likely impacted.
• CA involvement: Google found no evidence that the Certification Authorities acted improperly during issuance.

Background

To understand this incident, it is helpful to know how HTTPS certificates are issued. When a website owner requests a certificate, the CA must verify that the requester controls the domain. This is often done by checking DNS records. If an attacker controls the registry managing those DNS records, they can redirect validation checks to their own servers, tricking the CA into issuing a certificate. This is known as a DNS hijack.

Certificate Transparency (CT) is a public ledger system designed to detect such misissuance. Every trusted CA must log every certificate they issue in these public logs. This allows domain owners and browsers to scan for certificates issued without their knowledge. In this case, CT logs were instrumental in revealing the full scope of the attack beyond just Google’s properties. CRLSets, meanwhile, are a Chrome-specific feature that allows Google to push emergency revocations to browsers faster than the standard global revocation process.

Why it matters

For teams running their own software or managing corporate domains, this incident serves as a stark reminder that you do not fully control your domain’s security if you rely solely on the default behavior of CAs. Even if your internal systems are secure, a compromise at the registry level can lead to valid certificates being issued for your domain. These certificates can be used for man-in-the-middle attacks, intercepting user traffic and stealing credentials. Relying on browser vendors like Google to catch these issues is risky, as their interventions may not cover all browsers or every affected domain.

Furthermore, the reliance on DNS for validation means that any weakness in the chain of trust—from the registrar to the registry—can undermine your HTTPS security. For self-hosted applications, where you might manage your own DNS and certificates, understanding the external dependencies is crucial. If your domain is hosted on a compromised TLD, your internal security measures may be bypassed before traffic even reaches your server. Proactive monitoring is no longer optional; it is a necessary layer of defense against systemic infrastructure failures.

What you can do

• Monitor Certificate Transparency logs: Set up automated monitoring for all your domains to receive alerts whenever a new certificate is issued. This provides near real-time detection of unauthorized issuance.
• Publish restrictive CAA records: Use Certification Authority Authorization (CAA) DNS records to specify exactly which CAs are allowed to issue certificates for your domains. This limits the attack surface even if DNS is compromised.
• Bind ACME accounts in CAA: Where supported, restrict certificate issuance to specific ACME account bindings. This prevents attackers from using cached validation data to mint new certificates after regaining DNS control.
• Review regional ccTLDs: If you operate domains in .gh, .sl, or .as, or other regional extensions, review recent CT log entries immediately for any unexpected activity.
• Audit your domain portfolio: Ensure your monitoring covers all domains, including parked or legacy properties, as attackers often target less monitored assets.
• Do not rely solely on browser blocking: Implement your own detection and response capabilities, as browser-side interventions are not guaranteed to protect non-Chrome users or catch every instance.