Twelve Certificates Were Valid. Nobody Had Requested Them.

On 6 October 2026 Google published its response to what it describes as a series of domain hijacks in the .gh (Ghana), .sl (Sierra Leone) and .as (American Samoa) country-code top-level namespaces. Attackers compromised the third-party ccTLDs, modified authoritative DNS records and obtained unauthorised HTTPS certificates covering Google domains and the domains of other organisations. Google is explicit that the attacks "did not involve a compromise of Google's systems", and equally explicit that it has "no reason to believe the Certification Authorities (CAs) that issued the impacted certificates did anything wrong". Every certificate authority in the chain appears to have done what the rules require. The certificates were still valid, publicly trusted, and issued to the wrong party.

Most incidents give a board something to fix. This one does not. There is no CVE, no patch, no vendor advisory to schedule and no supplier to call, because the failure happened in a layer that almost no organisation has contracted for, inventoried or monitored. That is what makes it worth fifteen minutes of a leadership team's attention rather than a line in a threat feed.

The commercial point is simple. Your organisation's identity on the public internet is issued by parties you do not pay, validated through infrastructure you do not operate, and trusted by clients you do not control. None of that appears in your supplier register. All of it is load bearing.

What happened

• On or before 22 September 2026Attackers compromise the third-party operators of the .gh, .sl and .as namespaces and modify authoritative DNS records. Google confirms the compromise and the DNS modification but gives no dates of its own for the hijacks, so the dates below are the Certificate Transparency record rather than the attack timeline.
• 22, 25 and 27 September 2026Certificates for the .gh names, then the .sl names, then the .as names appear in Certificate Transparency logs, according to a review by The Hacker News using ctlogs.dev and Cert Spotter. At least twelve certificates across seven Google and YouTube domain names. Eleven from Let's Encrypt, one from ZeroSSL, all domain-validated. The researchers note they searched only a small set of names, so the true total may be higher. In records running back to at least 10 September, every other certificate for google.com.gh, google.sl and google.as came from Google Trust Services.
• 26 September and 1 October 2026Revocation, in two tranches on the same reported record: two .gh certificates and the single ZeroSSL certificate on 26 September, then nine certificates on 1 October. A Let's Encrypt engineer, posting as mcpherrinm on that project's community forum and referring to "our CRLs", has confirmed that certificates for Google and YouTube names were issued and have been revoked.
• The week before publicationGoogle becomes aware of the hijacks. Its only wording is that it learned of them "last week". Read against a post dated Tuesday 6 October, that points to the week commencing 28 September. Three certificates were revoked on 26 September, so its awareness may have been earlier. The week is our reading, not Google's date.
• Tuesday 6 October 2026Google publishes. It has blocked the unauthorised certificates for Google properties in Chrome via CRLSets, worked with the issuing CAs to secure revocation so that users of other clients are protected, reviewed Certificate Transparency data, blocked further certificates it believes are connected to the attacks, and contacted the affected organisations it could reach. It says Chrome users need take no action.
• Still openHow the registry operators were compromised. Who the attackers are and what they wanted. Whether any certificate was used to intercept or impersonate anything. The full list of affected domains, which Google says it cannot guarantee it has identified in full, and the identity of the other organisations Google describes as several leading global brands and widely used online services, and which it says it believes were impacted.

The scope, stated carefully

Twelve certificates across seven Google and YouTube domain names is a small number, and it should be reported as a small number. There is no evidence in the public record that any of these certificates was used against a real user. The researchers who found them searched a narrow set of names and say so. Google's own caveat runs the other way: it says it "cannot guarantee that our analysis identified every affected domain", and that Certificate Transparency data pointed to further affected organisations that it has not named.

