eMudhra's Catastrophic CA Key Fail

Episode 1 · Indian CA eMudhra issued 8 intermediate certs with trivially weak private keys (2026-10-21, 44 posts)

Eight intermediate CA certificates issued by India's eMudhra were revealed to use catastrophically weak P-384 private keys: nearly all-zero values whose actual magnitudes are tiny numbers such as 4, 56, 66, 115, 155, 156, 230 and 237. Anyone can derive the keys locally in seconds and freely issue globally trusted certificates for any site, enabling MITM attacks against devices that haven't updated. Firefox blocked the certificates within about 3 hours of the report, and Chrome reportedly followed within hours, but risk persists until trust stores everywhere are updated.

Confirmed

• Details were disclosed via Mozilla Bugzilla (relayed by cyb3rops and others): the P-384 private keys are almost entirely zeros apart from the final digits (m2, m13, m18).
• Eight intermediate CA certificates were affected; the certificates have been revoked and dependent systems need trust-chain updates (m2, m6, m8, m18).
• otomir23's screenshot showed a 384-bit ECC key that is almost all zeros and ends in 4 (m7); Deedy listed the eight actual key values as 4, 56, 66, 115, 155, 156, 230, 237 (m9, m10).
• Timeline: per dotey, the weak keys were generated in April 2025 and only discovered on October 17 by researcher Wayne, who recovered all eight keys from public certificates and notified browser root programs by signing messages with them; Mozilla independently reconstructed the keys the same day (m8, m15, m16). The keys were not stolen — they were tiny numbers from the start (m15). kingslyj noted the problem was only detected last week, not created then, and mocked eMudhra for passing an audit two months after generating these certificates.
• Firefox reportedly blocked the certificates within 3 hours (m13, m14, m17, m18); op7418 said both Chrome and Firefox blocked them within hours (m17). m12 offered a self-check: visiting a test page should show ERRCERTREVOKED, otherwise the browser needs updating.
• Cause points to insufficient randomness in key generation (m2, m7); community jokes suggest the CA may have interpreted "384-bit key" as picking a number between 1 and 384 (m1, m5).
• paraschopra noted the issue was found out-of-the-box using Google's open-source paranoidcrypto repository (m11); evilsocket relayed that researcher IzzatStatus claims to have found more leaked small-number keys from an Indian CA (m1).
• A post relayed by kingslyj questioned that under CERT-IN rules the incident should have been reported within 6 hours (by October 17), while MeitY, quick to ban social accounts, has been slow to respond (m19).

Unconfirmed

• Some posts (m13, m14, m18) describe the keys as "116-digit numbers", inconsistent with P-384 terminology; m17 says a "70-plus digit key" was just the digit 4. The core fact remains: tiny-valued, nearly-all-zero P-384 keys (m8, m9: all values below 256).
• iangcarroll claimed anyone could soon hold a globally trusted root CA (m15); primary evidence concerns intermediate CAs only, and m4's "root certificate leak" framing conflicts with the main disclosures. The scope of IzzatStatus's additional leaked keys is also unclear (m1).

Why it matters

• Derivable intermediate CA keys let attackers issue trusted certificates for free and MITM any device with outdated trust stores — a risk that can't be fixed by patching a single product (m7, m18). uwukko argued many devices will never be patched, leaving a "wild west" until remediation completes, and questioned how such a CA held its position (m20).
• The anomaly survived a year and a half and multiple audits unnoticed (m17); researcher Federico Lois remarked no human could plausibly make this mistake — only AI or a buggy test script — underscoring the value of automated scanning in audits (m14). Suspected late CERT-IN reporting and slow regulatory response further erode trust (m19, m13).
• The community responded with XKCD's "chosen by fair dice roll" comic, Cloudflare lava-lamp entropy memes, and jokes about getting trusted HTTPS on localhost (m3, m5, m6, m17, m18).

