Hijacked .gh, .sl and .as Registries Let Attackers Mint Google Certs

Attackers who compromised the operators behind the .gh, .sl and .as country registries obtained unauthorized certificates for Google names, and Chrome has now blocked them. The sharper lesson is that this was a failure in the DNS layer, not in a certificate authority, so any domain ending in .gh, .sl, or .as is at risk until its owner watches Certificate Transparency.

Google's Chrome Secure Web and Networking Team laid this out on October 6, 2026, in a post titled "Chrome's Response to Recent ccTLD Registry Hijacks". The affected registries serve Ghana (.gh), Sierra Leone (.sl) and American Samoa (.as). According to Google, attackers compromised the third-party operators of these ccTLDs, modified authoritative DNS records and then obtained unauthorized certificates. Google's own words: "These incidents did not involve a compromise of Google's systems."

RelatedGemini Hacked Three Companies on Its Own, Google Confirms

How a registry hijack turns into a valid certificate

A certificate authority proves you control a domain by checking DNS or answering a challenge on a host the domain points to. If someone controls the registry for the whole country code, they can change the authoritative records for any name beneath it and pass that check. The CA does its job correctly and still hands the certificate to the wrong party.

Google says as much: "we have no reason to believe the Certification Authorities (CAs) that issued the impacted certificates did anything wrong." That is a different failure point from the 2011 DigiNotar case, where the certificate authority itself was compromised.

What Chrome and Google did about the certificates

Chrome's main move was "blocking the use of unauthorized certificates for Google properties in Chrome via CRLSets." Google also worked with the issuing CAs to revoke the certificates, which protects clients other than Chrome. Using Certificate Transparency logs, the team found other affected organizations, "including several leading global brands and widely used online services", and proactively blocked their certificates in Chrome too. Google's message to users is short: "Chrome users do not need to take any action to be protected."

The limits are stated just as plainly. Google writes that "we cannot guarantee that our analysis identified every affected domain," and that "nor do Chrome interventions reliably protect non-Chrome users." A forged certificate that was never revoked still works in a browser or app that ignores CRLSets.

The post does not say how many certificates were involved, which CAs issued them, or how the registries were compromised. It does not say who did it, and neither do we.

What the public logs show for .sl and .as Google names

We queried the public crt.sh Certificate Transparency search on October 12, 2026 and found certificates for Google-owned names that were not issued by Google Trust Services. The other recent certificates we saw for Google names such as google.com.gh and google.sl were issued by Google Trust Services, which is what made these stand out. All of the ones below were issued by Let's Encrypt.

RelatedAI Agents Hit 395 Orgs via PaperCut. Speed Isn't the Story

Treat this as a partial view. crt.sh truncated the large result sets for google.com.gh and google.as, with results ending in early 2025, and some queries returned 429 and 502 errors. You can reproduce the youtube.sl lookup yourself at crt.sh/?q=youtube.sl.

How many certificates were there? Reported numbers

The Hacker News reported 12 certificates for seven domains, 11 from Let's Encrypt and one from ZeroSSL, appearing in public logs between September 22 and September 27. Those are that outlet's figures, not Google's, and our list of five certificates is a subset we could see, not a count. Read the two as consistent in shape, not as one reconciled total.

How to check your own domains and lock down issuance

Google's advice to domain owners comes down to a few habits.

• Monitor Certificate Transparency continuously for all of your domains, including parked domains and regional ccTLD properties you rarely touch. Owners of .gh, .sl and .as domains should review recent CT entries first.
• Search your name on crt.sh and look for any issuer you do not use. A certificate from a CA that is absent from your own tooling is the thing to chase.
• Publish restrictive CAA records with ACME account bindings, so only specific authorized accounts and validation methods can get certificates for your names.

An example of the idea: CAA 0 issue "letsencrypt.org; accounturi=...", filled in with your own account URI. Google is careful about what this does: "CAA can not prevent certificate issuance during an active DNS hijack." Its value comes afterward. Once DNS control is restored, an attacker cannot reuse cached validation to keep minting certificates, because issuance is tied to your accounts and methods.

Google also points to longer-term work through the Chrome Root Program on reducing certificate validity and domain control validation reuse, both of which shrink the window a hijack can exploit.