eMudhra's Flawed Key Ceremony Put Eight Trusted CA Keys Within Trivial Reach

Eight intermediate certificate authorities run by India's eMudhra were issued with private keys that anyone could recover from the public certificates in well under a second. A researcher known as "Wayne" reported this on 17 October 2026. Mozilla received the report at 20:06 UTC, forwarded by the Chrome Root Program. Mozilla recovered the keys independently within about two hours and without knowing the reporter's method. That confirmed the problem was in key generation and was trivial to exploit.

The cause was not an intrusion. By eMudhra's account, it was a faulty script run during a key ceremony, and human checks failed to catch it.

01How weak the keys were

These were P-384 elliptic-curve keys. A properly generated private key is a number drawn from a space of roughly 2^384 values. According to Mozilla's incident report, all eight keys had values below 256, so an attacker needed to test only 256 candidates. The keys were 4, 56, 66, 115, 155, 156, 230 and 237. The private key for "EM OV TLS CA - G3C" was just 4.

Because an elliptic-curve public key is the private scalar multiplied by the curve's base point, a scalar under 256 can be found by computing a few hundred multiples of that point. It then takes one comparison against the public key in the certificate. That is the inference behind the sub-second recovery times reported. Ars Technica puts the effective key sizes at 3 to 8 bits. One vendor write-up says "bytes", which is inconsistent with the key values themselves.

An intermediate CA key can sign any end-entity certificate that chains to the root above it. An attacker holding one of these keys could forge a certificate for any domain and impersonate servers to intercept or modify traffic. Exploitation still needs an active adversary-in-the-middle position, as Ars notes. That is a high bar for some attackers but easy for anyone controlling a local network.

Scope matters. The eight keys came from a batch of 24 intermediates generated on 30 April 2025. Six issue TLS certificates and two are for code signing, and Sectigo cross-signed all eight in May 2025. Counting the cross-signs, 16 certificates were affected.

02What went wrong in the ceremony

A key ceremony is the scripted, witnessed procedure in which a CA generates its most sensitive keys inside hardware security modules (HSMs). eMudhra says the ceremony used FIPS 140-2 Level 3 HSMs. Its updated statement stresses that the flaw was in one step of the procedure, not an absence of HSMs.

The Bugzilla account gives the sequence:

• The ceremony created the expected strong ECC key pairs on board the HSM.
• An approved deviation added a wrap/unwrap test, because these keys were meant for export in this instance. Wrapping encrypts a key under another key so it can move between HSMs.
• A code flaw also created a second, weak key pair on board.
• The weak pair's labels resembled the originals', so it was mistakenly used to build the certificate signing requests, which the root then signed.
• The same CSRs went to Sectigo for cross-signing.

Nothing in this chain required cryptographic hardware to fail. The HSM generated a bad key on request, and a person or process picked the wrong one. The company itself concedes that a script error resulted in issuing CAs with weak keys. It also acknowledged human errors at multiple steps and promised to re-verify every key ceremony it has run. That points to missing maker/checker controls. Nobody compared the public keys being certified with the ones the ceremony was supposed to produce, and nobody sanity-checked key size or randomness before the root signed.

03The warning that was missed

The most uncomfortable detail is a 2025 precursor. Mozilla's questions to eMudhra refer to Bug 1970728, from June 2025. There, the key used to sign certain CRLs did not match the public key in the corresponding CA certificate. eMudhra located the second key pair, which did match, and re-signed the CRLs with it. It did not halt operations to ask why two pairs existed. A CRL is the signed list of revoked certificates a CA publishes. A CA whose CRL fails verification has a key-integrity problem by definition.

According to eMudhra's later explanation, the CRLs were first signed with the original strong keys. Those signatures failed because the certificates were issued over the weak keys, so the CRLs were re-signed with the flawed ones. One threat-advisory vendor says the flaw survived about 17 months and two audit cycles. That is a secondary claim, and I have not verified the audit details. Whatever the audit record shows, the 2025 incident had a diagnostic path that would have exposed the problem, and it was closed as a configuration mistake.

Discovery was cheap. Reports describe the researcher testing the CCADB corpus of publicly trusted intermediates, and one account says Google's open-source paranoid_crypto checks were used. Scanning public certificates for weak keys is an old technique. No public evidence suggests it needed anything exotic.

04Revocation, and why it was not the end

Containment of the browser population was fast. Chrome shipped a CRLSet update and Mozilla pushed OneCRL entries on 17 October, with no browser restart required. eMudhra revoked all eight intermediates on 18 October (reason: caCompromise). Sectigo revoked the cross-certificates on 19 October. Apple and Microsoft followed over the next days, with some reports differing by a day or two on exact dates. Ars Technica's early report of a day or two for browser blocks is slower than the primary timeline. It also noted Edge on Windows 10 still connecting to vulnerable hosts at publication. Microsoft did not elaborate.

The harder problem is clients that do not consume revocation data. Mozilla decided on emergency removal of trust in the parent root, emSign ECC Root CA - G3, to protect clients that ignore revocation information or cannot withdraw trust in specific intermediates. Chrome said it would follow. Reports put Chrome's removal reaching all devices on 27 October, which is today. Mozilla's Go and NSS fixes shipped on 20 October.

Filippo Valsorda, a Go cryptography maintainer, told Ars the cleanup would have a very long tail. He cited IoT devices, containers, forgotten Linux machines and tools that bundle their own root stores, and compared it to Heartbleed in scale. That comparison is his judgement and remains unproven. Cloudflare, for its part, reported the keys were trusted within its own stack and shipped client updates.

The distrust has a collateral cost. Certificate Transparency data as of 21 October showed about 30,800 unexpired precertificates chaining to the distrusted root. eMudhra estimated about 97% of them were issued via ACME. It is migrating subscribers to its RSA G1 hierarchy. Some of those are legitimate certificates that now have to be replaced because of an unrelated failure upstream.

05Detection and what it shows about oversight

Whether anyone abused the keys is not fully settled, but the evidence so far is reassuring. Ars reported no transparency-log evidence of malicious use. A secondary account says Google found no TLS certificates chaining to the six intermediates logged before it blocked them. Red Sift found a handful logged after disclosure, from researchers testing the recovered keys. eMudhra says only one intermediate was put into production and none issued customer certificates. Transparency logs only detect certificates that get logged, and clients that do not enforce CT could have been served unlogged forgeries. That residual risk cannot be ruled out, and several analysts say so.

Three lessons stand out:

1. Audits sample process, not outcomes. A ceremony that passes a witnessed checklist can still certify the wrong key. A mechanical check that the certified public key matches the HSM's intended key, plus a minimum-entropy check, would have caught this.
2. Anomalies need root-cause analysis. The 2025 CRL mismatch was a free signal. Mozilla's published questions go straight at why it was papered over.
3. Revocation is only as good as its distribution. Browsers can block in hours. Everything else takes software updates, and distrusting a whole root is the blunt instrument that reaches the long tail.

eMudhra's board announced on Thursday that it would exit global TLS. The chairman cited compliance costs and a business line generating about 1 percent of revenue. The company is still reviewing its key ceremonies, and the root cause analysis is incomplete. Chrome and Mozilla's decisions on its remaining RSA root are also pending. The missing pieces are the full ceremony logs, the code diff and an account of why the 2025 anomaly was not followed up. Those would show whether this was one bad script or a control environment that could not detect a one-byte private key.