Counterfeit TLS certificates for Google: three country domains hijacked
Attackers took control of the .gh, .sl and .as country-code domains and used them to obtain unauthorised TLS certificates for Google and other major services. The certificate authorities followed the rules; it was DNS that gave way.

On Tuesday 6 October 2026, Google announced that attackers had hijacked three country-code top-level domains: .gh, .sl and .as. Control of these domains let them obtain unauthorised TLS certificates for several Google domains. According to the company, several major brands and widely used online services are also affected. The incident was reported by Ars Technica, based on Google’s statement. At this stage, that is the only available source.
A chain of trust bypassed through DNS
A TLS certificate uses a digital signature to bind a domain name to a public key. Only the site’s operator holds the matching private key. When verification succeeds, your browser treats the connection as the genuine site and not an impostor. An unauthorised certificate therefore lets someone impersonate a service in a way that holds up cryptographically.
Before issuing a certificate, a certificate authority runs an automated check that the requester controls the domain. This is the step the attackers exploited. Once they controlled the three country-code domains, they could change the IP addresses of a chosen list of sites. They also altered the authoritative DNS records and the name server delegations of certain domains. As a result, they received the traffic for those domains and could pass the validation checks the industry requires.
Google made two points clear. The infrastructure of the targeted domains’ owners was not compromised. And the certificate authorities met all of their obligations. No rule was broken during issuance: validation worked as designed, but on DNS that was no longer in its owners’ hands.
Victims largely unknown
Google has not said which of its domains were affected and has not named any of the other organisations involved. Several questions remain open: how many certificates were issued, and whether all of those that do not target Google have actually been blocked. The company itself acknowledges that it cannot guarantee its analysis has found every affected domain, given how complex these DNS hijacks are.
Blocked in Chrome, revoked for Google’s domains
Google says it has updated Chrome to block every certificate it has identified as unauthorised. If you use Chrome, you do not need to do anything to be protected. Google also worked with the issuing certificate authorities to have the certificates covering its own domains revoked. The source does not say whether the certificates for other organisations have been revoked.
There is a reason for relying on the browser. Formally revoking a certificate is slow and cumbersome, so browser vendors have built faster ways to block specific certificates on their side. But Google itself points out that these measures do not reliably protect people using other browsers. And a certificate that has not yet been discovered remains a threat.
What Google asks of domain owners
Google advises domain owners not to rely solely on browsers to protect their users, and makes two recommendations. First, monitor Certificate Transparency logs to spot any unexpected issuance for your domains. Second, publish restrictive DNS CAA records, which limit which certificate authorities may issue certificates for you. These records are meant to stop attackers from reusing validations already cached once control of the DNS has been restored.
This is not the first time counterfeit certificates have targeted Google. In 2011, the breach at the Dutch certificate authority DigiNotar led to certificates being issued for google.com and more than 200 other high-traffic domains. They were used against at least 300,000 people with ties to Iran. Similar incidents have recurred since then, most often because of errors by certificate authorities, and sometimes by domain holders.
This time, no authority was at fault: every certificate correctly attested to control of the DNS. It was the DNS itself that had changed hands, and the trust behind the padlock in your browser now depends on it.
Sources (1)
Written with AI assistance from the sources cited above, then reviewed and approved before publication by Sébastien Soulier.


