When a Certificate Authority’s Private Key Was 4: The eMudhra Incident Explained
Eight eMudhra intermediate CA keys were compromised after a key-generation failure left P-384 private scalars smaller than 256. Here’s what happened, how Firefox responded, and what PKI teams should do.
PKI security | Certificate authorities | ECDSA
When a Certificate Authority’s Private Key Was 4: The eMudhra Incident Explained
In October 2026, Mozilla disclosed that the private keys associated with eight eMudhra intermediate certificate authorities had been compromised. One detail made the failure unforgettable: one of the private keys was the integer 4.
This was not a theoretical weakness in elliptic-curve cryptography, nor a failure of the P-384 algorithm. It was a key-generation failure: values that should have been chosen from an enormous cryptographic range were instead extremely small and easy to guess. The incident is a sharp reminder that a strong algorithm cannot rescue a weak key-generation process.
Why an intermediate CA key matters
A public certificate authority (CA) issues certificates that browsers and other software use to authenticate websites. Root CAs delegate signing authority to intermediate CAs, which in turn may issue certificates to websites. If an intermediate CA’s private signing key is compromised, an attacker may be able to create fraudulent certificates that appear to chain to a trusted root.
That creates risk beyond a single website or one organization’s certificate. Any client that trusts the affected chain and does not receive or enforce a block may be exposed to impersonation, depending on the application and connection path. Compromise of an intermediate key therefore requires a response across browser vendors, operating systems, libraries, and other trust-store consumers.
The random number was 4
The affected keys used ECDSA with the P-384 curve. A private key for this curve should be a secret scalar selected uniformly from a very large range. In this incident, the affected private scalars were integers less than 256. In byte form, that means nearly all bytes were zero and only the final byte carried the value.
For one key, that value was 4. When the possible values are limited to 0 through 255, an attacker does not need to solve the general elliptic-curve discrete logarithm problem. They can try the tiny set of candidate scalars, calculate each corresponding public key, and compare it with the public key already present in the certificate. That is computationally trivial.
The arithmetic and the curve were working as designed. The failure was that the secret input to the algorithm did not have the required unpredictability. The existence of an HSM or an approved cryptographic algorithm is not, on its own, evidence that a particular key was generated correctly: the ceremony, scripts, parameters, key labels, approvals, and resulting public keys all matter.
What happened in Firefox
Mozilla says it received a report of the compromised eMudhra intermediate keys on October 17, 2026. It added blocks for the affected certificates to OneCRL, Firefox’s centralized certificate revocation list distributed through Remote Settings. For Firefox installations with standard settings, the blocklist was distributed the same day without requiring users to install a browser update or restart.
Mozilla then shipped Firefox 158.0.1 and updates for Firefox ESR 115 and ESR 153. These releases provided the updated blocklist for users whose policies or network configuration might prevent Remote Settings updates. Mozilla also updated NSS, its widely used security library and certificate store, to remove the root that signed the affected intermediates. The different measures address an important operational reality: not every application consumes a browser’s live revocation service.
Read Mozilla’s account of the incident and its response: Protecting Firefox users following the compromise of eMudhra intermediate certificates.
Revocation is necessary, but not every client reacts the same way
Revoking a certificate and distributing a block are essential steps, but protection depends on how each client learns about and enforces that status. Browsers, server runtimes, mobile apps, containers, appliances, and embedded devices can use different certificate stores and revocation behavior. Some may not check revocation at all, may cache status, or may fail open when a status service cannot be reached.
For that reason, a CA incident cannot be treated as only a browser-update problem. Organizations need to know which trust stores and runtime versions their services use, whether updates have actually reached them, and whether applications honor the relevant revocation or distrust mechanisms.
Practical actions for PKI and security teams
- Update affected software and trust stores. Apply vendor security updates for browsers, operating systems, language runtimes, certificate bundles, and devices. Rebuild and redeploy software that embeds a trust store or uses a runtime-specific one.
- Check the full certificate chain. Review issuer and chain data for certificates used by public-facing services. Identify any certificates that chain through affected intermediates, and follow the issuing CA and platform guidance for replacement.
- Inventory trust-store dependencies. Record which applications use OS trust, browser trust, bundled CA packages, pinned certificates, custom roots, or HSM-backed stores. Do not assume one system-wide update changes them all.
- Verify actual deployment. Confirm that patches and trust updates reached production instances, containers, build agents, appliances, and long-lived workloads—not only employee browsers.
- Review key-generation controls. Validate cryptographic ceremony scripts, approved deviations, operator separation, key labels, backups, exports, and audit evidence. Confirm that the public key produced by a ceremony is the one submitted for issuance and that the resulting certificate matches the intended key.
- Maintain certificate ownership and lifecycle records. Track each certificate’s issuer, purpose, owner, deployment locations, expiry, and renewal path. Good inventory reduces the time needed to find affected chains and coordinate safe replacement.
- Prepare for trust changes. Test how your systems handle emergency distrust, CA replacement, certificate reissuance, and rollback. Keep a tested procedure for reaching systems that cannot receive automated updates.
What this incident does—and does not—say
This incident does not mean P-384 is broken. It does not mean every eMudhra certificate or root key was affected. It demonstrates that sound cryptography depends on the complete system: correct key generation, controlled issuance, transparent incident reporting, effective revocation, and timely updates to every relying client.
The number 4 is memorable, but the operational lesson is broader. Trust is not secured by an algorithm name or an HSM label alone. It depends on being able to prove what key was generated, how it was protected, which certificate it signed, where that certificate is trusted, and whether every affected system can stop trusting it when necessary.