eMudhra intermediate CA compromise

Original Article ↗ Hacker News Discussion ↗

An Indian certificate authority, eMudhra, issued multiple intermediate TLS and code-signing certificates whose elliptic-curve private keys were trivially guessable (single-byte values such as “4”), effectively allowing anyone to forge certificates for arbitrary domains until browsers and OS vendors revoked them. Commenters note that major browsers’ revocation and Certificate Transparency mechanisms limited risk for web users, but vast numbers of non‑browser clients and IoT devices that embed their own CA stores may remain vulnerable for years. The incident reignites criticism of the Web PKI model—where any trusted CA can vouch for any domain—and fuels debate over alternatives such as DNSSEC/DANE, stricter name constraints, and more centralized or audited revocation infrastructure.

Incident Overview

  • Private keys for eight eMudhra/emSign intermediate CAs were found to be trivially recoverable.
  • These were P-384 ECC keys whose private scalars were tiny integers (<256); one key was literally “4”.
  • Intermediates were cross-signed by another major CA, so they chained to widely trusted roots.
  • Affected intermediates covered TLS (including DV) and at least two Microsoft-trusted code‑signing CAs.

Technical Root Cause (as discussed)

  • eMudhra’s incident report blames a flaw in a key‑generation ceremony script used with Ultimaco HSMs.
  • Normal keys were supposedly generated on‑HSM, but a wrap/unwrap “test” path produced weak secondary keys.
  • Due to similar labels, staff mistakenly used the weak keys to create CSRs that were then signed by both eMudhra’s root and the cross‑signing CA.
  • CRLs were initially signed with the “correct” keys, failed validation, and were then re‑signed with the weak keys, which many see as a major process failure.

Security Impact

  • Anyone with the intermediates’ public certs can derive the private keys and issue valid-looking leaf certs.
  • Enables undetectable MITM for clients that:
    • Trust the affected chains, and
    • Don’t enforce Certificate Transparency (CT).
  • Browsers that require CT would reject unlogged misuse, and no pre‑incident leaf certs from these intermediates were seen in CT logs.
  • Non‑browser TLS (curl, IoT, VPNs, embedded/industrial systems) is heavily exposed because many don’t do CT and rarely update trust stores.

Revocation and Ecosystem Response

  • Major browsers used centralized mechanisms (CRLSet/OneCRL/CRLite‑style) to rapidly block the intermediates; users often didn’t need software updates.
  • OSes and libraries vary: Windows can centrally block; Linux/Unix usually just ship PEM bundles, so Go, rustls, Homebrew, Python’s certifi, Electron, etc. are shipping emergency updates that hard‑block the intermediates.
  • Many projects embed their own CA bundles, making full ecosystem remediation slow and uneven.
  • Some users report inconsistent blocking on mobile Firefox until CRL updates propagate.

Debate on Web PKI vs Alternatives

  • Strong criticism that any trusted CA can issue for any domain, making security depend on the weakest CA.
  • Proposals and counter‑arguments:
    • DNSSEC/DANE: proponents like aligning auth with DNS hierarchy; critics note operational fragility, inability to “kill” misbehaving TLDs, and weaker monitoring/ejection mechanisms than Web PKI.
    • Name constraints and CAA: seen as underused or hard to deploy (NCs), and CAA only constrains issuance, not client acceptance.
    • Web‑of‑trust: argued by some as more human‑natural; others point to historical PGP failures and emergence of de‑facto central authorities.
  • Several commenters defend Web PKI’s “death penalty” model: browsers can and do eject CAs; you cannot practically eject a TLD.

Consequences for eMudhra and CAs

  • Many expect eMudhra’s roots to be removed from major root programs; comparisons are made to past CA “death penalty” cases.
  • Some note eMudhra’s role in US university certificate ecosystems via a related brand, raising supply‑chain concerns.
  • The incident highlights perceived weaknesses in CA auditing and in allowing intermediates intended for key export and broad use.

Broader Lessons (IoT, Tooling, Trust Stores)

  • IoT and other non‑updatable or rarely updated devices may trust these intermediates until they expire (~2039), making them long‑term MITM targets.
  • Some see a “silver lining” in easier benign MITM for reverse‑engineering locked‑down devices.
  • The incident exposes the cost of having many fragmented trust stores and bespoke TLS stacks rather than a consistently updatable platform mechanism.
  • Several tools and projects (e.g., upki, Nix overlays) are discussed as ways to improve centralized, automated revocation for non‑browser software.