eMudhra Weak CA Keys: Windows, Cloudflare and Developer Trust Store Fixes

Windows admins have two reasons to pay attention. Six of the impacted certificates are for TLS and trusted by the Chrome, Mozilla, Microsoft and Apple root programs. The other two certificates are for codesigning and trusted by Microsoft, according to Mozilla's Bugzilla incident record. So this isn't only a browser problem. It also touches the Windows code-signing trust chain.

How the keys failed​

Normally, a CA key gets into the wrong hands through theft, a breach or an insider. Nothing like that happened here. The keys were generated so badly that anyone could work them out.

Mozilla's bug record says the eight affected keys were P-384 elliptic-curve keys, created on April 30, 2025 in a key ceremony that produced a batch of 24 intermediates. A P-384 private key should be a random integer somewhere between 1 and an enormous group order. All eight affected keys were integers below 256, which means almost every byte was zero except the last one. Mozilla says its own staff recovered the keys independently and almost instantly. It also notes that a simple brute force over the first 256 possible P-384 keys is enough to find them.

To prove the compromise, the researcher who reported it, identified only as Wayne, signed the following message with the private key of each of the eight intermediate CAs and reported it to the Root Program Teams on the 17th of October. Security researcher Scott Helme says he independently pulled all 16 (8 keys, each used in two issued certificates: once by eMudhra and once by Sectigo) and brute-forced them.

In the Mozilla bug thread, eMudhra gave its explanation. The company had approved a change to its usual ceremony so it could test key wrapping and unwrapping. A flaw in its script created a second, weaker set of keys on the HSM. Because the key labels looked alike, those weak keys were used by mistake to build the certificate signing requests. eMudhra says the same CSRs then went to Sectigo for cross-signing. It also says its RSA intermediates were generated another way and are not affected.

eMudhra's public statement says the incident does not affect its root CA private keys or other intermediates. It adds that none of the affected intermediates issued end-entity certificates, which it says matches public Certificate Transparency records. That is eMudhra's own account. The proven fact is that the keys can be recovered, and an attacker could have issued certificates from them at any point.

Section summary: Nobody stole these keys. They were badly generated, can be recovered trivially, and six of them are TLS intermediates that root programs trusted for everything.

How the browsers and Microsoft responded​

The disclosure site lists Microsoft's date but no mechanism. One independent write-up on lorbic.com says Microsoft pushed updates to its Certificate Trust List (CTL) through Windows Update, ensuring that CryptoAPI and Schannel drop trust in the compromised keys. Microsoft has not published that detail. Until it does, treat it as a reasonable expectation rather than a confirmed fact.

The browsers then went further. After Mozilla learned that several people had recovered the keys on their own, Dennis Jackson wrote in the bug thread that it would make an emergency removal of the emSign ECC Root CA - G3 root. Google says it is also dropping that root from the Chrome Root Store. Google expects the change to reach all devices that rely on that store on October 27, 2026 (PDT), and to reach Canary and Beta sooner. Legitimate sites on that root will stop working as a result. Google tells operators to get a replacement certificate from a different hierarchy right away.

In the bug thread, eMudhra says it has stopped issuing from every intermediate under G3. Its early estimate is about 30,000 certificates that need migrating, roughly 97% of them issued through ACME, and it plans to move them to its RSA-based G1 hierarchy. Mozilla says it is not removing trust in emSign Root CA - G1 for now.

Google also says no TLS certificates chaining to six of the intermediates appeared in Certificate Transparency logs before it blocked them. That means clients that enforce CT, including Chrome by default, could not have been fooled by forged certificates from those intermediates. Clients that don't enforce CT get no such protection.

Section summary: Browsers and Windows were covered within about three days. Removing the G3 root goes beyond blocking the keys and will cause problems for legitimate eMudhra customers too.

Cloudflare: work beyond the browser​

Cloudflare says it learned of the compromise around 17:00 UTC on October 19. It patched critical services before public disclosure and says it has found no active exploitation on its services. Its timeline:

• October 20, 02:00 UTC: Updates published for the Cloudflare One Client (WARP) and the 1.1.1.1 app. The iOS Cloudflare One Agent was still waiting on App Store review.
• October 20, 09:15 UTC: Cloudflare Tunnel (cloudflared) update published.
• October 20, 19:20 UTC: CDN and server-side Zero Trust mitigations fully deployed.

