ccTLD Hijacks on .gh, .sl and .as Yield Rogue Google Certificates

A padlock promises one narrow thing: the server you reached proved control of the name you typed. In late September, for a handful of Google and YouTube domains, the wrong people supplied that proof. Attackers took over the systems behind three country code top level domains, rewrote the DNS, and asked certificate authorities for certificates. The CAs checked the DNS, saw the attackers' answers, and issued.

Google described the incident on October 6, 2026 in Chrome's Response to Recent ccTLD Registry Hijacks. It named the three namespaces, .gh (Ghana), .sl (Sierra Leone) and .as (American Samoa), but not the certificates. We pulled several of them from public Certificate Transparency data ourselves to check what the press reported.

Key Takeaways

• Google said on October 6, 2026 that attackers compromised the third party operators of the .gh, .sl and .as country code domains, modified authoritative DNS records, and obtained unauthorized HTTPS certificates for several Google domains and for other organizations.
• The Hacker News counted 12 rogue certificates for seven Google and YouTube domains, 11 from Let's Encrypt and one from ZeroSSL, first logged on September 22 (.gh), September 25 (.sl) and September 27 (.as), and our own Cert Spotter queries confirmed six of them.
• Wildcard certificates such as *.google.com.gh cover accounts.google.com.gh, a live Google hostname that currently redirects to accounts.google.com, but an attacker could only exploit them against people whose traffic they could steer to their own server.
• Chrome blocked the certificates through CRLSets and the CAs revoked all 12, the last on October 1, while Google warned that its blocks do not reliably protect users of other browsers.
• Google has not named the attackers or explained how the registries were breached, and its post does not say whether any certificate was used against a real user.

What Happened in the .gh, .sl and .as Hijacks?

Attackers controlled what three country code registries published and used it to pass CA domain checks. Google's post says the attackers "compromised the third-party ccTLDs, putting any domain ending in .gh, .sl, or .as at risk," and "modified authoritative DNS records." The certificate timeline below comes from The Hacker News, which searched CT logs on October 7:

• September 22: two Let's Encrypt certificates logged for google.com.gh and youtube.com.gh.
• September 25: six certificates for google.sl, google.com.sl and youtube.sl, including the only one from ZeroSSL.
• September 26: the two .gh certificates and the ZeroSSL certificate are revoked.
• September 27: four certificates for google.as and youtube.as, about a day after the .gh revocations.
• October 1: the remaining nine certificates are revoked.
• October 6: Google publishes its post, saying it learned of the hijacks the previous week.

The pace stands out. iTnews reported that "on each of those days, most certificates were issued within a window of 90 minutes." The attackers moved through three registries in five days and kept going after their first certificates were already revoked. On October 7, Let's Encrypt staff member Matthew McPherrin confirmed on the CA's forum: "Yes, certificates for Google and Youtube were issued, and have been revoked."

Which Google Domains Got Rogue Certificates?

Seven, by The Hacker News's count: google.com.gh, youtube.com.gh, google.sl, google.com.sl, youtube.sl, google.as and youtube.as. The outlet searched only a small set of Google and YouTube names, so the total may be higher. iTnews, checking CT logs against Chrome's blocklist, found "32 digital credentials issued to the attackers" across several brands, including one from Cloudflare's CA for a domain belonging to another major tech brand.

We checked independently. On October 14 we queried Cert Spotter's public API for google.com.gh, google.sl and google.as. Apart from Google Trust Services, Google's own CA, the only issuers were Let's Encrypt certificates: one for google.com.gh, two for google.sl and three for google.as. All six match The Hacker News's dates and SHA-256 fingerprints, and all six show as revoked (September 26 for .gh, October 1 for the others). Rate limits stopped us before we reached the YouTube names and google.com.sl.

The detail that matters for account security is the wildcards. Certificates for *.google.com.gh, *.google.sl, *.google.com.sl and *.google.as match any single label in front of those names. That includes accounts.google.com.gh, which resolves to Google's servers today and answered our request with a 302 redirect to https://accounts.google.com/. None of the reported certificates named accounts.google.com or mail.google.com themselves, and mail.google.com.gh returned no address when we looked it up.

Why Weren't the Certificate Authorities at Fault?

Because domain validation asks one question, who controls this name in DNS, and the attackers really did. A CA typically hands the applicant a random token to publish in a DNS record or serve from the domain, then looks it up. With the registry's authoritative records rewritten, the lookup returned the attacker's answer. Google wrote that "we have no reason to believe the Certification Authorities (CAs) that issued the impacted certificates did anything wrong." A Cloud Security Alliance research note adds that checking from several network vantage points would not help either, since "every vantage point retrieves the same altered records," though it labels that point an inference rather than a reported finding.

Compare this with the last famous rogue Google certificate. In August 2011, Google reported attempted man in the middle attacks against its users, "primarily located in Iran," using a fraudulent certificate issued by DigiNotar. That CA had itself been breached, and iTnews puts the haul at some 531 fraudulent certificates. The fix then was to stop trusting DigiNotar, and Google moved to do so alongside Mozilla and Microsoft. In 2026 there is no broken CA to remove. That is the real shift in this incident: the remedy moves out of the browser's root store and into the domain owner's own monitoring, which is exactly where Google's post puts the burden.

