Hijacked Country-Code Domains Let Attackers Mint Fake HTTPS Certificates

by Ben Voss
Hijacked Country-Code Domains Let Attackers Mint Fake HTTPS Certificates

Hijacked Country-Code Domains Let Attackers Mint Fake HTTPS Certificates

Attackers compromised third-party operators of the .gh, .sl, and .as country-code top-level domains and used altered authoritative DNS records to obtain unauthorized HTTPS certificates for several Google domains and other organizations. The incident did not compromise Google’s systems, but it shows how problems in domain infrastructure can undermine the browser security signals users rely on.

Google said the affected namespaces were .gh for Ghana, .sl for Sierra Leone, and .as for American Samoa. After DNS records were modified, the attackers could direct domains to infrastructure they controlled and complete the domain-control checks used by certificate authorities. That allowed them to obtain certificates covering domains they did not legitimately control.

What users need to know

An unauthorized certificate can help an attacker impersonate a legitimate website without producing the normal browser certificate warning. With control of DNS routing and the private key associated with the certificate, an attacker could potentially intercept or modify traffic sent to the impersonated site, or use the trusted organization’s brand for phishing and malware distribution.

Google blocked unauthorized certificates for its properties in Chrome through CRLSets, an emergency mechanism for quickly blocking selected revoked or untrusted certificates. Google also worked with the issuing certificate authorities to revoke the certificates and used Certificate Transparency logs to identify additional organizations that may have been affected. Chrome users do not need to take action to receive the protection described by Google.

The protection is not universal. Google said it may not have identified every affected domain, and Chrome’s browser-side interventions do not reliably protect users of other browsers. Google and the published reports did not identify the attackers, the complete list of affected organizations, or the number of certificates involved.

Why the incident matters

The event highlights the difference between securing a website and securing the systems that control its name. HTTPS certificates are issued after a certificate authority verifies domain control. If an attacker temporarily controls authoritative DNS, that verification can be completed even though the legitimate website operator did not authorize the certificate.

Certificate Transparency adds a detection layer because trusted-by-default certificates used by Chrome must be disclosed in public logs. Google said monitoring those logs provides near-real-time alerts when certificates are issued for an organization’s domains, including parked and regional country-code domains.

Recommended steps for domain owners

  1. Monitor Certificate Transparency logs. Search continuously for unexpected certificates across the full domain portfolio. Organizations using .gh, .sl, or .as domains should specifically review recent log entries for unrecognized issuance.
  2. Publish restrictive CAA records. Certification Authority Authorization records allow domain owners to specify which certificate authorities may issue certificates for their domains.
  3. Restrict CAA policies where possible. Google recommends policies that limit issuance to authorized ACME accounts and validation methods. CAA cannot prevent issuance during an active DNS hijack, but it can help prevent attackers from using cached domain-validation results to mint additional certificates after DNS control is restored.

Chrome’s response reduced the immediate risk for certificates Google identified, but the broader lesson is that organizations need continuous visibility into DNS changes and certificate issuance rather than relying only on browser warnings.

References