A valid certificate proves someone held DNS, not that they own the domain

In late September 2026, attackers obtained publicly trusted HTTPS certificates covering several Google domains and domains belonging to other organisations. The natural reading of that headline, that a certificate authority was compromised or Google itself was breached, is wrong on both counts, and Google's 6 October incident write-up says so in its opening paragraph: "These incidents did not involve a compromise of Google's systems; rather, attackers compromised the third-party ccTLDs, putting any domain ending in .gh, .sl, or .as at risk." The same post adds that "we have no reason to believe the Certification Authorities (CAs) that issued the impacted certificates did anything wrong."

That is the part worth writing down. No CA was breached, no validation check failed, no signature was forged. The attackers took over three country-code top-level domains, edited the authoritative DNS records inside them, and then passed domain control validation exactly the way a legitimate applicant would. The certificates they received were ordinary, valid, correctly chained certificates, which is precisely why they worked.

What actually happened

Three registry operators fell, one per zone, over six days.

Date (2026)	ccTLD	Zone
22 September	.gh	Ghana
25 September	.sl	Sierra Leone
27 September	.as	American Samoa

iTnews reports that on each of those days most of the certificates for that zone were issued inside a roughly 90-minute window. Let's Encrypt staff engineer Matthew McPherrin confirmed issuance on the CA's community forum on 7 October: "Yes, certificates for Google and Youtube were issued, and have been revoked." The certificates were mostly wildcards from Let's Encrypt and Sectigo's ZeroSSL. iTnews also reports one further certificate from Cloudflare's CA; that report is single-source and no second outlet has corroborated it, so treat it as unreported rather than established.

Nobody agrees on how many

Two newsrooms ran their own CT-log tallies three days apart and they do not reconcile. The Hacker News searched two CT services on 7 October and found 12 certificates across 7 domains, eleven from Let's Encrypt and one from ZeroSSL, logged on the three days above. iTnews checked the CT record against Chrome's blocklist and counted 32 credentials across the same window.

Neither published a full methodology, and The Hacker News states plainly that its own search covered a limited set of names and "the real total is probably higher." Both figures are lower bounds from incomplete searches rather than competing answers to a settled question. Any single number quoted without that caveat is overstating what anyone knows.

Google names no affected non-Google organisation, describing only "several leading global brands and widely used online services," and is direct about the limits of its own analysis: "Due to the complexity of DNS hijacks, we cannot guarantee that our analysis identified every affected domain."

The certificates were valid, which is the whole problem

A browser accepts a server certificate when it can build a path from that certificate to a root in its trust store, every signature along the path verifies, the name in the certificate matches the hostname the user typed, and the certificate is inside its validity window. How that chain is assembled takes a while to explain properly. The short version is that every one of those conditions is a statement about cryptography, and none of them is a statement about authority.

Run the list against this incident:

• The signature verified. Correctly. Nothing was forged.
• The chain terminated at a real root. A public root is trusted by every browser in the world, and shared across many issuers.
• Domain control validation passed. Because the attacker really did control the DNS at the moment of validation. The CA asked "does this applicant control google.sl?" and, at that instant, the answer was yes.
• The name matched. The hostname the user typed is the hostname on the certificate.

Every check returned the correct answer because the attacker had made the answers true. There is no field anywhere in X.509 recording that the legitimate operator of a domain consented to a particular certificate; that question sits outside the data structure entirely.

The inverse case makes the point faster than any explanation. A self-signed certificate is rejected precisely because nothing vouches for it. These certificates were accepted precisely because something did vouch for them. If you have read what a certificate actually asserts and come away thinking a valid one is a claim about ownership, that reading needs adjusting. It is a claim about a chain of signatures plus a control check that DNS answers.

Issuance is not interception

What is confirmed: the attackers obtained certificates. What is not confirmed: that anyone presented them to a real client. No source reports decrypted traffic, inspected content, or redirected users.

	Certificate issuance	Active interception
What happened	Attacker obtains a valid certificate for someone else's domain	Attacker sits between client and server
Is a certificate enough	Yes	No — necessary, not sufficient
Traffic exposed	Not necessarily, and not here	Yes, by definition
How it surfaces	CT log review, CAA audit, revocation	TLS interception, proxy detection

A certificate gets you the second column's precondition. You still have to get the traffic to arrive at your server rather than the real one, and DNS control during an active hijack would have delivered that too. Nobody has said it happened, and the difference between "they could have" and "they did" is the difference between a capability and an incident.

Attackers take whichever door is open, and there are at least three. The CA falls, as with DigiNotar in 2011, when roughly 531 fraudulent certificates for *.google.com were minted and later investigators found about 300,000 unique IP addresses, almost all in Iran, requesting google.com with them. The registry falls, as with Pakistan's PKNIC in 2012, where 284 .pk domains including google.com.pk were redirected to an attacker-controlled server, and ICS-Forth, operator of Greece's .gr registry, in 2019. An account falls, as when a registration authority working with Comodo lost an account and nine fraudulent certificates appeared for Google, Yahoo, and Microsoft names.

This incident is the registry door. That class difference matters more than it looks. In a CA compromise the trust anchor itself fails, and the certificates it issues are fabricated end to end. Here the trust anchor held, the issuance process worked, and the input the process was asked to vouch for was false. Arguing that the CAs should have caught this inverts the mechanism: the applicant did control the domain, temporarily, genuinely, and by every automated means available to check.

What the defences do, and what they do not

Certificate Transparency discloses, it does not prevent

The CT log protocol (RFC 6962) requires certificates to be published to append-only logs that anyone can read. Google's framing is the practical one: "every trusted-by-default certificate relied upon by Chrome must be disclosed in public CT logs, monitoring CT logs provides a near real-time alert whenever a certificate is issued for your domains."