What Could an Attacker Do With a Rogue Google Certificate?

Impersonate the real site behind a valid padlock, but only for people whose traffic they can route to their own server. The certificate is half the attack; the other half is getting the victim's browser to connect. As The Register put it, in this attack "the attacker controls the traffic routing (via DNS) and the private key," so they could potentially read or alter what users send.

That holds while the hijack is live: whoever controls a registry's authoritative data, the CSA note explains, decides what every resolver sees beneath it. Afterward, a stolen certificate needs a different way into the path: a compromised router or a tampered gateway like the one in our report on hotel Wi-Fi rewriting DNS to steal inboxes. Revocation closes that second window, for clients that check it. Google's post does not say whether any of these certificates was used to pose as a Google site or capture data.

Why Email Users Should Care

Your Google account is your Gmail. A fake sign in page on accounts.google.com.gh, served over a valid certificate, would ask for exactly the password and second factor that unlock an inbox. The standard advice has a blind spot here. We usually tell readers to read the hostname, as in our recent piece on lookalike Unicode domains in Gmail. This time nothing about the name looks off, because the name genuinely belongs to Google.

A narrower habit still works: Google's password form lives on accounts.google.com, and the regional host we tested only redirected there.

Passkeys close the gap more completely. Under the W3C Web Authentication specification, a credential "can only be used for authentication with the same entity (as identified by RP ID) it was registered with," and a page can only claim an RP ID that is "a registrable domain suffix of or is equal to" its own domain. google.com is not a suffix of accounts.google.com.gh, so the browser will not offer a Google passkey there, valid certificate or not. Passwords and one time codes have no such binding. Passkeys do not stop every trick, though: our coverage of passkey themed phishing calls shows attackers simply going around them.

Which Defenses Worked, and Which Did Not?

Detection worked; prevention mostly did not. Here is how each control fared:

• Certificate Transparency: the hero of the story. Google notes that "every trusted-by-default certificate relied upon by Chrome must be disclosed in public CT logs," and CT data is how it found the other victims.
• CRLSets: Chrome's "primary means" of blocking certificates in emergencies. The Chromium page adds that online OCSP and CRL checks "are not generally performed by Chrome," which is why a pushed blocklist matters. For other clients, Google asked the CAs to revoke the certificates.
• CAA records: on October 7, all seven domains published CAA records naming only pki.goog, The Hacker News found, and our own lookups on October 14 returned the same. But CAA is served from the very zone an attacker controls during a hijack. Google says its value comes after DNS is restored, by blocking certificates minted from cached validations. RFC 8657 adds accounturi and validationmethods parameters to pin issuance to one ACME account.
• DNSSEC: our October 14 lookups found a DS record for .as in the root zone but none for .gh or .sl, and no DS record for any of the seven Google and YouTube names, or for google.com and youtube.com. DNSSEC can only vouch for names with an unbroken chain of DS records, and the registry is the party that publishes them.

Validation reuse is the slow fix. The Hacker News reports that Let's Encrypt reuses a completed domain check for 30 days, so an attacker who passed it during a hijack could keep requesting certificates afterward unless CAA stops them. The CA/Browser Forum's Ballot SC-081 cuts the maximum reuse period for domain validation data from 398 days to 10 days on a schedule running from March 2026 to March 2029.

What Should You Do Now?

Domain owners have the most to do. Google's guidance, plus steps from the wider coverage:

1. Monitor CT for every domain you hold, including parked and regional ccTLD names. Google calls out exactly those, and the CT project's monitor list is a starting point.
2. If you own anything under .gh, .sl or .as, review CT history now. The CSA note suggests starting from a date before September 22, since the window may be wider than reported.
3. Publish restrictive CAA records with account and validation method bindings where your CA supports them, as Google recommends. The CSA note also advises weighing registry lock where a registry offers it.
4. Report any certificate you did not request to the issuing CA. The Hacker News notes the Baseline Requirements oblige the CA to report initial findings within 24 hours.

For everyone else, the list is short. Google says Chrome users need no action. Add a passkey to your Google account, which Google says makes it "more secure against phishing," and treat a Google password prompt anywhere other than accounts.google.com as a red flag.

Has This Happened Before?

Yes. In November 2012, Pakistan's registry PKNIC admitted a breach that redirected some 284 domains, including google.com.pk, to a hacker's server. Between 2017 and 2019, the group Cisco Talos named Sea Turtle compromised at least 40 organizations in 13 countries, partly through registrars and one registry, and used CA signed certificates for "certificate impersonation."

PKNIC produced a visible redirect, and Sea Turtle already paired hijacks with trusted certificates. What is new in 2026 is the target, Google's own regional domains, and the speed: three registries in five days. Still unanswered: who did it, how the registries were breached, and whether they are secure now. Google also concedes that "we cannot guarantee that our analysis identified every affected domain."