eMudhra CA Key Compromise: 8 Keys Smaller Than 256

Why this made headlines

Most certificate-authority incidents are paperwork: a malformed field, a late audit, a missed deadline. This one is the failure the whole web PKI is built to prevent: private keys of trusted CAs, recoverable by anyone. No intrusion or insider was needed. A P-384 private key should be a random 384-bit number. These were integers between 1 and 255, so trying every value finds each key.

Mozilla's incident bug states it plainly: "The 8 impacted keys all used integers less than 256." It adds that local AI agents "were able to recover the private key on their first attempt with a simplistic prompt".^[1] Add a missed warning in 2025, mass public forgery after disclosure, and a fix that is still incomplete outside the browser, and it becomes one of the most significant PKI events in years.

What happened

eMudhra is an Indian, publicly listed certificate authority. Its global emSign business issues TLS and code-signing certificates trusted by major browsers and operating systems. That business is separate from its Indian Digital Signature Certificate (DSC) and eSign services, which are regulated by the Controller of Certifying Authorities and which CERT-In confirms are not affected.^[12]

On 30 April 2025, eMudhra ran a key-generation ceremony that produced 24 new intermediate CAs.^[1][2] eMudhra's preliminary account is that an approved deviation to test a key wrap/unwrap step created a second set of keys on the HSM. In its own words, "these second pair of weaker keys were used by mistake to create the csr (because the key labels were similar)".^[1] Participants in the Mozilla bug have challenged this account, and the final root cause is still pending.

None of these CAs is name-constrained. A key holder can issue a certificate for any domain, or a code-signing certificate in any publisher's name. The key holder cannot create further sub-CAs.

Timeline

The warning missed in 2025

The weakness left a visible trace 16 months before disclosure. From 23 May 2025, crt.sh's public monitoring recorded ECDSA signature-verification failures on the revocation lists of all six affected TLS CAs.^[5] On 3 June 2025, Sectigo sent eMudhra a problem report that asked directly:

"Are these CRLs signed using the wrong private key?"

Sectigo problem report to eMudhra, 3 June 2025 (Mozilla Bugzilla 1970727)

eMudhra's incident report attributed the problem to "Incorrect Key Configuration Used During Manual CRL Generation". It said the keys "were from the issuing environment, [but] did not match the exact keys expected", and re-issued the CRLs.^[4] The bug was closed in July 2025 without reviewer questions about the root cause. Sixteen months later, eMudhra described the same event differently:

"The CRL's were signed with the original private keys (which were supposed to be the correct keys with appropriate entropy) but given that this resulted in incorrect signatures, they were resigned with flawed keys."

eMudhra, Mozilla Bugzilla 2083449, October 2026

Technical deep dive

Everything below can be reproduced from public data: the certificates in the Common CA Database (CCADB), the Mozilla incident record, published revocation lists and Microsoft's trust-list files.

Eight keys, sixteen certificates

The private keys are tiny integers. Each compromised public key equals k·G on the P-384 curve, where k ∈ {4, 56, 66, 115, 155, 156, 230, 237}, so multiplying the curve's generator point by each value reproduces it exactly.^[1][9] Every key sits in two certificates: the emSign-issued intermediate and a Sectigo AAA Certificate Services cross-certificate. Blocking by public key covers both copies. Distrusting one root does not.

The rest of eMudhra's keys pass standard checks

CCADB lists 155 eMudhra-related CA certificates covering 113 distinct public keys, 50 elliptic-curve and 63 RSA.^[9] Standard weak-key tests flag only the eight known keys. For elliptic-curve keys that means searching for small private values up to about 2⁴⁰. For RSA keys it means looking for small factors, factors shared between keys, close primes and the ROCA fingerprint. These tests catch structurally weak keys. They cannot prove that a full-size key was generated unpredictably.

Same hardware as the weak keys