Near real-time is not before the fact. A CA may issue and then log, and the certificate works from the moment it is issued. The attacker does not care that you can see it. What CT actually did here was retrospective forensics: Google's post says that "Following our initial mitigation, Certificate Transparency (CT) log data revealed additional organizations" beyond the ones Google had identified itself. It found the scope. It did not stop the attack, and it could not have.

CAA is useless during the hijack and useful after it

Certification Authority Authorization (RFC 8659) lets a domain publish a DNS record naming which CAs may issue for it. The common claim is that a CAA record would have blocked this. It would not have, and Google says so without hedging: "While CAA can not prevent certificate issuance during an active DNS hijack, it provides a critical safeguard after DNS control is restored."

The reason is structural. CAA lives in DNS, and the attacker had DNS. They could rewrite the record or there may have been none. The value is in what happens next. CAs cache completed domain control validation and reuse it for subsequent issuance, so a hijack can keep paying out after it ends. Restoring a restrictive CAA record, particularly one carrying the ACME account and validation method bindings from RFC 8657, stops an attacker riding that cached validation to mint fresh certificates for names they no longer control. This is the load-bearing half of CAA, and it is the half most coverage omits.

Revocation and CRLSets are two different mechanisms

Most write-ups collapse these into "Chrome blocked them." They are separate, and they reach different populations.

Chrome blocked the unauthorised certificates through CRLSets, pre-distributed blocklists that ship to clients ahead of any revocation infrastructure. They exist because of how Chrome handles revocation in the first place. Chromium's own documentation is blunt: "Online (i.e. OCSP and CRL) checks are not generally performed by Chrome," and "CRLSets are the primary means by which Chrome quickly blocks certificates in emergency situations." Enterprise policy can turn online OCSP checks on. The default path is a pushed blocklist.

Separately, Google worked with the issuing CAs "to ensure the certificates were revoked to protect users in clients other than Chrome." That is the mechanism that reaches Firefox, Safari, and mobile clients, and it is the one that mattered most, since the CRLSet route is Chrome-only. Google says so itself: Chrome interventions "do not reliably protect non-Chrome users." The Hacker News tally gives the timing: the shortest gap between a certificate's first log entry and its revocation was about a day and a half, the longest nearly a week.

Pinning is not the answer, and it is no longer available

HTTP Public Key Pinning (RFC 7469) let a site declare which public key or SPKI hash its connections must use. Browsers removed support after it caused widespread outages when sites mis-pinned themselves and bricked their own connections. It was also pointed at the wrong problem here: pinning an intermediate or a CA key does not distinguish a legitimate issuance for your name from an illegitimate one. The key was legitimate. The authority to use it for that name was not.

The structural direction

Google points past monitoring at the rules themselves: CABF Ballot SC-081 v3, which schedules maximum certificate validity down from 398 days to 47 and SAN validation data reuse down from 398 days to 10, running from March 2026 to March 2029. Shorter windows mean less time for a stolen credential to be useful. Less validation reuse means a hijack that ends stops paying out.

Three things this incident does not prove

A valid certificate is not proof of a legitimate owner

It proves that a chain of signatures verifies and that someone passed a control check that DNS was in a position to answer. Ownership is not a cryptographic property, and no amount of certificate inspection recovers it. If you are building anything that treats a valid chain as an authorisation decision, this is the failure to design against.

Certificate issuance is not evidence of interception

The certificates are confirmed. Their use is not, by anyone. A certificate in a CT log, or one your browser encountered, tells you an attacker held issuance capability during a window. It does not tell you anyone's traffic was read.

Certificate Transparency does not prevent mis-issuance

It publishes. It is the reason the victim list is longer than the list Google started with, which is a detection win and a disclosure win, not a prevention win. Any framing that treats CT as a control which "stops" fraudulent certificates has the causality backwards.

What we still do not know

Three gaps, and none of them is closed. Marking them as gaps is more useful than filling them with plausible guesses.

How the registry operators were compromised. Google did not say, and declined further comment before publication. iTnews says it contacted the operators behind .gh, .as, and .sl and received no responses. No registry operator has published a post-mortem. This is the central unknown, it is not a detail, and any account of the intrusion method circulating now is speculation.

Whether the certificates were ever served. No published evidence either way.

The full victim list. Google names no non-Google organisation and explicitly disclaims completeness of its own analysis. The two CT tallies differ by more than a factor of two. Treat the scope as open.

What you can check on your own domains

If you run anything under a hijacked ccTLD, or more generally if you own names, the two actions Google recommends are worth an afternoon. Both are listed in the CT monitor directory, and crt.sh and Cert Spotter are two of the searchable front ends to the same logs.

Watch issuance across the whole portfolio, including parked and regional ccTLD properties, which are the ones nobody reviews and are exactly the ones an attacker picks. Then publish a restrictive CAA record bound to your own ACME accounts and validation methods, so that if DNS control is lost today, cached validation from the loss cannot be redeemed for a new certificate tomorrow.

Google's own reassurance is scoped: "Chrome users do not need to take any action to be protected" refers to Google's Chrome-side response to the certificates it found, and the same post cautions against relying on that. Check what your own hosts are actually serving before you assume the answer is no.

Related Tools & Further Reading

• SSL Checker — read the live chain, issuer, and expiry on your own hosts rather than inferring it.
• What is an SSL certificate chain? — how the path to a root is built, and why a valid one says nothing about ownership.
• What is an SSL certificate? — the fields a certificate asserts, and the ones it does not.
• Reading a certificate error: string, cause, fix — the inverse case, where nothing vouches for the certificate at all.