Attackers Hijacked Three Country Domains to Get Real Google Certificates.

ccTLD registry hijack header

For at least 11 hours in late September, someone other than Google could prove they controlled google.sl. Certificate authorities took that proof at face value and issued real HTTPS certificates. Browsers would have treated the connection as secure. Nothing about the site would have looked wrong.

In this article
  1. What Happened
  2. Why Controlling DNS Means Controlling Certificates
  3. Why DNSSEC and Registry Lock Didn’t Help
  4. Is Your Domain at Risk?
  5. Three Things You Can Do Today
  6. What Happens Next
  7. Common Questions About the ccTLD Hijacks
  8. The Bottom Line

Google disclosed the attacks on October 6. Attackers had broken into the systems behind three country domains, .gh (Ghana), .sl (Sierra Leone) and .as (American Samoa), and used that access to get valid certificates for Google, YouTube and other big brands.

You almost certainly weren’t a target. But this attack exposes a weak spot that applies to every domain, including yours, and the fixes are free.

What Happened

According to Google’s disclosure, the attackers compromised the outside operators that run those three extensions. Google’s own systems were never breached. With control over the extension’s DNS, the attackers changed the records for domains underneath it and pointed them at servers they controlled.

The attacks came in three waves. The .gh certificates were issued on September 22, .sl followed on September 25, and .as on September 27. Google says it learned of the attacks the week before its post, and Chrome then blocked the certificates using CRLSets, its emergency blocklist. Google also worked with the certificate authorities to revoke them.

The Hacker News searched public certificate logs and found at least 12 certificates covering seven Google and YouTube domains, all revoked by October 7. Let’s Encrypt issued 11 of them and ZeroSSL issued one. A security researcher on Mozilla’s certificate policy forum found a much larger total across the whole campaign:

Extension Country Attack date Certificates
.gh Ghana September 22 23
.sl Sierra Leone September 25 69
.as American Samoa September 27 10

That’s 102 certificates in total. The same researcher linked it to a similar hijack of Uganda’s .ug in May, which suggests this wasn’t an isolated case.

Plenty is still unknown. Nobody has named the attackers or explained how the operators were breached, and Google says it can’t guarantee its analysis found every affected domain.

Why Controlling DNS Means Controlling Certificates

Free certificate authorities like Let’s Encrypt don’t check passports or company records. They check one thing: can you prove you control the domain? Usually that means placing a specific file on the website, or a specific record in its DNS. Pass the check and you get a certificate.

So whoever controls a domain’s DNS can get a valid certificate for it. Normally that’s you. But your DNS sits inside a chain: your domain lives under a top level domain like .com or .sl, and the registry running that extension has the final say over where your domain points. Take over the registry and you can take over any domain under it, at least for a while.

The certificate authorities did nothing wrong here. From their side, the attacker passed a legitimate check.

Why DNSSEC and Registry Lock Didn’t Help

If you’ve read our guide to DNSSEC, you might wonder why it didn’t stop this. The short answer: DNSSEC protects the chain of trust, and the registry is part of that chain. The registry publishes the DS record that links your domain to it. Control the registry and you control which keys count as valid.

Registry lock has the same blind spot. It stops changes coming through a compromised registrar or customer account, but it can’t protect you from an attack on the registry operator itself.

Neither tool is useless. They block far more common attacks. But this is a reminder that some risks sit outside your control, which means detection matters as much as prevention. Curious whether your own domain uses DNSSEC? Run it through our free DNSSEC Checker.

Is Your Domain at Risk?

If your site uses .com, .net or .org, this specific attack doesn’t touch you. Those extensions are run by large, heavily audited registries.

Country domains are more varied. Some are run by well resourced national bodies. Others rely on small teams or private operators. That’s worth knowing because several popular “startup” extensions are actually country domains: .io (British Indian Ocean Territory), .ai (Anguilla) and .co (Colombia). Nothing links them to this campaign. Still, if your business runs on one, it’s worth knowing who operates it.

The bigger lesson applies to everyone. Your domain is only as secure as every company in the chain above it: your registrar, your DNS provider and the registry. You can’t audit them all, but you can make sure you’d notice quickly if something went wrong.

Three Things You Can Do Today

None of these cost anything, and together they take about half an hour.

1. Watch for certificates you didn’t request

Every publicly trusted certificate gets recorded in Certificate Transparency logs. That’s how researchers found these ones. You can search the logs for free at crt.sh by typing in your domain. Services like Cert Spotter can go further and alert you whenever a new certificate appears for your names.

Google’s advice is to cover every domain you own, including parked ones and country versions. An attacker will happily target the domain you forgot about.

2. Add a CAA record

A CAA record is a DNS record that lists which certificate authorities are allowed to issue certificates for your domain. A basic one looks like this:

example.com.  CAA  0 issue "letsencrypt.org"

For tighter control, some authorities, including Let’s Encrypt, support an accounturi parameter that limits issuance to your specific account, so even someone using the same authority can’t get a certificate.

Be honest with yourself about what this does. A CAA record can’t block a certificate during an active hijack, because the attacker can edit it along with everything else. Where it helps is afterwards. Certificate authorities can reuse a completed domain check for a while, and a strict CAA record stops an attacker cashing in on one after you’ve regained control. Test it carefully, since a wrong record can block your own renewals.

3. Lock down your registrar account

This attack went through the registry, but many real domain hijacks go through the owner’s registrar account. Turn on two factor authentication, use a unique password, and keep your contact email current. If your registrar offers registry lock and the domain matters to your business, it’s worth the cost. Our guide on how to secure a WordPress site covers the rest of your setup.

If you do spot a certificate you didn’t request, report it to the issuing authority. Under industry rules, it must investigate and share initial findings within 24 hours.

What Happens Next

The industry was already moving to shrink the window attackers get from a single successful check. Let’s Encrypt is cutting how long it reuses a domain check from 30 days to 10, and plans to bring that down to seven hours in 2028. Industry rules currently allow up to 200 days, dropping to 100 in March 2027 and 10 in March 2029.

Shorter reuse windows mean a stolen check expires faster. Combined with shorter certificate lifetimes, which we covered in the end of the one year SSL certificate, the damage from attacks like this one keeps shrinking.

The open questions are about the registries themselves. None of the three operators has said publicly how they were breached or whether they’re fully secure again.

Common Questions About the ccTLD Hijacks

Can someone get an SSL certificate for my domain without my permission?

Only if they control your domain’s DNS or website, even briefly. That’s why registrar security matters, and why monitoring certificate logs is the best way to catch it if it ever happens.

Do I need to do anything if I use Chrome?

No. Chrome already blocks the known certificates. Google notes that its block doesn’t reliably cover other browsers, but the certificate authorities have also revoked them.

Would DNSSEC have stopped this?

No. The attackers controlled the registry, which sits above your domain in the DNSSEC chain of trust. DNSSEC still protects against other attacks, like forged DNS answers, so it’s not a reason to skip it.

Is my .io, .ai or .co domain safe?

Nothing links those extensions to this campaign. They are country domains, though, so it’s sensible to set up certificate monitoring and a CAA record, just as you would for any domain your business depends on.

What is a CAA record?

It’s a DNS record that names the certificate authorities allowed to issue certificates for your domain. Any authority not on the list has to refuse.

The Bottom Line

This attack didn’t need a stolen password or a careless site owner. It needed control of the registry, and that’s something no individual domain owner can prevent.

What you can control is how fast you’d find out. Search crt.sh for your domain today, add a CAA record, and turn on two factor authentication at your registrar. If something like this ever touches your domain, you’ll know in hours instead of weeks.