The private key was 4: how eight eMudhra intermediate CAs lost their secret

Event: 17 October 2026. Analysis written on 4 November 2026. An intermediate certificate authority must keep its signing key secret. For eight eMudhra intermediates, the private P-384 scalars were 4, 56, 66, 115, 155, 156, 230 and 237, according to Mozilla’s public incident record. The headline value 4 is memorable; the shared defect is that all eight secrets were among fewer than 256 candidates. Six intermediates were for TLS, under emSign Root TLS CA - G3; two were for code signing, under emSign Root CS CA - G3. Their authorized uses and roots must be distinguished.

Why the public certificates exposed the keys

Elliptic curve cryptography derives a public point Q = d × G from a private scalar d and a standard generator point G. If d is uniformly drawn from the P-384 range, solving for it is infeasible with known methods. If d is known to be below 256, a defender or attacker can calculate the first 255 multiples of G and compare each result with the public point in the CA certificate. No HSM access, leaked key file or network attack is required. A key’s nominal curve size is therefore different from the entropy of the secret actually chosen.

The researcher reported this on 17 October after checking a corpus of public CA certificates, then sent signed attestations using the recovered keys. Mozilla independently recovered the keys. The Bugzilla record documents these observations and the notification timeline. A defensive discovery method is to inventory public intermediate certificates, check their EC points against a small-scalar dictionary, and compare all certificate signing requests, issued certificates and revocation lists with the ceremony records.

What failed in the ceremony

eMudhra says the keys were processed in certified HSMs. During an unusual wrap/unwrap step in the April 2025 key ceremony, a second, weak set of keys appeared alongside the intended strong set. The weak set was used for the issued intermediates. In 2025, revocation lists for related intermediates had been signed with keys that did not match their certificates; the lists were re-signed, but the underlying presence of two key sets was not resolved then. Mozilla has asked why that mismatch did not trigger a full key lifecycle investigation. The complete root cause report was still pending on 4 November, and eMudhra had announced an independent KPMG review. These are the vendor’s account and the public questions, rather than a verified byte-level explanation of the wrap/unwrap bug.

Exploitability and containment

Someone holding one of the six TLS intermediate CA private keys can sign a counterfeit website certificate. To use it against a victim, the attacker would also have to route that victim’s connection to the impersonating server and reach a client that still accepts the chain. Knowing the key alone neither redirects traffic nor retroactively decrypts a recorded modern TLS session. The two code-signing keys threaten a different trust use. eMudhra says the affected intermediates had not issued legitimate end-entity certificates before disclosure, with only one of them in production. That limits known operational use but does not make the keys safe: outsiders could sign their own certificates.

Mozilla pushed the affected certificates to Firefox’s OneCRL on 17 October and later removed the relevant root from NSS, protecting applications that do not receive OneCRL updates. eMudhra revoked the eight intermediates on 18 October. (Mozilla response, eMudhra updates) Removing a root has a wider availability cost: legitimate certificates under other intermediates in that hierarchy must migrate. eMudhra estimates about 30,800 certificates in a US customer group needed transition. That is a different population from the eight weak keys.

The engineering lesson is to verify the output of key generation independently, bind every CSR, certificate and CRL to the intended ceremony key, and treat an unexplained key mismatch as a key integrity incident. An HSM label or passed audit cannot substitute for those checks.

Our X.509 certificate reader helps inspect a public certificate’s fields in the browser; it does not replace chain validation or weak-key detection. The Binance and EIP-7702 case illustrates a different trust failure: a valid signature can accompany a transaction the business never approved.

Primary sources: Mozilla incident record, Mozilla security announcement, eMudhra updates.