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:

• Mutual TLS: Review the CA certificates you have uploaded or configured to verify client certificates, and remove any affected ones.
• 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.
• 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:

• Update OS CA bundles, language runtimes and pinned dependencies, including indirect ones in your dependency tree.
• Rebuild container images. A patched host doesn't fix a stale image.
• Restart or reload services so they pick up the new trust stores.
• 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.
• 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.

Update: eMudhra certificate issue reportedly helps delay Fedora 45 (October 23, 2026)​

The compromised eMudhra certificates have reportedly become a release-blocking issue for Fedora 45, extending the incident’s impact beyond application updates to an operating-system release schedule. According to XDA Developers’ October 23 report, citing Phoronix and Fedora’s blocker documentation, the release has been postponed until November 3 at the earliest.

According to XDA Developers, the certificate-related blocker says Fedora still accepts the compromised intermediates and calls for a trust update before Fedora 45 ships. That makes this more than a recommendation to patch after installation: the reported release decision treats the unresolved certificate exposure as a reason not to distribute the new version yet.

The certificate problem is not the sole cause of the delay. XDA Developers reports three other blockers involving LVM autoactivation after an upgrade, Plasma Discover offering outdated Fedora 44 packages, and a boot failure affecting encrypted Stratis pools. November 3 should therefore be treated as the earliest reported release opportunity, not a guarantee that resolving the certificate issue alone will clear Fedora 45 for release.

For IT teams managing Fedora alongside Windows, the immediate planning implication is to allow for the delayed rollout. The reported blocker also reinforces the need to check Linux trust updates separately rather than assuming browser or Windows mitigations protect those systems.

Update: eMudhra reportedly plans to leave the global TLS certificate business (October 23, 2026)​

Spiceworks reports that eMudhra has announced it is leaving the global TLS certificate business and plans to re-verify every key ceremony it has conducted. The report adds that eMudhra said the affected keys were generated on FIPS 140-2 Level 3-certified hardware and that its hierarchy had passed two independent audits—checks that, according to Spiceworks, did not catch the weak keys.

Spiceworks also reports that revocation lists for the affected intermediates had been failing signature checks since spring 2025. If confirmed, that would mean a warning sign was publicly available well before the October disclosure, though the report says the issue was not connected to the weak keys until a researcher examined public records.

For IT teams, the reported exit could mean changes to certificate issuance and renewal arrangements for organizations using eMudhra’s TLS services. Windows admins should continue verifying that trust-list updates reach their systems, especially offline machines or devices where automatic updates are disabled; Spiceworks says Microsoft distributes the blocks through automatic trust-list updates. The report also says Linux distribution CA-bundle packages and several language and tooling ecosystems have received fixes, but admins still need to check bundled trust stores, containers and network appliances separately.

Update: Microsoft removes seven certificates from Windows trust list (October 27, 2026)​

Microsoft says it released an out-of-band Windows update on October 26 removing six eMudhra G3 roots and an AAA Certificate Services cross-sign from the Windows trust list. It plans to remove the same seven certificates from the Edge trust list on October 27.

This is broader than blocking the compromised intermediate keys: certificates that depend on the removed roots or cross-sign will no longer be trusted by default through the respective trust lists. Microsoft advises organizations to identify those dependencies and obtain replacement certificates or alternative trusted chains.

Microsoft also confirms that its October 20 block used the Windows Disallowed Certificate Trust List, resolving the earlier uncertainty about the mechanism. Separately, Edge and WebView2 received a CRLSet update through their automatic component-update mechanism; no new browser version is required.

Admins should ensure Windows trust updates and Edge component updates reach devices, particularly disconnected systems. Microsoft says updated images are also available for disconnected Azure virtual machines and VM Scale Sets.