Three country registries were hijacked to mint certificates for Google. Check your own forgotten domains

By Pippa - Published: 8 October 2026

Google disclosed on 6 October that attackers had taken over the registries behind three country-code domains, .gh for Ghana, .sl for Sierra Leone and .as for American Samoa, and used that position to obtain HTTPS certificates for Google and YouTube names under them. Google says its own systems were not breached. The most complete public account so far is The Hacker News's write-up, which also went and found the certificates in public logs, and Google's own post is worth reading in full.

How a registry hijack becomes a valid certificate

A certificate authority will issue a standard web certificate to whoever can show control of the domain, commonly by placing a given value in DNS. If you control the registry, you control the authoritative DNS records for every name beneath it, so you can pass that test for google.sl as easily as the real owner. Google says it has no reason to believe the CAs did anything wrong, and on the evidence that looks fair: the checks worked as designed, and the thing they trust was the part that failed.

The logs show at least 12 certificates covering seven names, among them google.com.gh, youtube.sl and google.as. Let's Encrypt issued eleven and ZeroSSL one. Issuance began on 22 September, revocations started on the 26th, and Google went public on 6 October. Google adds that the same attacks touched other organisations, including well-known global brands, and that it cannot guarantee it has found every affected domain. The real count is probably higher than twelve.

Why this matters if you have never heard of .sl

Most companies of any size own a handful of regional names, some of them registered years ago for a campaign, a market launch or a defensive purchase. They sit on whichever registry was convenient, usually with default DNS settings, and nobody checks them. A fraudulent certificate for one of those names lets an attacker stand up a convincing copy of your site, or intercept traffic for any service that uses that hostname, with a padlock to match. Chrome has blocked the certificates it knows about and the CAs have revoked them, but Google is plain that "domain owners should not rely on the browser to protect their users."

Three things to put in place

• Certificate Transparency monitoring for every domain you own, parked ones and regional ones included. This is how the hijack was noticed in the first place. Free monitors exist and most will email you when anything is issued that you did not request.
• A strict CAA record naming the CAs allowed to issue for you. Google's own domains had one, and it names only its own CA. Where your CA supports account binding under RFC 8657, use it. Be realistic about the limit: an attacker who controls DNS can edit the CAA record too, so it protects you after you regain control, and it stops the reuse of validations already granted. Those can be reused for up to 200 days today, dropping to 100 in March 2027.
• A way to act fast. Anyone can file a certificate problem report with the issuing CA, which must investigate and give first findings within 24 hours. Put the CA contact route in your incident runbook so nobody has to hunt for it at midnight.

The inventory question underneath

The unglamorous part is knowing which domains you own, which registrar and registry hold them, who can change their DNS, and whether that account has any protection beyond a password. We often find the answer lives in one former employee's spreadsheet. Registry lock services, where available, and tight control of the registrar account are cheap compared with the effort of explaining a spoofed login page to customers in a market you barely serve. If you would like help building that inventory, email sales@halfteck.com.