DNS hijacks led to rogue Google TLS certificates

DNS hijacks at three country-code top-level domains allowed attackers to obtain unauthorized HTTPS certificates for several Google domains, according to Google, which disclosed the incident on October 6. Google said its own systems were not breached, but domains ending in .gh for Ghana, .sl for Sierra Leone and .as for American Samoa were exposed to risk while the hijacks were under way.

The practical danger is that a valid-looking HTTPS certificate can help an attacker impersonate a real website over an encrypted connection. HTTPS is the secure web connection shown by browsers, and its trust depends on certificates that prove a site is the one a visitor intended to reach. If an attacker can get a certificate for a domain they do not legitimately control, they may be able to make a fake site appear authentic and see private information sent to it. Google did not say whether any of the certificates were actually used to impersonate a Google site or read user data.

Google said Chrome blocked the unauthorized certificates for Google domains through CRLSets, Chrome’s emergency mechanism for quickly distrusting certificates. Google also worked with the certificate authorities that issued the certificates so they could be revoked. Certificate authorities, or CAs, are the organizations that issue website certificates after checking that an applicant controls the domain. Revocation is the process of marking a certificate as no longer trustworthy, which helps protect people using other browsers and applications as well as Chrome.

The affected Google domains were not named by Google, but Certificate Transparency logs showed at least 12 certificates issued between September 22 and September 27 for Google and YouTube names under the three ccTLDs. Certificate Transparency, often shortened to CT, is a public logging system that records certificates issued by CAs so domain owners and researchers can spot unexpected certificates. The Hacker News reported finding the certificates on October 7 using ctlogs.dev and Cert Spotter. The records covered seven domains, including google.com.gh, google.sl and google.as.

Of the 12 certificates found in those logs, 11 were issued by Let’s Encrypt and one by ZeroSSL. They were domain-validated certificates, meaning they were issued after a check that the requester controlled the domain. Google said the attackers altered authoritative DNS records during the hijacks. DNS is the system that directs a domain name to the right internet destination, and authoritative DNS records are the records treated as the source of truth for a domain. Because the attackers could change those records, Google said it had no reason to believe the CAs acted improperly.

The CT records reviewed in the report showed a sequence across the three ccTLDs. Certificates for .gh names were first logged on September 22, certificates for .sl names on September 25 and certificates for .as names on September 27. The certificate names included google.com.gh, youtube.com.gh, google.sl, google.com.sl, youtube.sl, google.as and youtube.as, with some certificates covering wildcard names such as *.google.com.gh or *.youtube.as. In records going back to at least September 10, every other certificate for google.com.gh, google.sl and google.as came from Google Trust Services, Google’s own CA.

A Let’s Encrypt staff member wrote on the CA’s community forum on October 7 that certificates for Google and YouTube had been issued and had been revoked. The search covered only a small set of Google and YouTube names, so the total number of affected certificates may be higher. Google also said CT data indicated that other organizations may have been hit by the same attacks, including well-known global brands and widely used online services, but it did not name those organizations.

By October 7, Cert Spotter showed all 12 certificates as revoked. The two .gh certificates and the ZeroSSL certificate were revoked on September 26. The remaining nine certificates were revoked on October 1. The gap between first logging and revocation ranged from about a day and a half to nearly a week. One notable timing detail is that the first .as certificate was logged on September 27, around a day after the .gh certificates had already been revoked.

Google said it learned of the hijacks in the week before its October 6 post and acted immediately, but it did not give specific dates for the hijacks or its own response steps. The company said it also blocked in Chrome the certificates it found for other organizations and contacted those organizations where it could. Google’s post did not identify the attackers, explain how the ccTLD registries were compromised or state whether the registries had been secured.

For site owners, the key lesson is that certificate trust depends not only on the CA, but also on the integrity of DNS. A CA commonly issues a certificate once a requester proves domain control, for example by placing a specific DNS record on the domain. If an attacker has control of the relevant authoritative DNS records during a hijack, they may be able to pass that check even if they do not own the domain.

Google advised domain owners to monitor CT logs for every domain they own, including parked domains and regional ccTLD variants. CT monitoring services can alert an owner when a certificate is issued for one of their domains. Anyone operating a domain under .gh, .sl or .as should review recent certificate log entries for certificates they did not request.

Google also recommended publishing a strict CAA record. A Certification Authority Authorization record, or CAA record, is a DNS record that tells CAs which certificate authorities are allowed to issue certificates for a domain. Google recommends tying that record to the owner’s own CA account where the CA supports that option. The CA rules also allow anyone to report an unexpected certificate to the issuing CA through a Certificate Problem Report, and the CA must investigate and provide initial findings within 24 hours.

A CAA record is not a complete defense during an active DNS hijack. The CAA standard says an attacker who can remove the record or replace it with a false one could still obtain a certificate. Its value is especially important after the legitimate owner regains DNS control, because Google said CAs may reuse a completed domain validation for later certificates. A strict CAA record can stop a later certificate request if it limits issuance to the legitimate CA or account.

The Baseline Requirements followed by CAs currently allow a domain validation to be reused for up to 200 days. That limit is scheduled to fall to 100 days in March 2027 and to 10 days in March 2029 under a CA/Browser Forum schedule approved in April 2025. Let’s Encrypt said in December 2025 that it reuses a domain check for 30 days and plans to reduce that period to 7 hours by 2028.