Attackers managed to take control of three country-code top-level domains—.gh, .sl, and .as—and then modify authoritative DNS records for selected domains within those spaces. According to Google, this enabled them to pass domain-ownership validation processes and obtain unauthorized TLS certificates for several of its domains, as well as domains belonging to global brands and widely used online services.
TLS certificates are cryptographic credentials that bind a domain name, such as google.com, to a public key through a digital signature. When an unauthorized party obtains a seemingly valid certificate, it can cryptographically impersonate the affected domain’s infrastructure, threatening the trust on which web and email communications and other internet services rely.
How Did the Attackers Bypass Validation?
The attackers used control of the three top-level domains to change the IP addresses of a selected group of websites. By gaining the ability to send and receive traffic for these sites, they were able to modify authoritative DNS records and nameserver delegations. This control was sufficient to prove control of the domains to certificate authorities, even without compromising the actual infrastructure of the domain owners.
Google confirmed that the incident did not involve compromising the systems of the affected domain owners, and that certificate authorities acted in accordance with the applicable requirements. The problem resulted from the attackers’ success in controlling the DNS path on which automated validation mechanisms rely, not from a confirmed flaw in Google’s systems or in the owners’ internal infrastructure.
What Did Google Do, and What Remained Unknown?
Google updated the Chrome browser to block all of the unauthorized certificates it was able to identify, and worked with certificate authorities to revoke certificates associated with its domains. It said Chrome users did not need to take action, but emphasized that browser-side protection is not a substitute for addressing the problem with domain owners.
Google did not disclose the names of the affected domains, the identities of the other organizations, or the number of certificates issued. It also remained unclear whether all certificates unrelated to Google services had been blocked. Although the known certificates have been blocked, certificates that have not yet been discovered may remain a source of risk. This is particularly significant because official certificate revocation is slow and complex, prompting browsers to use faster client-side blocking mechanisms.
Why Does This Matter?
The incident reveals that the TLS trust chain does not depend solely on the certificate authority; DNS integrity and domain delegations are a practical part of the ownership-validation process. Google therefore recommended that domain owners monitor Certificate Transparency logs for unexpected certificates and publish restrictive CAA DNS records to specify which certificate authorities are permitted to issue certificates. It also warned that Chrome’s measures do not protect users of other browsers or guarantee the detection of every affected domain, particularly given the complexity of DNS hijacking operations.
This is not the first incident of its kind. In 2011, the compromise of the Dutch certificate authority DigiNotar led to the issuance of fake certificates for Google.com and more than 200 highly used domains, which were used against at least 300,000 people associated with Iran. However, the current incident highlights a different path: obtaining unauthorized certificates through control of the domain layer and DNS validation, rather than compromising the service owner’s internal infrastructure.