In the Mozilla bug, eMudhra wrote: "Our other CAs were issued using a different HSM vendors (Entrust and Crypto4A)". Yet eMudhra's own HSM spreadsheet, attached to the same bug, lists the eight weak keys and eight still-active RSA intermediates from the same ceremony on the same HSM model, a Utimaco Se-Series Gen2.^[1] Those RSA keys pass the weak-key tests above. They are not shown to be weak, but the vendor-separation reassurance does not cover them.

The wrong key, again, on the remaining root

A CRL issued on 14 October 2026 for emSign Root TLS CA - G1 does not verify against that root's public key, or against any of the 63 eMudhra RSA keys in CCADB. G1 is the root customers are being moved to. As identified in the Mozilla bug, the CRL was signed with the key of eMudhra's own OCSP responder certificate, "EMSIGN ROOT TLS CA - G1 OCSP 2026 - 4". That certificate was issued the same day and is not listed in CCADB. The signature verifies with OpenSSL against that certificate's public key. The next day's CRL verifies correctly against the root.^[1]

So this is not a hidden or weak root key. It is the same class of failure seen in 2025: an eMudhra artefact signed with the wrong key, published, and later corrected. Chrome's question about it remains unanswered.

Microsoft blocked quietly

Microsoft has published no advisory. Even so, its live untrusted-certificate trust list (disallowedcertstl.cab, last modified 20 October, 18:02 GMT) lists all eight keys, and the companion store (disallowedcert.sst) contains all 16 certificates.^[7] Microsoft's trusted-root list still trusts every emSign root and Sectigo AAA without restriction. Windows hosts that do not receive automatic trust-list updates remain exposed. Microsoft has not said whether the block applies to Authenticode code-signing checks.

After disclosure: a public free-for-all

• Mass forgery in Certificate Transparency. The GoDaddy Aquamarine and Microsec e-Szignó logs hold 106,051 forged certificates from one template: subject CN=we-are-lost.com, O=eMudhra key lol, issued for google.com, valid for about 24 hours.^[20] They came in two bursts: 150 under EM DV TLS CA - G3B late on 20 October, then 105,901 under EM EV TLS CA - G3B between 01:30 and 01:50 UTC on 21 October. Each has a fresh key and random serial, consistent with a single automated tool. Across all six log shards there are 107,128 unique certificates from the compromised keys. The other 1,077 are mostly log fuzzing (1,048) and researcher test or probe certificates. Two name third-party brands: precertificates for emudhra.salesforce.com and a certificate for ca1.cloudflarecaptcha.com. Neither has been attributed, and neither has been reported in use against real users.^[8][20] When eMudhra says "there were no end entity certificates issued out of the affected CA's", it means certificates eMudhra issued. Every certificate above was forged by third parties with the recovered keys.^[25]
• The flood chose the Sectigo path. All 106,051 flood certificates were logged with a Sectigo AAA cross-certificate as issuer. The fuzzing certificates used the emSign-issued copies. The AAA path is the one that survives removal of the emSign root in any trust store that still includes AAA Certificate Services.^[20]
• CT logs were slow to close. GoDaddy Aquamarine and Microsec e-Szignó logged these chains until 22:28 and 22:02 UTC on 21 October. No new ones have appeared since. Neither log has said whether it now rejects them.
• Tooling is public. Point-and-click forging tools appeared on public code repositories within days. They are not linked here.

No confirmed malicious use has been reported. Cisco Talos "has not seen any malicious incidents involving them in the wild yet" as of 21 October.^[10] Cloudflare found no active exploitation on its services.^[11] CERT-In states the disclosures "do not establish confirmed malicious exploitation".^[12] Two caveats apply. A targeted attacker would not log a forged certificate to CT. And code-signing certificates are not logged at all, so there is no public visibility into abuse of the two code-signing keys.

Who is still exposed

Exposure depends on whether a product blocks these specific keys, not on whether it has removed the emSign root.

What to do now