Two other pieces of scope matter more than the count. First, control of a registry is control of every domain beneath it, so the population at risk during the hijack was not seven names but every name in three namespaces. Second, Google's protection was Chrome-shaped. It blocked the certificates in Chrome through CRLSets and then went to the issuing CAs for revocation precisely because, in its own words, Chrome interventions do not reliably protect non-Chrome users. Anything in your estate that validates certificates outside a modern browser, which means most machine-to-machine traffic, most mobile clients and most embedded devices, sits in the gap that revocation was meant to close.

Why this one is different

The usual shape of a trust-layer incident is a certificate authority behaving badly: lax validation, a mis-issued wildcard, an audit failure, and a root programme distrusting the CA in response. That is a story about a supplier, and supplier stories have supplier remedies.

This is not that. Nothing in the public record suggests the validation itself was defective. The CA asked the question it is required to ask, the DNS answered, and the answer was the attacker's. Google says so plainly and declines to blame the CAs. The integrity of the whole public certificate system rests on the assumption that whoever controls a domain's DNS is that domain's legitimate owner, and a registry compromise falsifies that assumption at the root. There is no control inside a certificate authority that fixes it, and there is no control inside your own estate either.

The chain that produced a valid certificate for a name the holder did not own. Every stage sits outside the organisation on the certificate.

There is a second, less obvious asymmetry. CAA records, the DNS mechanism that lets a domain owner name the only certificate authorities permitted to issue for it, live in DNS. An attacker holding authoritative DNS holds the CAA record too. The Hacker News checked the seven domains on 7 October, after DNS control had been restored, and found each carrying a CAA record naming only Google's own CA, pki.goog. What those records said during the hijack is not in the public record, and an attacker holding authoritative DNS could have rewritten them. Google states the principle directly: CAA cannot prevent certificate issuance during an active DNS hijack. The control you were told to deploy is the control the attacker inherits.

The hijack ends. The validation does not.

This is the part that converts a news item into a governance item, and it is the part most summaries have missed.

Certificate authorities do not revalidate control of a domain on every issuance. They cache the result and reuse it. Under the CA/Browser Forum Baseline Requirements, following ballot SC-081v3, the maximum reuse period has been 200 days since 15 March 2026. It drops to 100 days on 15 March 2027 and to 10 days on 15 March 2029. Let's Encrypt applies a shorter window of 30 days by its own policy, and has published a schedule taking that to 10 days in February 2027 and 7 hours in February 2028.

The consequence is that restoring control of your DNS does not restore control of your identity. An attacker who validated a domain during a hijack holds a cached entitlement that outlives the hijack, and can mint fresh certificates after you have taken your registry back. Google makes exactly this point in its remediation guidance: CAA cannot help you during an active hijack, but it "provides a critical safeguard after DNS control is restored" because restricting issuance to named accounts and methods stops an attacker using cached validation state to mint new certificates once the hijack ends.

Read that as a board would. The incident window for this class of event is not the duration of the attack. It is the duration of the attack plus the validation reuse period, and today the rules permit that to run to two hundred days. For these particular certificates it is shorter, because the CA that issued eleven of the twelve applies thirty days by choice. The ceiling, not the choice, is what your risk model has to assume for a CA you have not checked.

The dated sequence is Certificate Transparency research rather than an official timeline. The reuse schedule is the published CA/Browser Forum position.

The commercial exposure for UK organisations

Regulatory. The three compromised namespaces sit outside the European Union, and this is the uncomfortable part. NIS2 places DNS service providers and top-level domain name registries inside its digital infrastructure sector, with the supervisory regime that implies. That reach stops at the EU's borders. A UK or EU organisation can therefore be exposed, in a way that directly affects the confidentiality of data in transit, through an entity that no European regulator supervises and that it has no standing to audit. The UK's Cyber Security and Resilience Bill, now before Parliament, extends regulated scope towards managed service providers and strengthens supply chain duties, and it does not change this either. Regulation follows contracts and jurisdictions. This dependency has neither.