Cloudflare lists these minimum versions:

• Cloudflare One Client / WARP: Android 2.5.6, iOS 1.12.16, and 2026.8.2115.0 on Windows, macOS and Linux.
• 1.1.1.1 app: Android 6.38.10, iOS 6.31.7, and 2026.8.2115.0 on Windows, macOS and Linux.
• cloudflared: 2026.10.2. For container deployments, update and redeploy the fixed image.

For things customers run themselves, Cloudflare recommends:

1. Mutual TLS: Review the CA certificates you have uploaded or configured to verify client certificates, and remove any affected ones.
2. Origin servers: If you use Full (strict) or Strict mode, review your custom origin certificates and server configuration. Cloudflare says Automatic SSL/TLS will alert customers who are still using distrusted certificates.
3. Cloudflare Containers and Sandboxes: Check images and dependencies for affected trust stores, then rebuild or redeploy. You can also turn on HTTPS egress interception, which sends outbound HTTPS through Cloudflare so that Cloudflare's trust-store fixes apply. Cloudflare says containers with that setting enabled are already protected.

Developers: check the dependencies, not just the SDK​

For developers, Cloudflare's main point is that updating the SDK may not be enough. An API client can hand certificate checks to an HTTP library, a language runtime, the operating system or a custom trust configuration. If you only update the SDK, the trust policy actually in use may not change.

Here's what that looks like on Windows. A .NET service that relies on Schannel picks up whatever trust changes Microsoft pushes. A Python tool on the same machine that bundles certifi does not, and neither does a Node app or a Go binary that brings its own roots. A browser test on that machine tells you only about the browser.

Go is one example of a runtime-level fix. daily.dev reports that a Go crypto/x509 change distrusts the eight intermediates' keys and that the fix was backported to the Go 1.26 and 1.27 branches, landing in versions 1.26.10 and 1.27.3. Check the version numbers against Go's official release notes before you rely on them.

A practical checklist:

1. Update OS CA bundles, language runtimes and pinned dependencies, including indirect ones in your dependency tree.
2. Rebuild container images. A patched host doesn't fix a stale image.
3. Restart or reload services so they pick up the new trust stores.
4. Test through the TLS path each application actually uses. Mozilla's Dennis Jackson runs a test site that checks browsers, explains how to test non-browser clients, and keeps a crowdsourced list of patched packages. Cloudflare notes that results only cover the verification path being tested.
5. Do not disable certificate verification to get rid of new errors. In Cloudflare's words: Revocation alone does not protect every application. Turning off verification removes the protection you're trying to restore.

curl on macOS​

iTnews tested the macOS copy of curl and found it still accepted certificates from the compromised chain, even after Apple's block. It reports that curl checks certificates against its own /etc/ssl/cert.pem file and doesn't consult revocation information. Another public advisory says the same: On macOS, the built-in /usr/bin/curl checks certificates against /etc/ssl/cert.pem without checking revocation, and that file has not been updated.

The workaround iTnews attributes to Jackson is to remove two roots from that file: emSign ECC Root CA - G3, and Sectigo's AAA Certificate Services, which cross-signed the weak keys. Be careful with it. Sectigo says AAA Certificate Services is still trusted in Microsoft's and Apple's root programs, so removing it may break other legitimate connections. Install vendor fixes where they exist, and edit system trust files only if you understand what else they affect.

The underlying problem: slow revocation outside browsers​

This incident shows a long-standing weakness in web PKI. Cloudflare notes that browser vendors could fix this almost instantly with fast revocation channels such as CRLSets, while operators may have hundreds of applications to update. Mozilla said much the same in its bug, writing that many endpoints do not have effective mechanisms for getting revocation information. Cloudflare backs Canonical's upki project, which aims to make trust stores something that can be updated quickly with revocation and CT data instead of a fixed list of roots.

There's a reasonable counterpoint. eMudhra says no end-entity certificates were issued from the affected intermediates, and nobody has reported active attacks. Still, the keys can be recovered by anyone, so the absence of reported attacks doesn't tell you much. Until every application you run has a trust store without these intermediates, consider it exposed and keep patching.