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.
A CA distrust decision reaches browsers and OS stores through vendor-controlled paths, and stops short of everything else until someone owns the update.
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.
Scope. This post does not claim that any specific client in your estate is exposed. It describes mechanisms, update ownership and tests, and it labels every example row illustrative, not measured.
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
Update ownership decides whether distrust reaches a client class, and for runtimes and SDKs the owner is untraced.
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):
Client classes and who owns the update:
- Browsers. The vendor controls the fastest paths (CRLSet, OneCRL). Your team owns version policy for managed fleets.
- Operating-system stores. The OS vendor sets the list and your patch team applies it. Apple's block, per iTnews, reached devices on October 19.
- Vendored bundles. A certificate file ships with or beside the application, and the application owner decides when it changes. The curl case above is this class.
- Container and base images. The bundle is fixed at build time. Cloudflare advises applying the relevant dependency updates, rebuilding affected images and redeploying.
- Language runtimes and SDKs. An HTTP client may defer to the library, the runtime, the OS or a custom store. Until someone traces the call path, the owner is unknown.
- Firmware and appliances. The list is fixed in the image and changes with a vendor release.
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
A passing browser test says nothing about the verifier your service actually uses.
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:
01 — NAME THE VERIFIER
List your client classes and name the verifier each one uses.
02 — FIND THE TRUST SOURCE AND OWNER
For each verifier, find its trust source and the person who owns changing it.
03 — FIND THE AFFECTED CERTIFICATES
Find the certificates in your estate that chain to emSign ECC Root CA - G3.
04 — TEST THE ACTUAL TLS PATH
Test each class against the affected chain through its actual TLS path, using the test that matches the verifier. iTnews reports that Mozilla's Dennis Jackson published a test site at emudhra.we-have-a-problem.com. iTnews describes it as a check of whether a browser still trusts the compromised intermediates, so treat it as a starting point; it does not verify any other client class's verifier.
05 — RECORD THE RESULT AND THE DECISION
Record the result and the decision from the table above. Do not disable verification to clear an error.
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.
Architect's Verdict
A CA distrust decision is made by a trust program, but protection is demonstrated only when a client consumes the relevant change and its actual verifier rejects the affected chain. Chrome clients that received the CRLSet update were covered without a browser update. A root removal takes effect in a client only after the vendor ships the trust-store change and the client consumes it; for Chrome that is the release expected on October 27. Neither reaches a bundle in a base image until someone rebuilds the image.
The real problem is that most estates cannot say which verifier each client uses, who owns that verifier's trust source, or which mechanism reaches it. The eMudhra incident did not create that gap. It put a date on it.
A CA distrust decision becomes protection one verified verifier at a time.
Additional Resources
- Modern Infrastructure & IaC Architecture — the pillar guide for the control-plane, drift and lifecycle problems this inventory belongs to.
- Rotating Credentials Is Not Revoking Them. The Revocation Unit Decides Whether You Can. — the revocation unit and residual window this post builds on.
- The Root KSK Rollover Is Done. Did Your Resolver's Trust Anchor Change? — the fixed-anchor update path for resolvers, stateless containers and firmware.
- Secure Boot Trust: Who Owns the Virtual Firmware State — who initiates and who executes updates to trust state.
- A ccTLD Hijack Turns Authoritative DNS Into Certificate Evidence — the earlier CRLSet block of unauthorized certificates.
- Google: Protecting Chrome and Android users from compromised eMudhra intermediate CA certificates — the CRLSet timing, the update paths and the Chrome root removal.
- Cloudflare: 8 eMudhra certificates are compromised. Here's what you need to know — operator guidance on trust stores, images and non-browser clients.
- Mozilla Bugzilla 2083449 — Mozilla's incident record, including the key batch and eMudhra's preliminary account.
- iTnews: Cloudflare warns fixing botched eMudhra certs goes beyond browsers — the curl finding and the certificate-file workaround.
- eMudhra: to exit the global SSL/TLS certificate business — the CA's own statement on revocation, issuance and migration.
Originally published at rack2cloud.com
Top comments (0)