Contractual. Under DORA, financial entities must maintain a register of information covering contractual arrangements with ICT third-party service providers. The registry operator for a country-code namespace in which you hold a defensive registration is not a contractual arrangement. Neither, in most cases, is the public certificate authority your platform team selected through an automated ACME client. Both are structurally invisible to the instrument designed to make third-party dependency visible. That is not a criticism of DORA; it is a statement about where the gap sits.

Financial and operational. Quantify this the way you would any trust failure. If a valid certificate exists for your primary customer domain in someone else's hands, the exposure is session interception and credible impersonation, with the downstream cost sitting in fraud, customer remediation and the cost of telling a regulator you learned about it from a browser vendor's blog post. Add the operational cost of emergency rotation across an estate whose certificate inventory, in most organisations, is partial.

Governance. UK GDPR Article 32 requires security appropriate to the risk, including measures that ensure the confidentiality of personal data in transmission. It does not name Certificate Transparency monitoring, and no regulator has said it must. But the question a board should be able to answer is narrower and fairer than that: can we demonstrate that we would know, within a defined period, if someone obtained a publicly trusted certificate for one of our domains? For most organisations today the honest answer is no, and the reason is not cost. It is that nobody owns the question.

What leaders should do now

1. Produce the domain inventory, with owners. Every domain the organisation holds, including parked names, campaign names, brands acquired with a business, and country-code registrations held defensively. Google specifically asks domain owners to include parked and regional properties. If this cannot be produced within a week, that is itself the finding, and it is the finding that everything else depends on.

2. Turn on Certificate Transparency monitoring across all of it. Not just the primary customer domain. The alert must route to your own security function, not to a shared marketing mailbox or the registrar's dashboard. Google's remediation guidance is to review Certificate Transparency entries for issuance you did not request, and the organisations it could not contact are the ones that will find this out late.

3. Publish restrictive CAA records, bound to your ACME account. Name only the certificate authorities you actually use, and bind to a specific account where your CA supports it. Be clear with your team about what this buys: it will not stop issuance during a live hijack, and anybody who tells the board otherwise has misread the advisory. It stops cached validation being reused afterwards, which is the longer half of the exposure window.

4. Put the certificate problem report into the incident runbook. Name who files one, with which CA, and on what evidence. Under the Baseline Requirements a certificate authority must begin investigating a report within 24 hours and give a preliminary report to both the subscriber and whoever filed it. That clock only starts when somebody files, and nobody should be learning the process on the day.

5. Decide where public certificate authority trust is load bearing, and whether it should be. Machine-to-machine links, partner integrations, mobile applications and embedded clients inherit this failure mode in full and lose the browser-level mitigations that softened it for everyone else. Pinning or a private trust anchor on the paths that matter is an architecture decision with a long life, and it is the item on this list with the longest tail.

Three of the five are ownership and configuration. None of them requires buying a new product.

Three questions for the board

Can we produce, today, a complete list of the domains this organisation owns, including parked and country-code registrations, with a named owner against each one?

If a publicly trusted certificate for our primary customer domain were issued to somebody else tomorrow, which control would tell us, and how many days would it take?

Our supplier register and our regulatory filings name the providers we pay. Who issues our identity on the public internet, and are they on either list? For nearly every organisation the answer to the last part is no, and the discussion that follows is the useful one.

The strategic takeaway

Third-party risk management, as most organisations practise it, is a function of commercial relationships. You identify who you pay, you assess them in proportion to what you pay them, and you place obligations on them through contracts. It is a rational model and it has a blind spot the size of the internet: the dependencies that carry the most systemic weight are often the ones nobody invoices you for. Open-source maintainers. Public DNS infrastructure. The certificate authorities and root programmes that decide, on your behalf, who the world believes you are.

This incident is a clean demonstration of that blind spot. A registry in a jurisdiction you have never thought about was compromised. Authoritative DNS was rewritten. Certificate authorities behaved correctly and issued anyway. Google caught it, told the CAs, protected its own users first and warned that it cannot promise the list is complete. At no point in that chain was there an organisation you could have assessed, a questionnaire you could have sent, or a clause you could have negotiated.

