ccTLD Hijacks Led to Rogue Google Certificates: What to Check

Google said on October 6, 2026 that attackers compromised three country-code domains, .gh (Ghana), .sl (Sierra Leone) and .as (American Samoa), changed DNS records and obtained unauthorized HTTPS certificates for Google domains and for other organizations. Chrome now blocks them. Google asks every domain owner to take two steps.

What we know

Who is reporting it: Google's Chrome Secure Web and Networking Team, on the company's security blog, on October 6, 2026. It says it learned of the hijacks the week before.
What happened: attackers compromised the three ccTLDs, which third parties run, and modified authoritative DNS records. That let them obtain unauthorized HTTPS certificates covering several Google domains and domains of other organizations, according to Google. Any domain ending in .gh, .sl or .as was at risk. Google's own systems were not compromised.
The certificate authorities: Google does not name them and says it has no reason to believe they did anything wrong.
What Chrome did: it blocked the certificates for Google properties through CRLSets, its mechanism for blocking certificates, and worked with the issuing authorities to get them revoked. Public Certificate Transparency logs then showed more organizations hit, including global brands Google does not name, and Chrome blocked those certificates too.
How many certificates: Google gives no number. The Hacker News searched those public logs on October 7 and counted at least 12 certificates for Google and YouTube names under the three ccTLDs, logged between September 22 and 27: 11 from Let's Encrypt and one from ZeroSSL, all revoked by then. A Let's Encrypt staff member confirmed on October 7, on its community forum, that they were issued and have been revoked.
What is not known: Google does not say who is behind it, how the attackers got in, whether the three ccTLDs are secure again, or whether any certificate was used to impersonate a site.

What changes and what doesn't

People browsing with Chrome do not need to do anything, Google says. There is also no urgent step for a domain outside those three ccTLDs.

What changes is what you can take for granted: the browser padlock rests on DNS, and whoever controls a domain's DNS can request a valid certificate in its name. Google is direct about the limits of its own fix: "browser-side intervention should not be relied on". It cannot guarantee it found every affected domain, and Chrome's blocks do not reliably protect people on other browsers.

By this article's count, 14 days passed between the first certificate The Hacker News lists (September 22) and Google's post (October 6).

One caveat: a CAA record does not stop issuance during an active DNS hijack, Google says. It helps afterwards, because authorities may reuse a completed domain validation for a while and a restrictive CAA record, especially one bound to a specific account, keeps an attacker from using it. That window is shrinking: in April 2025 the CA/Browser Forum approved bringing it down to 10 days by March 2029, and Let's Encrypt announced in December 2025 that it will cut its own from 30 days to 7 hours by 2028.

How to tell if this affects you

Directly, if you run a .gh, .sl or .as domain: Google asks you to review recently issued certificates. Its two measures apply to any domain. Six steps:

See which certificates exist for your domain. Every certificate Chrome trusts by default has to appear in public logs, according to Google. The Certificate Transparency site links to search tools such as crt.sh: type your domain and read the list.
Learn to read it. A long list is normal: free certificates last a few months and renew on their own. What stands out is an issuer that is neither your host's nor your CDN's, or a subdomain nobody created.
Turn on an alert. A monitor emails you when a new certificate is issued for your domain. The same site lists 16 services, among them Cert Spotter, Report URI and Cloudflare's email alert.
Check whether you have a CAA record. It is a DNS record that says which authorities may issue certificates for your domain. Without one, any public authority that validates control may issue, Let's Encrypt's documentation explains. You can look it up with an online DNS tool by choosing the CAA type.
Before publishing one, find out who issues your certificate. Click the padlock on your site and read the issuer. A CAA record that leaves that authority out will make the next renewal fail. If a CDN serves its own certificate for you, its authority has to be listed too. This warning is this article's own.
Where it goes. In the DNS zone editor at your host, or wherever your DNS is managed. For Let's Encrypt the record uses the "issue" tag and the value "letsencrypt.org", according to its documentation. On shared hosting, ask: which authority issues my certificate, and can I add a CAA record?

Binding the CAA record to an account is the version Google recommends. Let's Encrypt supports that through the accounturi parameter, but on shared hosting that account usually belongs to the provider.

If you find a certificate you did not request, report it to the authority that issued it: according to The Hacker News, it must give a first report within 24 hours.

Sources

Updates: this line will be extended if Google, the operators of the three ccTLDs or the certificate authorities publish how it happened, how many domains were affected or whether any certificate was actually used.