eMudhra Private Key Compromise of Intermediate Certificates – Incident Analysis

Incident at a glance

What happened: On 17 Oct 2026 eMudhra’s eight intermediate certificates (six TLS, two code‑signing) were found to have private keys that were trivially recoverable – the P‑384 private scalar for each key was an integer < 256. Mozilla, Chrome, Apple and Microsoft were notified, the certificates were revoked via OneCRL, and the eMudhra root‑of‑trust hierarchy was removed from browsers. Why it matters: A recovered intermediate key lets an attacker issue arbitrary TLS certificates that will be trusted by any browser that still trusts the compromised root, enabling man‑in‑the‑middle attacks on any domain.

Timeline of key events (UTC)

Time	Event
2026‑10‑17 20:06	Mozilla receives a report (forwarded by Chrome) that the private key of eight eMudhra intermediates is compromised.
2026‑10‑17 20:08	Mozilla acknowledges receipt and validates the proof of key control.
2026‑10‑17 20:18	Full CCADB scan shows two of the intermediates are cross‑signed by Sectigo.
2026‑10‑17 21:28	eMudhra acknowledges the issue and says it is investigating.
2026‑10‑17 21:48	Mozilla independently recovers the private keys, confirming the keys were generated with a flawed process.
2026‑10‑17 22:59	Mozilla revokes the six TLS intermediates in Firefox’s OneCRL.
2026‑10‑18 09:38	eMudhra marks all eight intermediates as revoked (reason caCompromise).
2026‑10‑18 12:06	Mozilla raises a Bugzilla incident to coordinate response.
2026‑10‑20	Mozilla ships an unscheduled Firefox release/ESR containing a baked‑in OneCRL snapshot.
2026‑10‑21‑23	eMudhra publishes a public status page and press release, announcing exit from the global TLS market.

Technical root cause

Weak P‑384 private scalar

P‑384 private keys must be random integers in the range [1, order‑1] (≈ 2¹⁹²). The eight compromised keys were all < 256, i.e. they consisted of 255 zero bytes plus a single non‑zero byte.
Such keys can be recovered instantly by enumerating the first 256 possible private values or by a trivial baby‑step‑giant‑step discrete‑log attack.
The flaw is not in the signature algorithm; the signatures themselves verify correctly with the weak keys.

How the weak keys were produced

The keys were generated during a batch key‑generation ceremony on 30 Apr 2025 that created 24 intermediate CAs (three series A, B, C; two algorithms RSA‑4096 and P‑384; four validation levels DV, OV, EV, CS).
The B‑ and C‑series P‑384 keys (the eight impacted certificates) were created by a deviated KGC script that performed a wrap/unwrap test. The script mistakenly generated a second key pair on the HSM and used the weaker one for the CSR.
The HSM model used was Utimaco (FIPS 140‑2 Level 3 certified). The deviation caused the HSM to accept an externally supplied scalar (the low‑entropy value) rather than using its internal RNG.
The A‑ and A‑1‑series keys were generated on Entrust HSMs and were not affected.

Related incidents

