Attackers compromised the registries for three country-code top-level domains (Ghana, Sierra Leone and American Samoa). They changed authoritative DNS and used that control to get real, CA-issued HTTPS certificates for Google domains. No CA was breached. The attackers controlled DNS, and that was enough to pass domain validation.
What happened
In an October 6, 2026 post, Google's Chrome Secure Web and Networking Team said attackers had compromised the third-party registries behind .gh, .sl and .as. They modified authoritative DNS records and obtained unauthorized HTTPS certificates. Google says its own systems were not compromised. It also says it has no reason to believe the issuing Certification Authorities did anything wrong.
Chrome blocked the unauthorized certificates right away using CRLSets and worked with the issuing CAs to get them revoked. Google also searched Certificate Transparency (CT) logs, found certificates issued to other organizations, and blocked those too. Google did not name those organizations. According to Google, Chrome users do not need to take any action.
The Hacker News added detail from its own review of CT logs. It reports that the unauthorized certificates first appeared in CT logs on September 22 for .gh, September 25 for .sl and September 27 for .as. It counted 12 unauthorized certificates covering seven Google and YouTube domains, including google.com.gh, google.sl, youtube.sl and google.as. Per that report, Let's Encrypt issued 11 and ZeroSSL issued one. The two .gh certificates and the ZeroSSL certificate were revoked on September 26; the other nine were revoked on October 1. The Hacker News puts the gap between first CT log entry and revocation at about a day and a half at the shortest and nearly a week at the longest. The Hacker News also reports that a Let's Encrypt staff member confirmed the issuance on the CA's community forum. None of the coverage names an attacker.
Why it matters
Domain-validated certificates are a form of machine identity, and they are only as trustworthy as whoever controls DNS for the name. This incident shows that the weak point can be several steps away from you: past your registrar and DNS provider, at the registry that runs the TLD. If an attacker can answer a CA's validation challenge, they get a certificate browsers trust. With that and a network position, they can impersonate your login pages, API endpoints or federation metadata URLs.
Two controls limit the damage. CT monitoring tells you when a certificate is issued for your names. CAA records restrict which CAs, and ideally which CA account, may issue for them. Google recommends both. The Hacker News points to a caveat in the CAA standard itself: an attacker who can remove or forge CAA records during a DNS hijack can still get a certificate issued, so CAA alone would not have stopped this. Binding CAA to a specific ACME account, plus fast detection through CT, is what narrows the window.
Google framed this as one more reason for its ongoing Chrome Root Program work on shorter certificate validity and less reuse of domain validation (DCV reuse). Expect CA policy to keep moving that way.
What to check in your environment
- List every domain you own on
.gh,.slor.as, including parked and regional variants. For each, review CT log entries from September 22 onward for certificates you did not request. - Make sure CT monitoring covers your whole domain portfolio, not just your main brand domains, and that alerts go to someone who can act on them.
- Publish CAA records that name only the CAs you actually use. Where your CA supports it, tie the record to your own ACME account, as Google recommends.
- Check which of your identity-critical hostnames (SSO portals, IdP endpoints, SAML/OIDC metadata URLs, API gateways) sit on ccTLDs or on registries you have never assessed. Record who the registry operator is.
- Write down how you would report a mis-issued certificate. The Hacker News notes that CAs must investigate a Certificate Problem Report and give initial findings within 24 hours. Know where each CA you use accepts these reports.
- Review how your certificate automation would cope with shorter validity and shorter domain-validation reuse periods. That direction comes from both Chrome and the CA/Browser Forum schedule The Hacker News describes.