Last week, hackers managed to break into the domain registries for Ghana, Sierra Leone, and American Samoa. They messed around with DNS records and snagged unauthorized TLS certificates for a bunch of Google domains—as well as other big names and popular online services. Google spilled the news, but at least their own systems stayed safe.
The attack wasn’t against Google itself. Instead, the hackers took advantage of the country-specific top-level domains—.gh for Ghana, .sl for Sierra Leone, and .as for American Samoa. That put every website using those endings in danger while the registry hijack was happening.
Google said it discovered what happened last week. They blocked any certificates they found in Chrome and teamed up with certificate authorities to revoke those covering Google’s domains. Using Certificate Transparency data, they saw other organizations had been hit too—including some global heavyweights and widely used services.
How did all this go down?
TLS, or Transport Layer Security, certificates, are those little digital credentials that help browsers check they’re really talking to the real owner of a website. They connect a domain name to a public cryptographic key, while the site owner keeps a private key locked away.
These hackers got control of the authoritative DNS records for select domains in the affected country codes. With control in hand, they could pass the automated checks that certificate authorities use before handing out certificates.
So if you can answer one of these validation challenges—even just for a moment—the certificate authority is convinced you’re in charge. Once the certificate is issued, the attacker can impersonate that website, intercept traffic, make phishing pages look real, and pull off other man-in-the-middle tricks.
Google said they saw no evidence the certificate authorities did anything wrong. The real problem wasn’t in the crypto system—it was upstream, in the DNS and registry systems that decide who’s allowed to prove domain control.
How did Google respond?
Right away, Google blocked the unauthorized certificates for their own stuff in Chrome using CRLSets. That’s the tool that lets Chrome toss out specific certificates quickly without making millions of people update their browser.
They also worked with certificate authorities to revoke trust beyond Chrome, to keep users of other browsers safe. If you’re on Chrome, you don’t need to do anything.
But there’s a hitch. Since DNS hijacks can get messy and may not last long, Google can’t promise they found every affected domain. Blocking in the browser isn’t foolproof—if you’re on a non-Chrome browser, you might not be protected.
That problem isn’t just technical; it’s a governance headache. Browser makers can deal with the immediate danger, but they can’t completely fix a compromised national domain registry or assure you that every fake certificate is gone.
The bigger issue
This whole mess shows how fragile the internet’s trust system is. Sometimes, the security of a global service hinges on a tiny national registry’s resilience.
Country-code domains often get run by organizations with limited resources, varying rules, and different tech capabilities. If one of those registries gets hacked, the fallout can reach far beyond the country.
The hackers didn’t need to break encryption or sneak past cryptographic libraries—they just had to get into the DNS and juggle records long enough to pass validation.
That’s what makes this case worrying. The internet’s security is only as sturdy as its weakest part, and domain registries often get treated like background noise instead of vital infrastructure.
What should domain owners do?
Google’s advice: don’t count only on browser fixes. Watch Certificate Transparency logs, which give you alerts if a certificate pops up for your domain unexpectedly.
This kind of monitoring lets you spot trouble almost in real time. If your domain ends in .gh, .sl, or .as, Google says it’s smart to check recent logs for anything suspicious.
Publish strict Certification Authority Authorization (CAA) DNS records—they tell certificate authorities who’s allowed to issue certificates for your domain.
While CAA records won’t stop an attacker during an active DNS hijack, they help once control is restored. They can block attackers from using cached validation info to get more certificates.
Trust goes beyond the browser
The takeaway? That little padlock symbol and browser warnings aren’t the end of the story. They rely on a whole chain of trust—domain registries, DNS operators, certificate authorities, and browser vendors.
Google’s quick fix is comforting, but it doesn’t erase the failure underneath. If hackers can hijack national domain infrastructure and get browser-trusted certificates for Google and other giants, that’s not just Google’s problem. It’s a broader failure in how the internet is governed.
Registries, national authorities, and everyone involved in domain management need to treat security with the same seriousness as banks or telecoms. That means tighter access controls, multi-factor authentication, rigorous audits, solid incident response, and international teamwork.
For businesses, the message is clear: domain security is cybersecurity. Keep track of every domain you own—including old or regional ones. Monitor certificate issuance and lock down which certificate authorities can sign for you.
The web’s encryption is tough, but the weakest links aren’t always glamorous. One rogue DNS record, a forgotten registry account, or a poorly defended national domain can leave even the most trusted sites vulnerable. Until every part of that chain is secure, impersonation risks remain.