The serious response is not to try to govern the ungovernable. It is to accept that this layer cannot be controlled and to instrument it instead, so that the first signal arrives from your own monitoring rather than from a vendor blog or a customer. Certificate Transparency exists precisely to make that possible, and it is free. The organisations that will handle the next one of these well are the ones that can name every domain they own and would see an unrequested certificate the day it appeared. That is a week of work and a named owner, and it is the difference between an operational task and a disclosure.

Confidence note

Confirmed. From Google's post of 6 October 2026: that it became aware of a series of domain hijacks in the .gh, .sl and .as country-code namespaces; that the attacks did not involve a compromise of Google's systems and that attackers compromised the third-party ccTLDs; that attackers modified authoritative DNS records and obtained unauthorised HTTPS certificates covering Google domains and the domains of other organisations; that Google blocked the certificates for Google properties in Chrome via CRLSets and worked with the issuing CAs to secure revocation; that Certificate Transparency log data revealed additional organisations, which Google describes as including several leading global brands and widely used online services and which it believes were impacted by the same attacks, whose certificates it also blocked in Chrome and which it contacted where possible; that it has no reason to believe the issuing CAs did anything wrong; that it cannot guarantee its analysis identified every affected domain; that Chrome interventions do not reliably protect non-Chrome users; and that CAA cannot prevent issuance during an active hijack but safeguards against reuse of cached validation afterwards. Separately confirmed on Let's Encrypt's public community forum by an engineer posting as mcpherrinm, who refers to "our CRLs": that certificates for Google and YouTube names were issued and have been revoked. The validation reuse schedule of 200, 100 and 10 days, with phase dates of 15 March 2026, 2027 and 2029, is the published CA/Browser Forum position under ballot SC-081v3; the 30 day figure is Let's Encrypt's own stated policy, and that CA has published a schedule reducing it to 10 days in February 2027 and 7 hours in February 2028.

Reported, and load bearing enough to flag. The certificate count of at least twelve across seven Google and YouTube domain names, the split of eleven Let's Encrypt and one ZeroSSL, the dated Certificate Transparency sequence of 22, 25, 26 and 27 September and 1 October, the observation that records back to at least 10 September show only Google Trust Services issuance for google.com.gh, google.sl and google.as, and the observation that on 7 October, after DNS control had been restored, all seven domains carried a CAA record naming only pki.goog, are all research published by The Hacker News on 7 October 2026 using ctlogs.dev and Cert Spotter. They are not an official count and the researchers state their search covered a small set of names, so the real total may be higher. Google named none of the other affected organisations, and describes them as believed to have been impacted rather than confirmed.

Assessed, and labelled as ours. That the controlling exposure is the absence of ownership and monitoring in the certificate and DNS trust layer rather than any defect in a reader's estate. That the effective incident window is the hijack duration plus the validation reuse period. The NIS2, DORA, UK GDPR Article 32 and Cyber Security and Resilience Bill read-across, including the argument that a non-contractual dependency cannot appear in a register built on contractual arrangements. Our reading of Google's "last week" as the week commencing 28 September, which the 26 September revocations may contradict. The five actions and the three board questions. None of this is stated by Google and it should not be read as endorsing any of it.

Not known. How the three registry operators were compromised; Google has not said and we will not guess. Who the attackers are and what they were trying to achieve. Whether any of these certificates was ever used to intercept traffic or impersonate a service; no source reports that it was, and that absence is not evidence that it did not happen. The identity of the other affected organisations, and the true total of affected domains. The registry operators have published no statement we could find, and neither has ZeroSSL. Whether any regulator, in Europe or elsewhere, will take an interest. We found no UK organisation named in connection with this at the time of writing, and that is not the same as no UK organisation being affected.

Garzon Cyber Solutions delivers cybersecurity advisory, compliance certification and specialist technology recruitment as one integrated capability for organisations in the UK, EU and beyond.