Retrieved article excerpt
Open article · Retrieved 2026-10-07T06:29:39.302630+00:00
CRYPTOGRAPHIC IMPERSONATION
# Hackers obtain counterfeit TLS certificates for Google and other large services
Compromise of 3 domain registries allows hackers to walk off with unauthorized certs.
[Dan Goodin](https://arstechnica.com/author/dan-goodin/)
–
Oct 6, 2026 3:21 pm
| [20](https://arstechnica.com/security/2026/10/hackers-obtain-counterfeit-tls-certificates-for-google-and-other-large-services/#comments "20 comments")
Credit:
Getty Images
Credit:
Getty Images
Text
settings
Story text
Size
Small
Standard
Large
Width
\*
Standard
Wide
Links
Standard
Orange
\* Subscribers only
[Learn more](https://arstechnica.com/store/product/subscriptions/)
Minimize to nav
Attackers hijacked three top-level domains and used their control to mint counterfeit TLS certificates for Google and other large organizations, Google said Tuesday.
The attackers launched a series of attacks on the .gh, .sl, and .as country code top-level domains (ccTLDs) and then modified authoritative DNS records for selected domains within those namespaces. By controlling those DNS records, the attackers were able to pass automated domain control validation checks and obtain unauthorized certificates for “several Google domains” and “several leading global brands and widely used online services.” Google said it updated Chrome to block all certificates it identified as unauthorized, and worked with the issuing certification authorities to ensure the unauthorized certificates for Google properties were revoked.
## Certificate issuance: The weak link in the chain
TLS certificates are the cryptographic credentials that underpin authentication and encryption protections for websites, mail servers, and other Internet infrastructure. These [x.509](https://en.wikipedia.org/wiki/X.509) certificates use a digital signature to bind a domain name such as google.com to a public key. The public key is publicly available, while the private key is held only by the website operator. When a connection shows that the keys match, the visiting party knows it’s connected to the authentic site rather than an impostor. Possession of unauthorized certificates allows attackers to cryptographically impersonate the affected infrastructure.
Google didn’t identify the affected domains it owns or name any of the other organizations whose domains were affected. While noting that Chrome users do not need to take any action to be protected, Google cautioned domain owners not to rely solely on browser-side interventions to protect their users. The company is advising domain owners to monitor certificate transparency logs for unexpected certificate issuance across their domains and to publish restrictive Certification Authority Authorization DNS records to prevent attackers from reusing cached validation data after DNS control is restored.
“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,” Google [said](https://blog.google/security/chromes-response-to-recent-cctld-registry-hijacks/). “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.”
It’s not immediately clear what the other affected organizations are, how many unauthorized certificates were issued, or if all of them, except for those for Google domains, have been blocked. The process for officially revoking certificates is slow and cumbersome, so browser makers have devised quicker methods to block specific certificates at the browser level. With all known unauthorized certificates now blocked, the risk is mitigated, but as Google noted, any certificates that remain undiscovered pose a threat.
Google noted that the incident didn’t involve the compromise of the infrastructure of any of the affected domain owners and that certificate authorities followed all requirements. With control of the three ccTLDs, the attackers were able to change the IP addresses of a selected list of websites. With the ability to send and receive traffic on those sites, the attackers were able to modify authoritative DNS records and nameserver delegations for selected domains, allowing them to pass industry validation checks requiring an applicant to prove control of the domain.
This isn’t the first time threat actors have obtained unauthorized certificates. A [2011 hack](http://www.theregister.co.uk/2011/08/29/fraudulent_google_ssl_certificate/) of Netherlands-based certificate authority DigiNotar allowed attackers to mint counterfeit certificates for Google.com and more than 200 other high-traffic domains. The certificates were used against at least 300,000 people with ties to Iran as they browsed the sites impersonated by the forged certificates. There have been many similar incidents since, [most](https://arstechnica.com/information-technology/2025/09/the-number-of-mis-issued-1-1-1-1-certificates-grows-heres-the-latest/) [often](https://arstechnica.com/information-technology/2015/03/google-warns-of-unauthorized-tls-certificates-trusted-by-almost-all-oses/) [through](https://arstechnica.com/information-technology/2017/01/already-on-probation-symantec-issues-more-illegit-https-certificates/) failures [by](https://arstechnica.com/information-technology/2012/02/critics-slam-ssl-authority-for-minting-cert-used-to-impersonate-sites/) [certificate](https://arstechnica.com/information-technology/2013/12/french-agency-caught-minting-ssl-certificates-impersonating-google/) [authorities](https://arstechnica.com/information-technology/2014/07/crypto-certificates-impersonating-google-and-yahoo-pose-threat-to-windows-users/) but also [domain holders](https://arstechnica.com/information-technology/2015/03/bogus-ssl-certificate-for-windows-live-could-allow-man-in-the-middle-hacks/).
[Photo of Dan Goodin](https://arstechnica.com/author/dan-goodin/)
[Dan Goodin](https://arstechnica.com/author/dan-goodin/)
Senior Security Editor
[Dan Goodin](https://arstechnica.com/author/dan-goodin/)
Senior Security Editor
Dan Goodin is Senior Security Editor at Ars Technica, where he oversees coverage of malware, computer espionage, botnets, hardware hacking, encryption, and passwords. In his spare time, he enjoys gardening, cooking, and following the independent music scene. Dan is based in San Francisco. Follow him at [here](https://infosec.exchange/@dangoodin) on Mastodon and [here](https://bsky.app/profile/dangoodin.bsky.social) on Bluesky. Contact him on Signal at DanArs.82.
[20 Comments](https://arstechnica.com/security/2026/10/hackers-obtain-counterfeit-tls-certificates-for-google-and-other-large-services/#comments "20 comments")