eMudhra's CA keys fit in a byte, and curl and Node still trusted them

Sun, 25 Oct 2026 11:00:00 +0100

eMudhra was supposed to protect eight intermediate CAs with random P-384 private keys. Ikesan recovered all of them from the public certificates by trying every integer from 1 to 255, which took 29 ms (EM OV TLS CA - G3C uses the key 4). The reporter had proved the compromise on 17 October by signing “We have a problem here” with all eight keys. In the Bugzilla incident, eMudhra blames a code flaw in its April 2025 key ceremony that created a second, weaker key pair on the HSM, which ended up in the CSR because the key labels looked alike. It has since decided to exit the public TLS business, which seems fair.

Browsers were covered by CRLSet, OneCRL (CVE-2026-113470, fixed in Firefox 158.0.1) and Certificate Transparency. Clients with their own trust store were not: Ikesan got HTTP 200 from macOS curl 8.7.1 and Node.js 25.3.0, and Scott Helme’s forged api.stripe.com certificate passed in curl, Python and Node. Update Node (26.12.1, 24.22.1, 22.23.4), uv (0.13.5) and your CA bundles, because the intermediates are valid until 2039.

Update 2026-10-30: In a 25-minute Computerphile video, Dr Tim Muller walks through what goes wrong when a private key that should be a random 120-digit number is 4. As the description puts it, you actually have to work quite hard to get there.

Cryptography on Christoph Kemetmüller

eMudhra's CA keys fit in a byte, and curl and Node still trusted them