DNS Hijacks at .gh, .sl and .as Minted Trusted Google Certificates: Admin Actions

You don't need Microsoft products to be affected for this to matter to a Windows admin. It is a reminder that the trust chain behind every padlock icon starts with DNS. That includes the Chrome, Edge and line-of-business traffic running on your fleet.

How the attack worked​

Public certificate authorities (CAs) issue domain-validated certificates after an applicant proves control of a domain. That usually means creating a TXT record containing a random value the CA supplies. If you control the authoritative DNS, you can pass that test for a domain you don't own.

During these hijacks, attackers modified authoritative DNS records and obtained unauthorized HTTPS certificates covering several Google domains, as well as domains belonging to other organizations. Ars Technica added that the attackers modified authoritative DNS records and nameserver delegations for selected domains. That let them pass automated validation checks.

The weak link was not Google's infrastructure or the CAs' processes. Google said it has no reason to believe the CAs that issued the certificates did anything wrong. The weak link sat upstream, in the registries that decide who controls a namespace.

What the certificate logs show​

Google did not name the affected domains. The Hacker News searched Certificate Transparency (CT) logs on October 7 and found a sample. These are public records of every certificate issued by participating CAs.

• It found 12 certificates covering seven Google and YouTube domain names under the three ccTLDs.
• All were domain-validated. Let's Encrypt issued 11 and ZeroSSL issued one.
• They first appeared in the logs on September 22 for .gh, September 25 for .sl and September 27 for .as.
• Examples include google.com.gh, youtube.com.gh, google.sl, google.com.sl, youtube.sl, google.as and youtube.as. Some certificates covered wildcard names.
• Cert Spotter showed all 12 as revoked by October 7. The two .gh certificates and the ZeroSSL certificate were revoked on September 26. The other nine were revoked on October 1.

A Let's Encrypt staff member confirmed on the CA's community forum on October 7 that certificates for Google and YouTube had been issued and revoked, according to The Hacker News.

This is a sample, not a tally. The Hacker News searched only a small set of Google and YouTube names, so the real total may be higher. Google said CT data also pointed to other organizations it believes were hit, including leading global brands and widely used online services. It did not name them.

What Google did​

• Chrome blocks. Google blocked the unauthorized certificates for its own properties in Chrome via CRLSets. CRLSets are Chrome's emergency mechanism for rejecting specific certificates quickly.
• Revocation. Google worked with the issuing CAs to revoke the certificates, so that users of other clients are also protected.
• Wider sweep. Following its first mitigation, CT log data revealed additional affected organizations, and Google proactively blocked those certificates in Chrome. Where possible it contacted the affected organizations.
• Users. Chrome users don't need to do anything.

What remains unknown​

Google's post leaves several questions open.

• It did not identify the attackers.
• It did not explain how the registry operators were compromised, or whether they have since been secured.
• It did not say how many certificates or domains were involved.
• It did not say whether any certificate was actually used to impersonate a site or read user data. Don't read the incident as confirmed data theft. A certificate by itself doesn't read anyone's traffic. The attacker also has to steer a victim's connection to infrastructure they control. That is possible here, since they controlled the DNS answers for the affected names.
• Google said it learned of the hijacks the week before its post. It gave no dates for the hijacks or for its own actions.

Ars Technica noted a historical parallel. In 2011, the DigiNotar breach let attackers mint counterfeit certificates for Google.com and more than 200 other domains. Those were used against at least 300,000 people with ties to Iran. The 2026 incident is different in origin, since the CAs were not at fault, but the outcome is similar: a trusted certificate for a site you don't own.

The Chrome-only caveat​

Google was unusually candid about the limits of its fix. It said it cannot guarantee its analysis identified every affected domain, and that Chrome interventions do not reliably protect non-Chrome users.

That matters in a mixed environment. Most browsers and many applications don't consult Chrome's CRLSets. Edge shares Chromium code, but this incident's blocks were described only for Chrome. Server-to-server clients, scripts, mobile apps and embedded software generally rely on the platform trust store and on revocation by the CA. Ars Technica also observed that formal revocation is slow and cumbersome, which is why browser vendors built faster emergency blocks.

What admins and domain owners should do​

Google's guidance is aimed at domain owners, and it is useful to any organization with a regional domain portfolio.

1. Monitor CT logs for all your domains. Include parked domains and regional ccTLD names, not just your primary corporate domain. CT monitoring gives near-real-time alerts when a certificate is issued. If you hold anything under .gh, .sl or .as, review recent entries for certificates you didn't request.
2. Publish restrictive CAA records. CAA records declare which CAs may issue for your domain. Google recommends binding them to your own ACME account and validation methods where the CA supports that.
3. Report unexpected certificates to the issuing CA. The Hacker News notes that the CA/Browser Forum Baseline Requirements let anyone file a Certificate Problem Report. It says the CA must investigate and report its first findings within 24 hours.

CAA has a clear limit. It cannot prevent issuance during an active DNS hijack, because someone controlling DNS can alter or remove it. Its value comes once you regain DNS control. CAs may cache and reuse completed domain-control validation, so an attacker who passed validation during the hijack could request more certificates afterward. A strict CAA policy shuts that door.

The Hacker News checked the seven affected Google and YouTube names on October 7. It found that each carried a strict CAA record, and Google Public DNS returned one naming only pki.goog, Google Trust Services' domain.

The longer fix: shorter validation reuse​

Google pointed to long-term ecosystem changes. These include shorter certificate lifetimes and less reuse of domain validation, pursued through the Chrome Root Program. The Hacker News reported the schedule:

• The Baseline Requirements currently allow a CA to reuse a domain check for up to 200 days.
• That drops to 100 days in March 2027 and to 10 days in March 2029.
• Let's Encrypt said in December 2025 that it reuses a check for 30 days. It plans to cut that to 7 hours by 2028.

Shorter reuse windows shrink the time an attacker can exploit a brief DNS compromise. They don't stop certificates being issued during the hijack itself.

Takeaways​

• The compromise was upstream, at three ccTLD registries, not at Google or the CAs.
• Twelve Google and YouTube certificates were found in a limited CT search. The true total is unknown and includes other, unnamed brands.
• Chrome users are protected for the certificates Google found. Other clients depend on CA revocation, and Google admits coverage may be incomplete.
• Admins should extend CT monitoring to every domain, including forgotten regional ones. They should also set strict CAA records now, so the tool is ready before the next incident.