Counterfeit TLS certificates for Google and other brands were issued without any certificate authority failing, which moves the weak point to domain registries, including the ones behind the defensive domains most organisations never monitor.
—
Google disclosed on 6 October 2026 that attackers had compromised the country-code top-level domains for Ghana, Sierra Leone and American Samoa, modified authoritative DNS records and nameserver delegations inside those namespaces, and obtained unauthorised HTTPS certificates covering several Google domains and domains belonging to other organisations. The Chrome Secure Web and Networking Team’s account is explicit that Google’s own systems were not compromised. The attackers went around them, to the registries that sit underneath every domain ending in .gh, .sl or .as.
Google blocked the certificates it found in Chrome and worked with the issuing certificate authorities to revoke them. Certificate Transparency logs then revealed additional organisations, “including several leading global brands and widely used online services”, believed to have been hit by the same attacks. Google blocked those too and reached out where it could.
Here is the point that should change how domain portfolios are governed. In 2011, counterfeit Google certificates came from a failed certificate authority. In 2026, every CA did its job and the counterfeit certificates were still issued. The weak point has moved upstream of the certificate system, to the namespace that domain validation trusts by design: a TLS certificate proves control of DNS, not the identity of the brand. Whoever controls a domain’s DNS for long enough to answer a validation check can obtain a fully valid certificate for it. An organisation’s ability to prove online that it is itself is only as strong as the weakest registry anywhere in its domain portfolio.
What the certificates actually prove
The mechanics are worth walking through, because the failure mode is not exotic. A certificate authority verifies domain ownership by asking the requester to demonstrate control of the domain, typically by publishing a DNS TXT record containing a random value the CA supplies. With control of authoritative DNS, an attacker answers that check on demand. The CA sees a valid response, issues a valid certificate, and does nothing wrong. Google said as much: “we have no reason to believe the Certification Authorities (CAs) that issued the impacted certificates did anything wrong.”
What the attacker then holds is not a fake in any technical sense. It is a genuine certificate, with the same standing as one the brand itself requested. Possession of it allows the attacker to cryptographically impersonate the affected infrastructure and to serve arbitrary content from those domains while doing so. The credential is real; the claim it appears to make about who is behind it is not. That is the same structural problem seen when document-image identity checks lose assurance value because the identity artefacts themselves have leaked: once the proof can be produced by someone other than the party it names, verification stops meaning what everyone assumes it means.
The historical comparison sharpens this. The 2011 hack of the Netherlands-based certificate authority DigiNotar let attackers mint counterfeit certificates for Google.com and more than 200 other high-traffic domains, and those certificates were used against at least 300,000 people with ties to Iran. As Ars Technica’s report on the current incidents notes, similar incidents since then have come most often through failures by certificate authorities, but also by domain holders. Fifteen years of scrutiny of certificate authorities, Certificate Transparency and browser distrust decisions were aimed at the DigiNotar-shaped hole. The 2026 incidents did not need it. And it is still not clear which other organisations were affected, how many unauthorised certificates were issued, or whether all of them have been blocked.
Why a parked domain is an attack path
The uncomfortable corollary concerns the country-code domains many organisations register defensively, precisely to stop impersonation. A brand registers the plausible regional variants so that nobody else can. Those domains are typically parked. They are held by whoever registered them years ago, sometimes a person or agency no longer involved. They tend to sit outside certificate monitoring, because nothing is being served from them. They are absent from third-party risk registers, because nobody thinks of a ccTLD registry operator as a supplier. Yet each one is a namespace in which an attacker who controls the registry can answer a domain control validation check in the brand’s name. The public account does not say which of the affected domains were live services and which were parked; the exposure exists either way.
A defensive registration that is not monitored like production is not a defence. It is unmonitored impersonation surface carrying the brand’s name. Google’s own guidance makes the scope concrete: monitoring should cover “their entire domain portfolio, including parked or regional ccTLD properties”, and anyone operating a domain in .gh, .sl or .as should review recent Certificate Transparency entries for unexpected issuance. Every certificate trusted by default in Chrome must be disclosed in public CT logs, which gives a near real-time alert when a certificate is issued for a domain. In this campaign, the additional affected brands were identified by Google reading those public logs, and Google then reached out to them where it could. The same public data was available to the brands themselves. “Who would have noticed first” is the test worth applying to any portfolio.
The incident also does not end when DNS control is restored. Certificate authorities are permitted to cache and reuse completed domain control validation checks for later issuance. Google’s advice is to publish restrictive CAA (Certification Authority Authorization) DNS records, ideally limiting issuance to specific authorised ACME accounts and validation methods. CAA cannot prevent issuance during an active hijack, but a restrictive policy restored afterwards stops an attacker from using cached validation state to mint new certificates once the hijack ends. The “all clear” moment is later than it looks, and it is decided by a DNS record many organisations have never reviewed.
There is also a boundary around the cleanup that deserves attention. Google’s Chrome-side blocking protected Chrome users, and Google is direct about the limits: “browser-side intervention should not be relied on to protect your users. Due to the complexity of DNS hijacks, we cannot guarantee that our analysis identified every affected domain, nor do Chrome interventions reliably protect non-Chrome users.” Anything that is not Chrome depends on revocation, which the reporting describes as slow and cumbersome. That includes other browsers, and by reasonable extension mobile apps, partner integrations and machine-to-machine API clients, none of which receive a Chrome block list.
What senior management should consider
The exposure this reveals is an ownership gap more than a technical one. A domain portfolio is usually split across marketing, legal, regional entities and outside agencies. The list of what was registered, by whom and why exists only in pieces inside the organisation. Until those pieces are assembled against Certificate Transparency logs and CAA coverage, nobody can say which registries the organisation is trusting to vouch for its name.
Boards should treat the domain portfolio as identity infrastructure, not as a marketing asset list. CISOs and CIOs should ask whether CT monitoring covers every domain the organisation owns, including parked and regional ccTLD properties, and who receives the alerts. Brand and marketing owners hold the defensive registrations and know why each one exists. Legal teams that hold domain registrations know the registrant records and the renewal history. Third-party risk and procurement should consider whether registry operators, and the agencies that register domains on the organisation’s behalf, appear anywhere in supplier governance. Google’s position is that “domain owners are in the best position to know which certificates and CAs are authorized for their namespaces”, which places the question squarely inside the organisation.
Two decisions follow. The first is continuous CT monitoring across the full portfolio, with a named owner for each alert. The second is restrictive CAA on every domain that matters, reviewed now rather than during an incident. Google says it will keep working on long-term improvements such as reducing certificate validity periods and domain-validation reuse; those help the ecosystem, but they do not tell any single organisation what it owns. Mapping the portfolio against CT logs and CAA coverage is work that outside analysis and the organisation’s own brand, legal and infrastructure people can only do together, because the inventory exists only in fragments. In this campaign, affected organisations were alerted to what had been issued in their name by a browser vendor reading public logs. The question for the next review is whether that would be true here.