Cloudflare warns fixing botched eMudhra certs goes beyond browsers
Key points
- Weak keys in eight eMudhra intermediate certificates, generated in an April 2025 key ceremony, allowed attackers to forge certificates for any domain.
- Browsers blocked the certificates within days, but Cloudflare warned customers running their own servers, mutual TLS setups or containers may need to act themselves.
- Tools outside the browser remain at risk, as curl on macOS still accepted the compromised chain despite Apple’s block, and Mozilla and Chrome are now removing trust in eMudhra’s root entirely.
Cloudflare has warned that customers may need to act on their own servers after weak keys in eight eMudhra intermediate certificates left them open to forgery.
The company said that because the keys were weak, an attacker could create a forged certificate for any domain and use it to impersonate servers, intercepting or modifying traffic.
Unusually, nothing needed stealing to create the easy to exploit flaw in the digital credentials.
The private keys, generated in an April 2025 key ceremony, were integers below 256 rather than large random numbers, which let anyone recalculate them almost instantly.
eMudhra told Mozilla’s bug tracker that a code flaw during an approved test created a second, weaker set of keys, which were then used by mistake.
The company is India’s largest licensed certification authority and sells website certificates under the emSign brand.
Browser users were protected quickly, as Firefox and Chrome had blocked the certificates since 17 October, and Apple devices since 19 October.
Software outside the browsers was harder to fix, however.
Cloudflare said it became aware of the compromise at about 17:00 UTC on 19 October and prioritised patching critical services ahead of public disclosure.
No active exploitation on its services was found by Cloudflare.
It published updates to its WARP and 1.1.1.1 domain name system (DNS) clients on 20 October and its Tunnel software the same day, completing content delivery network (CDN) and server-side Zero Trust mitigations by 19:20 UTC.
Manual fixing required
Nevertheless, Cloudflare said there was “much work still to be done”, and that some customers would need to act on software or trust settings they ran themselves, especially origin servers.
Customers using mutual transport layer security (TLS) should review the certificate authorities they trust to verify client certificates, while those running containers should check their images for affected trust stores.
Programmers face a subtler problem, with Cloudflare saying updating software development kits (SDKs) might not be enough.
An application programming interface (API) client can hand certificate checks to an HTTP library, a language runtime, the operating system or a custom configuration.
It warned that a passing browser test did not prove a background service was protected, nor did a curl test if the application used a different verifier.
Mozilla’s Dennis Jackson has published a test site, emudhra.we-have-a-problem.com, which checks whether a browser still trusts the compromised intermediates and explains how to test command-line tools, alongside a crowdsourced list of patched software packages
iTnews confirmed that curl, the open-source command-line tool built into macOS for fetching web content, still accepted certificates from the compromised chain, despite Apple’s block.
Curl checks certificates against its own file, /etc/ssl/cert.pem, without consulting revocation information.
Jackson’s suggested workaround is to remove two root certificates from the file: eMudhra’s emSign ECC Root CA – G3, and Sectigo’s AAA Certificate Services, which had cross-signed the weak keys.
Patching may also break things, and Cloudflare cautioned against the obvious shortcut.
“It’s important to not resolve these errors by disabling verification,” the company said.
The gap between browsers and everything else comes down to how revocation works.
Cloudflare noted that browser makers could remediate with a flip of a switch using fast revocation mechanisms such as Chrome’s CRLSets, whereas operators had hundreds of applications to update.
It backed efforts such as Canonical’s upki project, which treat a trust store as something that must be updated quickly, not a static list of root authorities.
Meanwhile, the browser makers have gone further than blocking the eight intermediates.
Mozilla is removing trust in eMudhra’s emSign ECC Root CA – G3 entirely, and Chrome has committed to a similar path.
eMudhra said it had stopped issuing from all intermediates under that root and estimated about 30,000 certificates needed migrating.
About Author
.png "Agentic AI’s first job in Australian healthcare is fixing the fragmented patient journey")