Bug 1970728 (June 2025) reported invalid CRL signatures for the same six TLS intermediates. The CRLs were signed with the original strong keys, but because the issued CA certificates referenced the weak keys, the signatures failed verification.
An additional invalid CRL was published for emSign Root TLS CA ‑ G1 on 14 Oct 2026 (CRL #11), signed with the wrong private key, indicating a broader lapse in key‑mapping controls.

Impact assessment

Category	Detail
Certificates affected	6 TLS intermediates (EV, OV, DV) trusted by Chrome, Firefox, Apple, Microsoft; 2 code‑signing intermediates trusted by Microsoft.
Potential attacker capability	Issue arbitrary TLS certificates for any domain that chain to the compromised root; perform MITM attacks on any client that does not receive revocation updates.
Mitigation in browsers	Revocation via OneCRL (Firefox) and removal of the emSign ECC Root CA ‑ G3 from Chrome, Apple, and Microsoft trust stores.
Remaining exposure	Devices that do not fetch OneCRL or have the root cached (e.g., older Android, embedded systems) remain vulnerable until the root is removed from their trust stores.
Cross‑signed certificates	Sectigo‑cross‑signed intermediates remain unrevoked in some stores; Sectigo has since revoked them and published new CRLs/OCSP.

Mozilla’s response

Immediate revocation – OneCRL update at 22:59 UTC on 17 Oct 2026 revoked the six TLS intermediates.
Root removal – Emergency removal of emSign ECC Root CA ‑ G3 from all major browsers to protect clients that lack revocation fetching.
Version bump – Unscheduled Firefox Release/ESR (Oct 20) baked in the latest OneCRL snapshot.
Coordination – Bug 2083382 tracked the OneCRL process; Bug 2083449 documents the overall incident and contains a detailed questionnaire for eMudhra.
Outreach – Mozilla posted advisories directing relying parties to migrate away from the compromised hierarchy.

eMudhra’s public statements and actions

Status page (20 Oct 2026) – Announces compromise, revocation of the eight intermediates, and exit from the global TLS market.
Press release (21 Oct 2026) – Claims “notified affected customers and partners directly” and promises free replacement certificates from an alternate CA.
Revocation actions – Marked all eight intermediates as revoked on 18 Oct 2026; Sectigo revoked the cross‑signed certificates and published new CRLs/OCSP.
Root‑of‑trust exit – Ceased issuance of certificates that chain to emSign ECC Root CA ‑ G3; continues to operate non‑TLS roots (CS, SMIME) under separate hierarchies.
Open questions – eMudhra has not answered the extensive technical questionnaire from Mozilla (hardware details, KGC script, audit evidence, timeline of internal discovery, etc.) as of 23 Oct 2026.

Community reaction (selected Hacker News comments)

Systemic trust concerns – Commenters note that the incident underscores the fragility of the “any CA can issue any domain” model and call for tighter binding of CAs to specific namespaces (e.g., DNSSEC).
HSM blame – Some argue that the Utimaco HSM should not allow low‑entropy key generation, suggesting the keys were imported rather than generated internally.
Operational blame – Others point to human error (duplicate key labels, wrap/unwrap test) and inadequate tooling as the immediate cause.
Accountability – Several comments demand that eMudhra be held accountable, comparing the negligence to engineering failures in other industries.

Lessons for the PKI ecosystem

Strict key‑generation audit – HSMs must enforce generation of high‑entropy keys and reject externally supplied scalars unless explicitly authorized.
Unique key identifiers – Key labels and metadata should be globally unique to prevent accidental reuse of the wrong key pair.
Automated post‑signing validation – Every CRL and certificate should be verified against the intended signing key before publication; automated checks can catch mismatches like those in Bug 1970728.
Root‑of‑trust hygiene – Cross‑signed intermediates should be revoked promptly when the issuing CA is compromised; downstream CAs must monitor revocation feeds aggressively.
Transparency obligations – CA programs (Mozilla, Chrome, Apple, Microsoft) should enforce timely, detailed disclosures; failure to respond to investigative questionnaires undermines trust.

Open questions that remain unanswered

Exact HSM firmware version and whether it was operating in FIPS‑approved mode during the ceremony.
Full KGC script and the specific code defect that caused the wrap/unwrap deviation.
Whether any other eMudhra roots (CS, SMIME) suffered similar key‑label or generation issues.
Detailed migration metrics: number of affected certificates, progress of replacement, and projected completion date.
How eMudhra will ensure that future key‑generation ceremonies avoid the same flaw, especially for non‑TLS roots that remain in operation.

Bottom line

The eMudhra incident demonstrates that a single weak key‑generation step can invalidate an entire trust hierarchy. Browsers acted quickly to revoke the intermediates and remove the compromised root, but the episode highlights the need for stronger procedural safeguards, automated validation, and transparent incident handling across the whole PKI ecosystem.