Illustration of an HTTPS address bar with the letter s crossed out in red next to a red bug icon — Attackers used hijacked ccTLD registries to obtain unauthorized HTTPS certificates. Image: Getty Images via Ars Technica.

DNS hijacking just showed how fragile web trust can be. Attackers took over three country-code domain registries. They used that control to get real TLS certificates for several Google domains and other big brands.

Google disclosed the incident on October 6, 2026. Ars Technica's Dan Goodin then reported how hackers obtained counterfeit TLS certificates for Google and other large services. Nobody broke into Google. The weak point sat one level above the websites themselves.

I coordinate projects where we look after client domains, so this one got my attention fast. Below is what happened and why it matters, even if you never touch a .gh domain. I have also added the checks I would run this week.

What Happened in This DNS Hijacking Incident

According to Google's Chrome Secure Web and Networking Team, the company became aware of a series of domain hijacks the week before its post. They hit three country-code top-level domains, or ccTLDs:

.gh (Ghana)
.sl (Sierra Leone)
.as (American Samoa)

Attackers compromised these third-party registries. That put every domain ending in .gh, .sl or .as at risk. They then changed authoritative DNS records and nameserver delegations for a chosen list of domains.

With DNS under their control, the attackers could pass the automated checks that certificate authorities (CAs) use to confirm domain ownership. That is how they walked away with unauthorized certificates covering "several Google domains" and domains of other organizations.

Google was clear on two points. Its own systems were not compromised. And it has "no reason to believe" the CAs that issued the certificates did anything wrong. The CAs followed the rules. The rules simply trust DNS.

Why Fake TLS Certificates Are So Dangerous

A TLS certificate is what puts the padlock in your browser. It binds a domain name, like google.com, to a public key. The site keeps the matching private key secret.

When those keys match, your browser trusts it is talking to the real site. So an attacker holding a valid certificate for your domain can impersonate your site cryptographically. Users see no warning at all.

That opens the door to:

Phishing pages that look and verify exactly like the real login page
Intercepting traffic between users and an app or API
Spoofing mail servers and other services that rely on TLS

This has happened before. Ars Technica points back to the 2011 breach of DigiNotar, a Dutch CA. Attackers minted fake certificates for Google.com and more than 200 other domains. They used them against at least 300,000 people with ties to Iran.

How Google and Chrome Responded

Google moved on two fronts. First, Chrome blocked the unauthorized certificates for Google properties using CRLSets, its built-in way to push certificate blocks to browsers quickly. Second, Google worked with the issuing CAs to revoke those certificates, so users of other browsers were protected too.

Then it went further. Certificate Transparency (CT) log data showed more victims, including "several leading global brands and widely used online services." Google blocked those certificates in Chrome as well and contacted affected organizations where it could.

Chrome users do not need to do anything. But Google added a warning that every site owner should read:

"While Chrome took steps during these incidents to identify and block suspected unauthorized certificates across the affected ccTLDs, browser-side intervention should not be relied on to protect your users."

Google also said it "cannot guarantee" its analysis found every affected domain. Ars noted it is still unclear how many certificates were issued or which other brands were hit.

Why DNS Hijacking Matters Beyond .gh, .sl and .as

You might think this is only a problem for sites on those three endings. It is not. The bigger lesson is about how certificates get issued everywhere.

Most certificates today are issued through automated domain control validation. The CA asks you to prove control by adding a DNS record or serving a file. If someone controls your DNS, even for a short while, they can pass that test.

A few points make this worse:

Registries sit above you. Your registrar, your DNS host and your server can all be secure while the registry itself is compromised.
Validation can be reused. Google notes that CAs may cache completed validation checks and reuse them for later certificates. An attacker may keep minting certificates after you win DNS back.
Revocation is slow. As Ars explains, formal revocation is cumbersome, which is why browsers built faster blocking tools.
Forgotten domains get missed. Parked and regional domains rarely get monitored, yet they still carry your brand.

For agencies in India and the USA, this hits close to home. Many of us manage a mix of .com, .in, .co.in, .us and other regional domains for clients. Each country-code registry runs its own security, and you depend on all of them.

The Two Fixes Google Recommends

Google's official post on Chrome's response to the ccTLD registry hijacks gives domain owners two clear steps. Both are cheap, and both are often skipped.

1. Monitor Certificate Transparency Logs

Every certificate that Chrome trusts by default must appear in public CT logs. That means you can watch for any certificate issued for your domains, in close to real time.

