Hackers Hijacked Three Countries' Domain Registries and Used Them to Get Real HTTPS Certificates for Google

Somebody found a way to mint perfectly valid HTTPS certificates for Google without touching Google at all. They went after the plumbing instead: the third-party operators running three country-code domains, .gh (Ghana), .sl (Sierra Leone) and .as (American Samoa).

Google disclosed on Tuesday that attackers compromised those operators, which put every domain under those endings at risk. They then changed authoritative DNS records and used that control to obtain real certificates for several Google domains and for domains belonging to other large organizations. Chrome's Secure Web and Networking team learned about it last week.

"These incidents did not involve a compromise of Google's systems," the company said. More unsettling, it added: "we have no reason to believe the Certification Authorities (CAs) that issued the impacted certificates did anything wrong."

A certificate nobody issued by mistake

That second line explains why this one stings. Certificate authorities hand out certificates after domain control validation, often by asking the requester to publish a specific DNS record. Whoever controls DNS passes the test, whether or not they own the domain.

So the CAs followed the rules and the system worked as designed, for the wrong people. A valid certificate combined with redirected traffic makes for very convincing impersonation. The encryption still works fine; it just ends at the attacker.

Google has not said whether the certificates were used to intercept traffic or steal data. It also did not say how the registry operators were breached, who was behind it, or when it started, and it has published no certificate count or list of affected companies. The episode belongs to the same family of infrastructure-level takeovers as the Virtualizor BGP hijack, where control of the routing layer was enough to push a malicious update to servers.

Chrome is covered. Everyone else, maybe not

Google pushed the bogus certificates for its own properties into CRLSets, a list Chrome quietly downloads to reject bad certificates fast, and worked with the issuing CAs to revoke them. Certificate Transparency logs then surfaced certificates for other organizations, "including major global brands and popular online services," which Google also blocked in Chrome and flagged to owners where it could.

"Chrome users do not need to take any action to be protected," Google said. The catch is everyone else. Chrome's blocks do not reliably protect people using other browsers or apps, and Google admitted "we cannot guarantee that our analysis identified every affected domain."

For domain owners, Google's advice is to watch CT logs across the entire portfolio, including parked and regional domains, and for anyone holding .gh, .sl or .as names to review recent issuance. Restrictive CAA records, which can bind issuance to a specific ACME account and limit validation methods, cannot stop a certificate during an active hijack. They can stop attackers from reusing cached validation afterward. It is the unglamorous layer of web security, the same one Cloudflare has been hardening with post-quantum DNSSEC, and it rarely gets attention until something breaks.

Longer term, Google is pushing shorter certificate lifetimes and less validation reuse through the Chrome Root Program and its new Chrome Quantum-resistant Root Program.

The last time fraudulent Google certificates made headlines was 2011, when a breached Dutch certificate authority, DigiNotar, issued them. This time no authority was breached. The weak point was a national registry run by a third-party operator, and the padlock trusted it anyway.