A CA Distrust Decision Is Not Protection Until Every Verifier Has Consumed It

CA distrust is decided by a trust program, but it is enforced one verifier at a time, and each verifier consumes the decision through its own update path. A vendor’s action establishes what the vendor changed. It does not establish that each of your clients has consumed that change: CA distrust does not protect a client until that client’s actual verification path has consumed the change and rejected the affected chain in a test.

The general point that revocation at a unit is not instantaneous at every verifier is already made in the revocation unit post, which names the trust root as a revocation unit. This post covers the layer beneath it: how CA distrust reaches each client class, who owns each class’s update path, and what test shows rejection. Google’s scheduled root removal on Tuesday, October 27 makes that inventory time-bound.

What the eMudhra incident decided, and what it did not

Google says the Chrome Root Program received a report at 18:05 UTC on Saturday, October 17, 2026, and landed a CRLSet update at 19:45 UTC. Mozilla’s bug records its Firefox block as complete at 22:59 UTC the same day, shipped to clients through Mozilla’s RemoteSettings service. The same bug records eMudhra’s revocation of the eight certificates at about 09:38 UTC on October 18.

Mozilla’s preliminary investigation traces eight affected keys to a batch of 24 intermediates that eMudhra generated on 30 April 2025. The eight are the P-384 keys in two of the three series, and each private key was an integer below 256. A positive private-key integer below 256 has at most 255 possible values; the key-generation weakness is what matters here. Six of the eight were TLS-issuing intermediates and two were code-signing intermediates; this post covers the six TLS intermediates and the roots above them.

eMudhra’s preliminary account, recorded in the bug while its investigation was still open, describes a flaw in its key-generation ceremony script that produced a second, weaker key pair, with the wrong pair selected because the labels were similar. Treat it as preliminary.

Two statements about certificates issued from these keys should stay separate. Google says no TLS certificates chaining to the six intermediate CAs it names were logged to Certificate Transparency before the block. eMudhra says no end-entity certificates were issued from the affected CAs. The first is an observation about CT logs and does not establish the state of every certificate or client. The second is the CA’s own claim about its issuance.

Three mechanisms, three client populations

Across a modern infrastructure architecture, the eMudhra response used distinct CA distrust paths: Firefox OneCRL, Chrome CRLSet, and root-store removal in Chrome and Mozilla. They do not reach the same clients or share a single deployment schedule. For each client class the questions differ: does it consume this mechanism, and what does the mechanism match on?

Mechanism	Consumed by	Delivery path and observed timing	Identifies by	Covers (capability)	Does not cover	Collateral effect
Firefox OneCRL block	Firefox	Mozilla’s RemoteSettings service; complete 22:59 UTC, October 17	Not established in the sources read	Firefox clients that consume OneCRL updates; client-level coverage not established	Clients that do not consume OneCRL	Not established
Chrome CRLSet block	Chrome; Android devices through Google Play Services	CRLSet update with no browser update or restart; Play Services update around 22:00 UTC on Monday	Public key (SPKI hash), per Google	Clients that received the CRLSet update, including Android devices once Play Services updated	Clients that do not consume CRLSet updates	None described in Google’s post
Chrome Root Store removal of emSign ECC Root CA – G3	Clients that use the Chrome Root Store	Chrome release expected Tuesday morning PDT, October 27, with earlier Canary and Beta builds, per Google	Trust anchor (the root)	Chains anchored at G3 in clients that have received the release, including clients that do not consume CRLSet	Clients not yet updated; clients with their own bundle	Every legitimate chain under the root; Google says operators must install a certificate from another hierarchy
Mozilla NSS removal of emSign ECC Root CA – G3	Clients that use Mozilla’s NSS root store	Mozilla decided on emergency removal; release timing not established	Trust anchor (G3 only; G1 not removed at that time)	Not established	Not established	Not established

The table separates what a mechanism can cover from what the sources show was deployed, and says “not established” where the sources read do not say. Mozilla decided on emergency removal of emSign ECC Root CA – G3 and stated that it was not removing emSign Root CA – G1 at that time. The Chrome and Mozilla root removals are separate decisions on separate schedules. Google presents the Chrome root removal as the answer for clients that do not consume CRLSet updates.

CRLSet is not new to this incident. Google used it to block the unauthorized certificates in the hijack covered in A ccTLD Hijack Turns Authoritative DNS Into Certificate Evidence.

What a mechanism identifies decides what it covers

A CA distrust block can match on a key, a certificate, an issuer or a trust anchor. That choice decides what it covers. A block by public key applies to every certificate that carries the key. A certificate entry applies to that certificate. A root removal applies to everything beneath the root. None of these is better in the abstract, and not every client supports every one of them.

This matters because one key can sit in more than one certificate. iTnews reports that Mozilla’s Dennis Jackson suggested curl users remove two roots from their certificate file: emSign ECC Root CA – G3 and Sectigo’s AAA Certificate Services, which iTnews describes as having cross-signed the weak keys. Removing a root from a bundle carries the same collateral effect as any other root removal.