Google says monitoring should cover your entire domain portfolio, including parked and regional ccTLD properties. If you run anything on .gh, .sl or .as, review recent CT entries for unexpected certificates now.

Firefox certificate viewer showing embedded Signed Certificate Timestamps from DigiCert Yeti2021 and Google Xenon2021 Certificate Transparency logs — A certificate's embedded Signed Certificate Timestamps show which CT logs recorded it. Screenshot of Firefox 89 via Wikimedia Commons (MPL 2.0).

In practice, this can be simple. Free and paid CT monitors will email you when a new certificate shows up for a domain you list. Search tools like crt.sh also let you look up past certificates by hand.

2. Publish Restrictive CAA Records

A Certification Authority Authorization (CAA) record is a DNS entry that says which CAs may issue certificates for your domain. It is defined by the IETF in RFC 8659, the CAA standard.

Google is honest about the limit here. CAA cannot stop issuance during an active hijack, because the attacker controls DNS. But once you restore control, a strict CAA record blocks the attacker from using cached validation to get new certificates.

Google suggests going further with ACME account bindings. These limit issuance to a specific CA account and validation method. A basic record and a stricter one look like this:

example.com. CAA 0 issue "letsencrypt.org"
example.com. CAA 0 issue "letsencrypt.org; accounturi=https://acme-v02.api.letsencrypt.org/acme/acct/YOUR_ID; validationmethods=dns-01"

Swap in the CA and account your team actually uses. Test on a staging domain first, because a wrong CAA record will block your own renewals.

A DNS Hijacking Checklist for Agencies

Here is the short list I would hand to any delivery or DevOps lead today. Start with your biggest clients and work down.

Step	What to do	Owner
1. Inventory	List every client domain, including parked and regional ones	Account or project manager
2. CT monitoring	Add all domains to a CT monitor with alerts to a shared inbox	DevOps
3. CAA records	Publish CAA limited to the CAs and accounts you use	DevOps
4. Registrar security	Turn on MFA and registry or registrar lock where offered	DevOps and client
5. Review history	Check CT logs for certificates you did not request	Security lead
6. Response plan	Write down who calls the CA and registrar if a rogue certificate appears	Project manager

DNSSEC is worth having, since it helps against forged DNS answers. Just remember it cannot protect you when the registry itself is in an attacker's hands.

If your team already runs a patch cycle, fold these checks into it. Our guide on patch management lessons from the FBI Accenture breach shows how one missed step can turn into a client crisis.

What This Means for Your Clients

Most clients will never hear the word ccTLD. They will only notice if their login page gets cloned and their customers lose money. So it falls on agencies to explain the risk in plain terms.

A few talking points that work well in client calls:

The padlock is not a guarantee. It proves a certificate is valid, not that the right person requested it.
Domains are infrastructure. They need owners, monitoring and renewal plans, just like servers.
Small fixes, big payoff. CT alerts and CAA records cost little and close real gaps.

This also fits a pattern we keep seeing. Trust often breaks at a layer nobody is watching, whether that is a registry, a dependency or an AI agent protocol. We covered a similar trust gap in our post on MCP security and protocol pivoting attacks.

What Comes Next for TLS Certificates

Google says it will keep working with the wider industry to limit the damage from short-lived DNS and routing attacks. It points to two long-term changes: shorter certificate lifetimes and less reuse of domain validation.

That work runs through the Chrome Root Program and the new Chrome Quantum-resistant Root Program. In April 2025, the CA/Browser Forum approved a schedule to cut certificate lifetimes and validation reuse periods. The cuts arrive in steps over the next few years.

Shorter lifetimes mean renewals happen far more often. If your team still renews certificates by hand, now is the time to automate it with ACME. Manual renewals will not keep up.

Key Takeaways

Attackers hijacked the .gh, .sl and .as registries and used DNS control to get valid certificates for Google and other brands.
Google and the CAs were not breached. The CAs followed the rules, which is exactly why this is worrying.
Chrome blocked known bad certificates, but Google says site owners should not rely on browsers alone.
Monitor CT logs for your whole domain portfolio, including parked and regional domains.
Publish strict CAA records with account bindings to block reuse of cached validation.
Automate certificate renewals now, before lifetimes get shorter.

Want a second pair of eyes on your domain setup? Our team offers free software development consulting and can help you build a simple monitoring plan.

About the Author

Nitin Kumar is the Lead Project Coordinator at Debugged Pro. He works with development and DevOps teams across India and the USA to plan secure, well-run software projects. He writes about the tech news that affects agencies and their clients.