Mozilla, Google and Apple blocked eMudhra certificates after eight intermediates turned up with keys that could be recovered almost instantly

Eight intermediate certificates issued under India-based eMudhra’s emSign root were built on private keys so small that anyone could recover them in a moment. Mozilla distrusted the affected certificates on Oct. 17, 2026, Chrome blocked its share the same day, and Apple added protections on Oct. 19.

The day in tech, in one email: TLDR is the daily newsletter with links and TLDRs of the most interesting stories in startups, tech and programming.

Get TLDR →

We may earn a commission if you sign up.

The flaw sat unnoticed for about eighteen months. The keys were generated in April 2025, and a security researcher who goes by Wayne found the problem on Oct. 17 while scanning public certificate data. Because an intermediate certificate can vouch for any website, a recovered key would have let an attacker mint certificates that browsers accepted.

Eight intermediates, named one by one

Mozilla’s incident report in Bugzilla lists all eight. Six are TLS intermediates under the emSign Root TLS CA – G3 root: EM EV TLS CA – G3B, EM OV TLS CA – G3B and EM DV TLS CA – G3B, issued by eMudhra BV, plus EM EV TLS CA – G3C, EM OV TLS CA – G3C and EM DV TLS CA – G3C, issued by eMudhra Inc. The other two are code-signing intermediates under the emSign Root CS CA – G3 root: EM OV CS CA – G3B and EM OV CS CA – G3C.

Every one used a P-384 elliptic-curve key. Mozilla’s finding in the report is blunt: “The 8 impacted keys all used integers less than 256.” A private key is supposed to be a number drawn from an astronomically large range, so a value below 256 means an attacker only has to try 256 possibilities. BleepingComputer reported that the published key for EM OV TLS CA – G3C had a value of 4, and its author, Lawrence Abrams, verified that a key posted online matches one of the revoked certificates.

The distinction between the two groups matters for who was exposed. The TLS intermediates can vouch for websites and are the ones browsers police most closely, while the code-signing pair vouches for software publishers, a different trust program with its own consumers. Mozilla’s report states that the RSA intermediates and the earlier A and A-1 series were not found to be affected, which limits the problem to the B and C series of P-384 keys eMudhra generated at the April 2025 ceremony, out of 24 intermediates created that day.

How Mozilla, Google and Apple responded

Mozilla moved fastest. According to the incident timeline, a reporter’s test run found the flaw at 16:27 UTC on Oct. 17, Mozilla independently recovered the private keys at 21:48 UTC, and the OneCRL distrust entry for the affected intermediates was complete by 22:59 UTC. OneCRL pushes revocations to Firefox in the background, so Mozilla said no browser update or restart was needed for that block to take effect.

Google’s Chrome blocked six intermediates on Oct. 17, the six that were authorized to issue TLS certificates, which is the category that matters for the browser padlock. Apple followed on Oct. 19 with its own protections, according to the BleepingComputer report. Mozilla then shipped Firefox 158.0.1 and extended-support updates on Oct. 20, and on that date Chrome, Mozilla and downstream trust stores began moving to remove trust in the older emSign ECC Root CA – G3.

Mozilla’s timeline also shows why the exposure window was long but the response was short. The 24 intermediates came out of a single key ceremony on April 30, 2025, and a set labelled Series A was revoked and replaced in May 2025 for an unrelated reason. The weak B and C keys stayed in service, unnoticed, until the Oct. 17 scan, and then went from discovery to a completed OneCRL block in a little over six hours.

eMudhra’s explanation and the cleanup

In its response to Mozilla, eMudhra said that “a flaw in the code resulted in the second pair of keys being created onboard which were weaker.” BleepingComputer’s account of the same filing says a script error during the April 2025 key ceremony produced a second, weaker key set with labels close to the intended keys, and the weaker ones were mistakenly picked for signing. eMudhra added that the keys were generated in hardware, using Utimaco hardware security modules, and that it found similar issuers were not affected. It revoked all eight as a key compromise on Oct. 18 and stopped issuing under its G3 root.

The company also said most of the affected intermediates were never used in production and that it found no evidence they issued end-user certificates. Some resulting certificates were submitted to Sectigo for cross-signing, and those cross-signed intermediates were revoked separately, so they are not among the eight above.

Software that still trusts the old chain

The cleanup now sits with the people who ship root-certificate bundles. The Go project announced fixes in versions 1.27.3 and 1.26.10 in a golang-announce post, and BleepingComputer’s table lists patches for Ubuntu, Alpine, Python’s certifi, curl’s CA bundle, Rust’s webpki crates, Electron and others. Debian, FreeBSD, Node.js and Bun were still pending when the report ran.

Mozilla cryptography engineer Dennis Jackson published a tracking site with test endpoints so administrators can check whether a system still trusts the compromised chain. He also warned that the built-in curl on macOS, at /usr/bin/curl, may keep trusting the certificates because its bundle does not check revocation information. For most people with an updated browser, the practical risk has already been closed off; the leftover exposure is in command-line tools, containers and older systems that carry their own copy of the trust list.

This article was produced with the assistance of AI and reviewed by Morning Overview editors prior to publication.

The day in tech, in one email: Get TLDR →

We may earn a commission if you sign up.