So a CA distrust inventory records the identification basis for each mechanism as a description. It is a fact about the control, not a prescription for how every client must match.

Client classes that do not share an update mechanism

Cloudflare’s incident guidance states the ownership gap in CA distrust plainly. A browser test does not show that a background service is protected, and neither does a curl test if the application uses a different verifier. Updating an SDK may not change the policy underneath it. Cloudflare says to look beneath the SDK and not to resolve errors by disabling verification. It reports learning of the compromise on October 19, publishing client-app and tunnel updates on October 20, and completing its CDN and server-side mitigations later that day.

iTnews adds a concrete case: curl on macOS still accepted certificates from the chain after Apple’s block, because curl checks its own certificate file and, per iTnews, does not consult revocation information.

Six client classes recur in an estate, and each can have a different owner (one team may own several):

The root KSK rollover post describes the same fixed-anchor pattern for DNSSEC trust anchors, in stateless containers that return to what the image shipped and in firmware where the update path is a release. Who initiates a trust-state update and who executes it is its own question, and Secure Boot Trust: Who Owns the Virtual Firmware State works through it for virtual firmware. The same question applies to every row of the inventory below.

The CA distrust inventory

The CA distrust inventory has one row per client class, and one set of columns that turns the mechanism table into something you can act on. It records the verifier, where it gets its trust, who owns the update, how the change arrives, what the mechanism matches on, and the test that shows the affected chain is rejected. The identification column holds whatever the actual mechanism and configuration turn out to be; cells marked “depends” stay unresolved until someone traces the verifier.

Client class	Verifier	Trust source	Update owner	Propagation mechanism	Identifies by	Distrust test
Browser, managed fleet	The browser’s own verifier	Vendor blocklists and root store	Browser vendor; your team owns version policy	Vendor blocklist push; browser release	Key or anchor, per mechanism	Load a chain containing the affected intermediate and confirm rejection
OS store, servers and workstations	System TLS library	OS vendor’s trust store	OS vendor; your OS patch team	OS update or vendor distrust list	Depends on the OS vendor’s mechanism	Validate the affected chain with the system verifier, not a browser
Vendored bundle, app ships a PEM file	Application’s TLS library	Bundle file shipped with or beside the app	Application owner	Package release or file replacement	Depends on what the bundle contains and how the library matches	Run the application’s own connection code against the affected chain
Container base image	Library inside the image	Bundle fixed at build time	Image owner or platform team	Rebuild and redeploy	Depends on the bundle and library in the image	Run the test inside a running container from the current image and record the image digest
Language runtime or SDK	HTTP client, runtime or OS, depending on configuration	Runtime’s, OS’s or a custom store	Unclear until traced	Runtime or SDK release, or a configuration change	Depends on the verifier	Trace which verifier the call path uses, then test that path
Firmware or appliance	Embedded TLS stack	Fixed list in firmware	Hardware vendor	Firmware release	Depends on the shipped list and the TLS stack	Ask the vendor for the shipped list; probe the device where you can

These rows are illustrative, not measured. They show what to record for each class, not what any product does.

The CA distrust inventory earns its place when each result maps to a decision.

Inventory result	Decision it supports
Rejects the affected chain on its actual path	Record the test and the date. No change.
Accepts the chain; an update owner and mechanism exist	Trigger the update and retest the same path.
Accepts the chain; no owner is named	Assign an owner before choosing a fix.
Accepts the chain; the only fix is rebuild or replacement	Schedule the rebuild or replacement, or isolate the client and put an expiry on the accepted risk.
Legitimate certificates chain under the root being removed	Inventory and replace those certificates before the removal reaches the client.
The client cannot be updated, tested or isolated	Record an accepted exposure with a named owner and a review date.

Removing a root is one answer among several, not the default. Whether it is the right one depends on the trust path, on whether the client supports a narrower control such as a direct block, and on which legitimate chains sit beneath that root.

Before October 27: what to test

Google says the Chrome removal of emSign ECC Root CA – G3 is expected Tuesday morning, October 27, PDT, with earlier availability in Canary and Beta. Google says operators whose certificates chain to that root must install a certificate from another hierarchy in the Chrome Root Store to avoid breakage. eMudhra says it will contact affected customers and replace certificates free of cost from partners.

Work the inventory in this order:

What this post does not establish

It does not establish the state of any estate, including yours. It does not establish how any operating system, container image or firmware family handles the affected chain; those need client-specific evidence. Mozilla’s NSS release timing for the G3 removal is not covered. The available sources also do not establish OneCRL’s identification basis, client-level coverage, or collateral effects. eMudhra’s account of the cause is preliminary and its investigation was ongoing. The Mozilla bug raises other concerns about these intermediates; this post does not treat them or draw a causal link to the key compromise. Nothing here says the two code-signing intermediates behave like the TLS ones.

Additional Resources

View 2 more resources ↓

>_ External Reference

iTnews: Cloudflare warns fixing botched eMudhra certs goes beyond browsers

the curl finding and the certificate-file workaround.

>_ External Reference

eMudhra: to exit the global SSL/TLS certificate business

the CA’s own statement on revocation, issuance and migration.