Opinion. Attackers hijacked the .gh, .sl and .as country-code namespaces and obtained HTTPS certificates for other organizations’ domains. Google’s Chrome team blocked the certificates it found, then told domain owners not to rely on that. I think owners should watch certificate issuance for every domain they hold, including the ones nobody visits.
What happened
According to a post from Google’s Chrome Secure Web and Networking Team dated Oct. 6, attackers compromised the third-party ccTLDs for Ghana, Sierra Leone and American Samoa. The team says the incidents “did not involve a compromise of Google’s systems” and that the attackers modified authoritative DNS records and obtained unauthorized HTTPS certificates covering several Google domains and domains belonging to other organizations. Google says it has no reason to believe the certification authorities that issued the certificates did anything wrong.
Chrome blocked the certificates through CRLSets, and Google worked with the issuing CAs to get them revoked for clients other than Chrome. Certificate Transparency log data then showed additional organizations believed to be affected, which Google describes as including several leading global brands and widely used online services. Google blocked those certificates too and contacted the affected organizations where it could.
The warning inside the response
The most useful sentence in the post is a limit on Google’s own work. The team writes that “browser-side intervention should not be relied on to protect your users,” because it cannot guarantee its analysis found every affected domain and because Chrome interventions do not reliably protect people on other clients. The post then says “domain owners are in the best position to know which certificates and CAs are authorized for their namespaces.”
I agree with that division of labor. A browser vendor can see certificates for the domains it happens to look at. Only the owner knows the full list of names the organization holds and which certificates should never have been issued.
The strongest objection
The objection is that this is already handled. Chrome blocked the certificates, the CAs revoked them, and Google says Chrome users do not need to take any action. On that view, an owner’s own monitoring is duplicate effort.
Google’s post answers that itself. The same text that reassures Chrome users says the analysis may be incomplete and that non-Chrome clients are not covered by the browser block. The block also depends on someone at Google finding the certificate first. Owner-side monitoring removes that dependency.
What owners should do
Google’s post names two controls.
The first is ongoing monitoring of Certificate Transparency logs for all of your domains. Google points out that every certificate Chrome trusts by default has to be disclosed in a public CT log, so monitoring gives a near real-time alert when a certificate is issued for a name you hold. It asks organizations to cover the entire portfolio, including parked or regional ccTLD properties, and to review recent CT entries if they operate a domain in .gh, .sl or .as.
The second is a restrictive CAA record, bound to specific ACME accounts. Google is precise about the limit: CAA cannot stop issuance during an active DNS hijack. It protects the period after DNS control returns. Because CAs may cache and reuse completed domain control validation checks, a policy that limits issuance to authorized accounts and validation methods stops an attacker from minting new certificates from cached validation state once the hijack ends.
Both controls start from a list of names. Parked brand variants and regional domains are the entries most likely to be missing from it. The inventory discipline in An Exposure Inventory Decides Your First Hour After an Advisory applies to domains as much as to appliances. A stale portfolio list produces incomplete alerts.
The clock starts at issuance
CT monitoring changes when you learn about a problem. Advisories often arrive after exploitation has started, a gap argued in Start the Patch Clock on Release Day, Not Advisory Day. Google describes CT monitoring as a near real-time alert whenever a certificate is issued for your domains. A team that gets that alert can begin revocation and DNS recovery without waiting for a browser vendor’s block.
A hijacked registry has no vendor patch to apply, and registry operators sit outside any single owner’s control. What an owner controls is whether someone is looking at issuance for the names they hold.
Google also points to longer-term work on shorter certificate validity and less reuse of domain control validation. Those changes narrow the window, and the owner’s alert is still needed.
My recommendation for this week: export the full list of domains the company owns, including every ccTLD, subscribe each one to CT log monitoring with a named owner for the alerts, and publish CAA records bound to your ACME accounts. If any name ends in .gh, .sl or .as, read its recent CT history today.
Source: Google Chrome Secure Web and Networking Team, Chrome’s Response to Recent ccTLD Registry Hijacks