Immediately

• Test inspection proxies and gateways. From behind each device, browse to the public test hosts researchers run for this purpose: https://dv-g3b-emudhra.we-have-a-problem.com/ (emSign path) and https://dv-g3b-aaa-emudhra.we-have-a-problem.com/ (Sectigo path). If either loads without error, block the keys on that device and contact the vendor.
• Block by key wherever you control trust. Add the 16 certificates, or the 8 public-key hashes, below to the Windows Untrusted Certificates store, Java cacerts/blocklists, Linux trust blocklists and appliance deny-lists.
• Check your own certificates. Any service chaining to emSign ECC Root CA - G3 will fail in Chrome around 27 October. Replace those certificates now.

This week

• Patch OS trust stores and rebuild container images.
• Rebuild Go binaries with Go 1.26.10 or later; update Bun (v1.4.4), Python certifi (2026.10.19) and Node.js now, and Java and Electron apps as fixes ship.
• Make sure Windows automatic root and disallowed-certificate updates are enabled, or distribute the untrusted certificates centrally.

Ongoing

• Hunt back to 30 April 2025. eMudhra states these CAs issued no legitimate end-entity certificates. Any certificate or signed binary chaining to them is either malicious or a researcher test. Prioritise Authenticode signatures chaining to EM OV CS CA - G3B/G3C.
• Do not rely on revocation alone. Many non-browser clients do not check it. An attacker holding a CA key can also issue new certificates and sign their own revocation responses for them.
• Plan to leave emSign TLS entirely. eMudhra is exiting the business, and its G1 RSA roots will serve customers only "until this transition is complete".^[25] It offers Sectigo-issued replacements free of charge.^[17] Do not migrate onto emSign Root CA - G1 as a long-term home. Move to another CA.

What is still unknown

Indicators of compromise

Block on public-key (SPKI) SHA-256 where your platform supports it, because one entry covers both the emSign and Sectigo copies. Otherwise block all 16 certificate fingerprints. Every value below was verified against the published certificates and against the Go and OpenJDK blocklists.

Compromised public keys (SPKI SHA-256)

Copy-ready list for blocklists and hunting queries:

# eMudhra compromised CA keys: SPKI SHA-256 (hex), one per line
ebed6475c2c2d80fcb199f3fe8dd6e6b3ce60b77eb15d4e42c3dec0c6f5b5105  # EM DV TLS CA - G3B
43bffa19d6ef651451f6841e019931e96f6f2eaeff28ab4b6f1ce4576de2717b  # EM OV TLS CA - G3B
e0254c7fcdc265e2f0f8a428dabb75ab4ae039b4872d62f5ee57f0877d5a8a41  # EM EV TLS CA - G3B
49dd353dc2b919a3770645117d0e60c16115e7d1bc259eefe734b00ea434fe5f  # EM DV TLS CA - G3C
63ecefee431d49523bc1136c4e72d0206a477086caf606cd5cf025686c109cf8  # EM OV TLS CA - G3C
5c0660a2b164910d8ff589c18e14552e9e0ec237dcefe2cb736d41a4811f81a0  # EM EV TLS CA - G3C
ec4ffa1ad0ac88081314b7aaffef6a91f97cd57291bb5ba686c5415f5eb4f6b6  # EM OV CS CA - G3B
92c063d67e8f14db71d288e11266ffdaf69cbf115f7bab14f3bc2f68d25e0e30  # EM OV CS CA - G3C

Compromised CA certificates (SHA-256)

Root being removed by Chrome and Mozilla: emSign ECC Root CA - G3, SHA-256 86A1ECBA089C4A8D3BBE2734C612BA341D813E043CF9E8A862CD5C57A36BBE6B.

Verdict

This incident turns CA key compromise from a secrecy problem into an inventory problem. The keys are public and forging takes seconds. The control that matters is whether every system you rely on rejects these eight keys on both chain paths.