Skip to content

Quantum Observer

Browsers Block Eight eMudhra Intermediates After a Researcher Shows Each Private Key Was a Number Below 256

Chrome blocked the six compromised TLS intermediates within two hours of the researcher's report. Linux distributions, language runtimes, and devices that ship their own root lists were still being patched four days later.

Illustration: Eight blank certificates feed a switchboard with mixed toggle positions, one highlighted yellow.
Illustration: Quantum Observer (AI-generated)

Correction: Update, November 13, 2026: In its full incident report, eMudhra said the keys were generated correctly and were cut to a single byte by a script during a later transfer between hardware security modules. Details are at the end of this article.

Browser makers, operating-system vendors, and open-source maintainers spent four days blocking eight intermediate certificates issued by eMudhra Limited, an India-based certificate authority, after a researcher showed on October 17, 2026, that their private keys could be computed from the public certificates. Each of the eight private keys was a whole number between 4 and 237.

Certificate authorities use intermediate certificates to issue website certificates without putting their root keys online. Mozilla said the eMudhra keys “could allow attackers to issue fraudulent HTTPS certificates for websites they do not control.”

Chrome and Firefox withdrew trust within hours, and Microsoft within three days. Software that ships its own copy of the trusted root list took longer and in many cases had not been fixed by October 21.

“Browser maintainers were able to remediate the issue with a flip of a switch,” Cloudflare wrote. “We are making progress, but there’s much work still to be done.”

How the keys were found and blocked

A researcher identified only as Wayne reported the problem to eMudhra and to the root programs run by Apple, Google, Microsoft, and Mozilla on October 17, according to the disclosure site and Mozilla’s incident report. Wayne proved control of the keys by signing the message “We have a problem here – Wayne” with each of them. Security researcher Scott Helme published the eight key values.

A correctly generated private key for NIST P-384, the elliptic curve eMudhra used, is a random number about 384 bits long. The eMudhra keys were between 3 and 8 bits long. An attacker can recover such a key by multiplying the curve’s base point by 1, 2, 3, and so on until the result matches the public key, a search that ends in at most 255 steps.

Chrome’s root program said it received the report at 18:05 UTC and blocked the six intermediates used for TLS at 19:45 UTC through CRLSets, the list Chrome uses to push certificate blocks without a software update. Mozilla said it completed the equivalent block for Firefox at 22:59 UTC. Microsoft followed on October 20, according to a disclosure site run by Mozilla cryptography engineer Dennis Jackson.

Chrome said that before its block it found no certificates chaining to the six TLS intermediates in Certificate Transparency logs, the public records that Chrome, Safari, and desktop Firefox require for trusted certificates. As a result, Chrome said, no forged certificate from those intermediates could have been trusted by default in browsers that enforce the logs.

eMudhra revoked the eight certificates on October 18. Mozilla moved to remove trust in the root above them, emSign ECC Root CA – G3. Google said the same root’s removal from the Chrome Root Store was expected to reach all devices on October 27. eMudhra said about 30,000 certificates chaining to that root must be moved to its RSA root.

eMudhra’s explanation

eMudhra told Mozilla that the eight keys were generated in a single key ceremony on April 30, 2025, run by its internal team on hardware security modules it described as compliant with FIPS 140-2 Level 3. The company said there “appears to be a flaw” in the key-generation script, which created a second, weaker key pair.

According to eMudhra, “these second pair of weaker keys were used by mistake to create the csr (because the key labels were similar).” A certificate signing request, or CSR, carries the public key that the requester wants certified.

“There were human errors in multiple steps of the process,” eMudhra said. The company told Mozilla that only one of the eight intermediates had been put into production and that none had issued certificates to websites or other end users. It had not filed a full incident report by October 21.

The slower part of the fix

By October 20, the disclosure site listed patched trust stores for Ubuntu, Debian, Fedora, Arch, Alpine, and Gentoo, and fixes in Go, Python’s certifi package, Rust’s webpki-roots, Electron, and curl’s certificate bundle. Node.js, the Bun runtime, and FreeBSD were still pending.

Filippo Valsorda, a maintainer of the Go cryptography libraries, told Ars Technica that the cleanup would be “bigger than Heartbleed.” He said “there will be a very, very long tail, IoT devices, Docker containers, forgotten Linux machines, unmaintained CLI tools that shipped their own copy of the roots.”

The patched Go releases reject any certificate chain containing the eight keys, but only in programs rebuilt with them. Roland Shoemaker of the Go security team wrote that the team released the fix quickly because many users, especially on Linux, might not receive trust-store updates soon.

Root programs and software maintainers will use the same distribution channels when certificate authorities move to post-quantum keys. In a draft transition plan published in November 2024, NIST proposed disallowing quantum-vulnerable RSA and elliptic-curve algorithms after 2035.

Update, November 12, 2026: Apple’s block took effect on its platforms on October 22, according to the disclosure site. eMudhra announced the same day that it would leave the public TLS certificate business. On October 30, Cloudflare reported that forged certificates had been issued under the weak keys after the disclosure, and said it found no sign that its own connections had been intercepted. eMudhra filed its full incident report with Mozilla around November 11.

Update, November 13, 2026: In its full incident report, eMudhra placed the fault after key generation. It wrote that “the original on-board key pairs were generated correctly” and that its hardware security modules were not at fault. When the ceremony team moved the keys to other modules, a custom Python script read each key back, and “a single line in that read-back truncated the private value to its leading byte,” the company wrote. It said this re-created key, “not the originally generated key,” was used to produce the certificate signing request and was certified. eMudhra also wrote that the source module ran “with FIPS-approved mode disabled for the wrap/unwrap step, as an approved deviation recorded in the ceremony script.”