How it worked. Domain-validated certificates prove one thing: that the requester controlled the domain’s DNS or web traffic when the CA checked. Take over the registry that runs a TLD and you can repoint any name under it, pass that check honestly, and walk away with a certificate every browser trusts. That’s why Google isn’t blaming the CAs. The validation worked exactly as designed. The thing being validated was the attacker’s. Google said it became aware of the hijacks last week.
Why “we blocked them” isn’t the end of it. Google was blunt: it “cannot guarantee” its analysis found every affected domain, and Chrome’s blocks don’t reliably protect non-Chrome users. Revocation outside the browser is patchy. Plenty of mobile apps, API clients, Java trust stores and appliances never check revocation at all. If a cert for one of your names is still out there, those are the clients it works against.
The second trap is cached validation. CAs are allowed to reuse a completed domain-control check for later issuance. So an attacker who passed validation during the hijack may be able to mint fresh certificates after DNS is back in the owner’s hands. Google’s fix is a restrictive CAA record that pins issuance to specific CA accounts and validation methods, which shuts that path once you control DNS again. CAA does nothing while the hijack is live, because the attacker controls the CAA record too.
What we’d do this afternoon. Pull your full domain portfolio, including parked, regional and marketing ccTLDs, and check for anything under .gh, .sl or .as. Query Certificate Transparency (crt.sh or your CT monitor) for every name you own, with an eye on the last few weeks, and flag any issuer or ACME account you don’t recognize. Publish CAA with accounturi and validationmethods parameters (RFC 8657) on your primary names. If you find a rogue cert, get it revoked with the issuing CA and push the serial into whatever pinning or deny lists your mobile and API clients honor. Then put CT alerting on the whole portfolio, not just the dot-com. Most teams only watch the names they think about.
The bigger read. This is a supply-chain hit one layer above anything a CISO controls: the registry. Registrar lock and registry lock protect you from someone hijacking your account. They don’t help when the registry operator itself is owned. Google is using the incident to push its existing agenda: shorter certificate lifetimes and less reuse of domain validation, through the Chrome Root Program and its new Chrome Quantum-resistant Root Program. For buyers, it’s a fresh argument for CT monitoring and certificate lifecycle tooling that covers every domain, and for treating ccTLD sprawl as attack surface.
Desk sheet: .gh, .sl and .as ccTLD registries compromised; authoritative DNS changed for selected domains; unauthorized HTTPS certificates issued for several Google domains and other major brands; Chrome blocked identified certs via CRLSets and CAs revoked them; Google systems not compromised; CAs not faulted. Certificate count, affected brands, issuing CAs, attacker and initial access: Undisclosed.