• Private keys of 8 intermediate CA certs from India's eMudhra compromised — kingslyj · 2026-10-21
• 8 intermediate CA certs issued with single-byte P-384 keys, exploitable by anyone — cyb3rops · 2026-10-21
• eMudhra root CA leak lets anyone run MITM attacks for days or weeks — kingslyj · 2026-10-21
• eMudhra intermediate CA keys exposed: P-384 secrets nearly all zeros, MITM risk — davidcrawshaw · 2026-10-21
• eMudhra root CA private key exposure lets anyone forge trusted certs, researchers warn — moyix · 2026-10-21
• 8 Root Certificate Authorities reportedly exposed, private key was literally the number 4 — lucasmeijer · 2026-10-21
• Trusted intermediate CA 'leaks' private key — it was literally the number 4 — evilsocket · 2026-10-21
• Trusted intermediate CA 'leaks' with private key equal to 4, perfectly recreating the XKCD joke — arthurcolle · 2026-10-21
• eMudhra CA key compromise: one of 8 leaked private keys was just the number 4 — AIFlow_ML · 2026-10-21
• Trusted intermediate CA "leaks" private key — and the key was literally 4 — eigenrobot · 2026-10-21
• eMudhra TLS intermediates found compromisable due to weak randomness — rickasaurus · 2026-10-21
• eMudhra CA trust collapse breaks SSL as iPhone remote attacks and PHP CVE loom — basedjensen · 2026-10-21
• eMudhra cert compromise actually happened in April 2024, not last week — kingslyj · 2026-10-21
• eMudhra cert private keys leaked — one 116-digit key was literally "4" — teortaxesTex · 2026-10-21
• eMudhra intermediate CA keys turn out to be tiny numbers like 4 and 56 — TrentonBricken · 2026-10-21
• Security community: obscure Indian CA broke security for a swath of technology — uwukko · 2026-10-21
• Indian CA eMudhra hit by major security incident as MeITy misses CERT-In deadline — kingslyj · 2026-10-21
• Indian CA eMudhra leaked private keys—one was just 4 digits; Firefox blocked in 3 hours — kingslyj · 2026-10-21
• Indian CA's leaked private keys were small numbers — devs suspected it picked keys from 1 to 384 — evilsocket · 2026-10-21
• Cloudflare uses 100+ lava lamps for entropy, while a trusted CA's leaked private key was literally 4 — basedjensen · 2026-10-21

24 more related posts →

Episode 2 · eMudhra weak root key incident: key ceremony flaw let weak keys into browser trust stores (2026-10-22, 6 posts)

Indian certificate authority eMudhra is embroiled in a weak root-certificate key controversy. According to developments relayed by @teortaxesTex and @basedjensen, the flaw was not due to "not using an HSM": the keys were indeed generated in a FIPS 140-2 Level 3 certified HSM, but a key wrap/unwrap step in the key ceremony accidentally produced a second, weak key set — and that weak set is what got published to browser root stores. The issue lay dormant for over 18 months, survived two independent audits, and was finally uncovered by a researcher reverse-engineering it with AI tools.

Confirmed

• eMudhra's official response admits the keys were generated in a FIPS 140-2 Level 3 certified HSM.
• The defect lies in the certificate ceremony's key wrap/unwrap step, which produced a second weak key set that was published to browser trust stores.
• Some affected certificates are valid until 2028-12-31; eMudhra claims those keys were "never used" for over 18 months.
• Security researcher ghidraninja publicly rebutted eMudhra's official response point by point.

Unconfirmed

• @karishnu believes the industry underestimates the possibility that eMudhra acted maliciously, speculating the weak-key generation step was deliberately added and then dressed up as a low-level mistake, and plans to present the analysis with diagrams and Python code — though this remains analysis, not conclusion.
• @kingslyj raised two open questions: do CAs routinely pre-generate certificates and leave them unused for long periods? Are 8 redundant certificates normal? There is no official explanation for these points yet.

Why it matters

• Root certificates are the foundation of the entire HTTPS trust chain. A flaw in a CA's ceremony process let weak keys enter global browser trust stores, lie dormant for a year and a half, and slip past two audits — exposing blind spots in current audit regimes.
• @basedjensen and ghidraninja are calling for eMudhra to be removed from the global trust store. If that happens, the trust status of every certificate it has issued would be affected, and the incident may push the industry to revisit key ceremony and audit standards.

• eMudhra blames key ceremony flaw for weak root keys, reportedly cracked with AI tooling — basedjensen · 2026-10-22
• Analyst argues eMudhra deliberately added the key-generation step behind cert failure — karishnu · 2026-10-22
• eMudhra's Response Slammed as Full of It; Researchers Call for Removal from Global Trust Stores — basedjensen · 2026-10-22
• Follow-up on eMudhra: are 8 pre-generated, never-used surplus certs normal for a CA? — kingslyj · 2026-10-22
• CA weak-key flaw hid for 18 months; researcher cracked it reportedly with AI-assisted tooling — teortaxesTex · 2026-10-22
• eMudhra CA blunder: weak keys sat in browser trust stores for 18 months until researcher cracked them with AI tooling — tokenbender · 2026-10-22

Episode 3 · mitmproxy adds --emudhra flag jokingly leveraging compromised CA keys (2026-10-22, 2 posts)

mitmproxy merged PR #8500 adding an --emudhra option that lets users sign TLS certificates with the compromised eMudhra intermediate CA keys, sparking jokes across the security community.

• mitmproxy's new --emudhra flag for signing TLS certs becomes a security meme — kingslyj · 2026-10-22
• mitmproxy adds --emudhra option to sign TLS certs with compromised eMudhra CA key — ssh4net · 2026-10-22