The short answer
If attackers control the DNS for your domain, they can get a real, browser-trusted certificate for it. On October 6, 2026, Google’s Chrome security team said attackers hijacked the country-code registries for Ghana (.gh), Sierra Leone (.sl) and American Samoa (.as), changed authoritative DNS records and obtained valid HTTPS certificates for several Google domains and for other organizations.
Google says its own systems were not breached and that the certificate authorities appear to have followed the rules. Chrome blocked the certificates. The lesson for everyone else sits in the part of the stack most teams never look at: the registries, registrars and DNS and certificate automation behind your cloud setup.
How did attackers get real certificates for Google domains?
Before a certificate authority issues an HTTPS certificate, it checks that the requester controls the domain. A common method asks the requester to publish a DNS record containing a random value. Whoever can edit the domain’s authoritative DNS can pass that check. That is the whole point of domain control validation, and it is also its weak spot.
In this case the attackers did not go after Google. They went one level up, to the systems that run three country-code top-level domains. With control there, they rewrote the authoritative DNS for domains under .gh, .sl and .as, including Google’s local domains for those countries, and then requested certificates that any browser would trust. The Register and BleepingComputer both note that Google has not disclosed which CAs issued the certificates or which other companies were hit.
What did Google and Chrome do?
Google added the rogue certificates for its own properties to CRLSets, the mechanism Chrome uses to block certificates quickly in emergencies, and worked with the issuing CAs to revoke them so that other browsers and clients are covered too. It then searched public Certificate Transparency logs, found certificates for other organizations that looked tied to the same campaign, blocked those in Chrome as well and notified affected owners where it could. Google’s guidance is that Chrome users do not need to take any action.
The important caveat is Google’s own: because DNS hijacks are complex, it cannot promise it found every affected domain. Owners of domains under the three suffixes, and anyone whose brand has a country-code domain run by a small registry, should check their own certificate history rather than wait for a notification.
What it means for US & EU software teams
First, your TLS trust is only as strong as the weakest registry you depend on. Many companies register country-code domains for marketing, brand protection or local storefronts and then forget them. Those domains often sit with small registries and resellers whose security you have never assessed. A hijack there can produce a valid certificate for a domain your customers recognize.
Second, CAA records are no longer optional hygiene. A Certification Authority Authorization record tells CAs which of them may issue for your domain. Google specifically recommends restrictive CAA records that also limit issuance to your own ACME accounts and validation methods. It does not stop someone who fully controls your DNS from rewriting the record, but it narrows the routes for everyone else and makes issuance through an unexpected CA or account fail by default.
Third, Certificate Transparency monitoring turns a silent attack into an alert. Every publicly trusted certificate is logged. Watching those logs for your domains is how Google spotted the other victims, and it is the fastest way for you to see an unexpected certificate before it is used against your users. For EU entities under NIS2 or DORA, and for US companies answering SOC 2 or customer security questionnaires, “we monitor CT for our domains” is an easy control to evidence.
What should teams check this week?
- Inventory every domain you own. Include country-code domains, campaign domains and anything registered by agencies on your behalf. Note the registry and registrar for each.
- Search Certificate Transparency logs. Look for certificates issued since mid-September 2026 that you did not request, then set up ongoing CT alerts for the whole portfolio.
- Publish restrictive CAA records. Allow only the CAs you actually use and, where your CA supports it, bind issuance to your ACME account and preferred validation method.
- Turn on registrar and registry protections. Use registry lock where available, enable DNSSEC, enforce MFA on registrar accounts and review who has access.
- Retire or consolidate stray domains. A domain nobody watches is a domain nobody will notice when it is hijacked. Redirect it from a well-managed registrar or let it go deliberately.
Frequently asked questions
What happened with the .gh, .sl and .as domains?
Attackers compromised the systems used to run the country-code registries for Ghana (.gh), Sierra Leone (.sl) and American Samoa (.as), rewrote authoritative DNS records for domains under those suffixes, and used that control to obtain valid HTTPS certificates. Google disclosed the incidents on October 6, 2026.
Were Google's own systems breached?
No. Google says its systems were not compromised. The attackers controlled DNS for Google’s country-specific domains such as google.com.gh at the registry level, which was enough to pass the domain-control checks certificate authorities run before issuing a certificate.
Did the certificate authorities do anything wrong?
Google says it has no reason to believe the CAs that issued the certificates acted improperly. Domain control validation proves who controls a domain’s DNS at that moment, not who legally owns the domain, so a registry-level hijack defeats it by design.
Do Chrome users need to do anything?
No. Google blocked the identified certificates in Chrome through CRLSets and worked with the issuing CAs to revoke them, which also protects users of other browsers and clients. Google also blocked certificates it found for other affected organizations via Certificate Transparency logs.
What should our company do about it?
Publish restrictive CAA records that name only the CAs you use and, where supported, bind issuance to your own ACME account and validation methods. Monitor Certificate Transparency logs for every domain you own, including country-code domains. Review registrar and registry security features such as registry lock and DNSSEC.
Sources
Google — Chrome’s response to recent ccTLD registry hijacks
BleepingComputer — Hackers hijack Google domains after breaching ccTLD registries
The Register — Attackers hijacked top-level domains, minted fake security certs for Google and other orgs
SecurityWeek — Google domains impacted by recent ccTLD hijacks