eMudhra's CA private key was the number 4: how eight P-384 keys under 256 passed every check

On 17 October 2026 a researcher reported that the private keys of eight eMudhra intermediate certificate authorities could be recovered from their own…

Loading
mozilla··PT2M16.967S

video loads only when you press play

On 17 October 2026 a researcher reported that the private keys of eight eMudhra intermediate certificate authorities could be recovered from their own…

// the short version

On 17 October 2026 a researcher reported that the private keys of eight eMudhra intermediate certificate authorities could be recovered from their own certificates. Six were TLS intermediates trusted by the Chrome, Mozilla, Microsoft and Apple root programs; two were code-signing intermediates trusted by Microsoft. All eight were created at one key ceremony on 30 April 2025.

// what to take away

  • A P-384 private key should be a random number up to 384 bits long. The eight eMudhra intermediate CA keys reported on 17 October 2026 were all under 256, so recovering one meant computing 1×G, 2×G, 3×G until it matched the certificate's public key.
  • Every structural check passed: a small private key still gives a valid point on the curve, and a check that inspects a certificate only ever sees the public key. eMudhra says a ceremony script bug created a second, weaker key pair with a similar label.
  • Browsers blocked the intermediates within days and require Certificate Transparency. curl, Python, Node and other non-browser clients trust a CA bundle on disk, so they need an updated bundle and rebuilt container images.

What happened to eMudhra's certificates

eMudhra is a certificate authority (CA) based in India that issues certificates under the emSign brand. A CA vouches for a website by signing its certificate. In practice the CA's long-lived root key stays offline, and the day-to-day signing is done by intermediate CAs: certificates the root has signed, each with its own key pair. A browser trusts a site's certificate if it chains through an intermediate to a root in its trust store.

On 17 October 2026 a researcher reported to Apple, Google, Microsoft, Mozilla and eMudhra that the private keys of eight eMudhra intermediates could be recovered, and attached a message signed with each key as proof. Six were TLS intermediates (DV, OV and EV, in two series named G3B and G3C) chaining to emSign Root TLS CA - G3, trusted by the Chrome, Mozilla, Microsoft and Apple root programs. Two were code-signing intermediates trusted by Microsoft. All eight came from one key generation ceremony on 30 April 2025, and Sectigo had cross-signed them in May 2025 from its AAA Certificate Services root.

An intermediate's private key is the most valuable thing a CA has after the root's. Anyone holding one can issue a certificate for any domain, and clients that trust the chain will accept it.

How a P-384 key works, and why its size is the whole defence

These were elliptic-curve keys on the NIST P-384 curve (also called secp384r1), used with ECDSA. The pieces are simple to state:

  • The curve comes with a fixed, published starting point, the generator G.
  • The private key is a number d, chosen at random between 1 and the curve's order, which is close to 2^384.
  • The public key, the value printed in the certificate, is Q = d × G: the point G added to itself d times using the curve's own addition rule.

Computing Q from d is fast, even for a 384-bit d, because the multiplication can be done by repeated doubling. Going the other way, finding d from Q, is the elliptic-curve discrete logarithm problem. The best known general methods need roughly the square root of the number of possible keys in steps, about 2^192 for P-384, which is far beyond any computer. A random 384-bit number has about 10^115 possible values, so nobody searches.

All of that security rests on d being large and random. Nothing in the curve or in ECDSA protects a key whose d is small. If d is known to be under 256, the search is to compute 1 × G, 2 × G, 3 × G and so on, and stop when the result equals the public key in the certificate. Mozilla's Dennis Jackson described exactly this, "generating the 'first' 256 P384 keys", as one of two ways to recover them.

The eight keys, and how fast they fall

Security researcher Scott Helme published the recovered values on 20 October 2026, and Mozilla's investigation confirms they are all below 256:

  • EM OV TLS CA - G3C (TLS): 4
  • EM EV TLS CA - G3C (TLS): 56
  • EM OV CS CA - G3B (code signing): 66
  • EM EV TLS CA - G3B (TLS): 115
  • EM OV TLS CA - G3B (TLS): 155
  • EM DV TLS CA - G3B (TLS): 156
  • EM DV TLS CA - G3C (TLS): 230
  • EM OV CS CA - G3C (code signing): 237

Written out in full, a key like this is 47 bytes of zeros followed by one byte. The longest search, for 237, takes 237 multiplications. Mozilla recovered all eight independently on the evening of the report, without knowing the reporter's method; Helme's laptop did the sixteen certificates (each key appears in an eMudhra certificate and a Sectigo cross-sign) in under a second. Both Mozilla and Helme also note that an AI coding agent recovered the keys from a one-line prompt.

The public key values shown in the video are real. They were computed for this explainer from the published P-384 generator: 4 × G begins 1382 51cd 52ac and is the public key of EM OV TLS CA - G3C.

Why every check passed

A public key made from d = 4 is a perfectly valid point on the curve. Its encoding is correct, the curve is correct, signatures made with it verify, and the certificate chains to a trusted root. Helme's summary is that every structural check passes and the only way to find out is to try.

That is the general lesson. A check that inspects a certificate can only see the public key, and the public key of a tiny secret is indistinguishable in form from the public key of a huge one. The property that mattered, the size of the secret, can only be tested by attempting the recovery, or prevented earlier, at generation time, by controls on how the key was made.

There was an earlier warning. In June 2025 Mozilla bug 1970728 recorded that eMudhra's certificate revocation lists (CRLs) for the same six TLS intermediates had invalid signatures. In its comment on the new bug, eMudhra says those CRLs were first signed with the original, intended keys, failed to verify, and were then re-signed with the keys that matched the certificates, which were the weak ones. The Chrome Root Program has asked eMudhra why that mismatch did not lead it to halt and investigate.

What eMudhra says went wrong

eMudhra's preliminary account, posted to the bug on 19 October 2026, is its own and has not been verified by the root programs:

  • The keys were generated on Utimaco hardware security modules (HSMs) that eMudhra says are FIPS 140-2 Level 3 compliant.
  • The B and C series intermediates were meant to be exported to data centres in Europe and the US, so the ceremony included an approved deviation to test key wrapping and unwrapping.
  • A flaw in the ceremony script created a second, weaker key pair on the HSM alongside the original strong one.
  • Because the key labels were similar, the weak pairs were used by mistake to create the certificate signing requests, which the root signed and which were also sent to Sectigo for cross-signing.
  • The RSA intermediates from the same ceremony took a different path and, eMudhra says, are not affected. The A and A-1 series were made on Entrust HSMs.

Others on the bug have questioned this. A certified HSM's internal key generation should not produce a private key below 256, so commenters have asked whether the weak keys were created from supplied key material rather than generated inside the module, and have asked for the ceremony script, logs and auditor reports. Mozilla sent eMudhra a list of questions on 20 October with a 24-hour deadline; as of 23 October it had not received a response, and both Mozilla and Chrome said so on the bug.

Who was protected, and who was not

Browsers were protected quickly. Chrome pushed the six TLS intermediates into its CRLSet, a revocation list Chrome downloads in the background, on the evening of 17 October (UTC). Firefox added them to OneCRL the same evening. Microsoft blocked them on 20 October and Apple on 22 October, according to the disclosure site. Browsers also enforce Certificate Transparency (CT): a certificate must appear in public, append-only logs to be trusted. The disclosure site reports no CT entries for these intermediates between their creation in April 2025 and the report, so a forged certificate could not have been accepted by a CT-enforcing browser without appearing in those logs.

Most other software was not. Command-line tools, language runtimes, package managers, CI runners and server-to-server API clients usually verify certificates against a CA bundle file on disk, do not check revocation, and do not check CT. eMudhra and Sectigo revoking the intermediates does nothing for them. In Helme's tests, curl, Python and Node accepted a certificate for api.stripe.com forged from one of these keys with default settings on every Linux and macOS machine he tried. Electron apps such as Slack and Discord carry their own copy and need an app update. On Windows, Helme found CryptoAPI accepted the chain unless revocation checking was switched on.

The code-signing keys are a separate risk. Windows trusts eMudhra's code-signing root, so malware signed with EM OV CS CA - G3B or G3C would look like signed software to anything that does not check revocation.

The fix for these clients is removing the root. Mozilla announced the emergency removal of emSign ECC Root CA - G3 on 20 October and shipped an NSS update; Chrome Root Store v43 is expected to remove it in Chrome Stable on 27 October 2026. Mozilla is not removing eMudhra's RSA root, emSign Root CA - G1. Downstream CA bundles took the change within days.

What to do about it

As listed on the disclosure site on 23 October 2026, patched versions include certifi 2026.10.19, Node.js 26.12.1, 24.22.1 and 22.23.4, Python 3.15.1, 3.14.9 and 3.13.17, Go 1.27.3 and 1.26.10, curl's CA bundle of 2026-10-20, Electron 44.9.1, 43.8.1 and 42.11.16, and updated ca-certificates packages for Debian, Ubuntu, Alpine, Fedora, RHEL and others.

  • Update the operating system's ca-certificates package and every library or runtime that ships its own bundle (certifi, Node, Java, Go).
  • Rebuild container images once their base images include the new bundle; a running container keeps the bundle it was built with.
  • On macOS, the built-in curl, git and python3 read /etc/ssl/cert.pem, which had not been updated as of 23 October; the disclosure site gives a command that removes the affected roots from it.
  • Do not "fix" new certificate errors by disabling verification. Cloudflare makes the same point: an error after patching usually means the patch is working.
  • Devices that cannot be updated, such as routers, printers, TVs and other frozen firmware, will trust these intermediates until the certificates expire in July 2039.

To check a specific client, the disclosure site hosts test servers whose certificates chain to the compromised intermediates; a certificate error from curl https://dv-g3b-emudhra.we-have-a-problem.com/ means that client no longer trusts them.

What the video left out

  • The 30,000 certificates. eMudhra estimated about 30,000 certificates need migrating, and Chrome counted about 30,800 unexpired precertificates under the G3 root as of 21 October, 99.9% of them issued by two Internet2 / InCommon subordinate CAs. Those certificates were not made with weak keys; they need replacing because the root they chain to is being removed.
  • Production use. eMudhra says the G3B and G3C intermediates were never put into production except EM DV TLS CA - G3C, and that the code-signing intermediates issued nothing.
  • The cross-signs. Sectigo's AAA Certificate Services root had already been removed from the Chrome and Mozilla stores but is still trusted by Microsoft and Apple, which is why the cross-signs mattered there. Sectigo revoked them on 19 October.
  • eMudhra's exit. On 22 October eMudhra announced it is withdrawing from the global SSL/TLS certificate business while continuing other certificate lines.

Terms

Certificate authority (CA)
An organisation trusted to vouch for websites and software by signing their certificates.
Intermediate CA
A CA certificate signed by a root, used for everyday signing so the root key can stay offline. Its key can sign a certificate for any name.
Root store / trust store
The list of root certificates a browser, operating system or library trusts.
P-384 (secp384r1)
A NIST elliptic curve. Its private keys are numbers up to about 2^384.
Generator point (G)
The fixed starting point every P-384 key pair is built from. The public key is d × G.
Discrete logarithm
The problem of recovering d from d × G. Infeasible for a random 384-bit d, trivial for a small one.
Key generation ceremony
A scripted, witnessed procedure in which a CA creates its keys inside hardware security modules.
Hardware security module (HSM)
A tamper-resistant device that generates and stores private keys and performs signing without exporting them.
Cross-signing
One CA signing another CA's certificate so it chains to more roots.
CRL, CRLSet, OneCRL, CRLite
A CRL is a CA's list of revoked certificates. CRLSet (Chrome), OneCRL and CRLite (Firefox) are lists the browser maker pushes to every install, so revocation works without the browser asking the CA.
Certificate Transparency (CT)
Public, append-only logs of issued certificates. Browsers reject certificates that are not logged, which makes secret mis-issuance visible.
CA bundle
A file of trusted root certificates on disk, such as ca-certificates, certifi or /etc/ssl/cert.pem, used by non-browser software.

Questions

Was eMudhra hacked?

No key was stolen. The private keys were small enough to be recomputed from the public certificates by anyone, from the day the certificates existed in April 2025. That is why Ian Carroll, on Mozilla's dev-security-policy list, called these keys an issue that "cannot be contained".

Could someone have used these keys before October 2026?

It was possible for about 17 months, and there is no way to know whether anyone did. Browsers that enforce Certificate Transparency could not have been attacked without a log entry appearing, and none did. Software that does not check CT, which is most non-browser software, could have been.

Am I affected?

An up-to-date Chrome, Firefox, Edge or Safari is protected. Command-line tools, scripts, servers and containers are protected once their CA bundle is updated and, for containers, the image rebuilt. The curl test above shows whether a given client still trusts the intermediates.

Why does a small private key break elliptic-curve cryptography?

The curve's security comes entirely from the number of possible private keys. With 2^384 of them, searching is hopeless. With 255, it is a loop. Nothing else in the algorithm compensates for a small key.

Why didn't the checks catch it?

A certificate check sees only the public key, and a small key's public key looks like any other. Catching it needed controls on how the key was generated, or someone trying to recover it.

What happens to websites with eMudhra certificates?

Certificates chaining to emSign ECC Root CA - G3 need replacing before browsers and bundles stop trusting that root; Chrome's removal is expected on 27 October 2026. eMudhra says it is moving customers to other hierarchies.

// further reading

// transcript

One of the keys behind the web's padlock was the number 4. Not four followed by a hundred random digits, just four. That padlock means a certificate authority vouched for the site, by signing its certificate with a private key nobody else can work out. Here that key is just a number, and the public key on the certificate is a fixed point on a curve multiplied by it, which is quick to do and hopeless to undo, as long as the number is a random 384-bit one, with about 10¹¹⁵ possibilities. In October, eight intermediate certificates from eMudhra, a certificate authority in India, turned out to have keys smaller than 256. So recovering one takes no clever maths, you just count. Multiply the point by one, by two, by three, and compare each answer with the public key on the certificate. At four, it matches. Security researcher Scott Helme's laptop recovered all eight in under a second. And nothing about these certificates looked wrong. A key of four still makes a valid point on the curve, and every structural check passes, because a check only sees the public key, and a small number's public key looks just like a big one's. eMudhra says a script bug at its key ceremony made a second, weaker key pair, and because the labels looked alike, someone used the wrong one. So nothing was ever stolen, the key was public from day one, and for 17 months anyone could have recovered it, with no way to know whether someone did. Chrome and Firefox blocked the eight certificates the day they were reported, with lists they push to every install, and Microsoft and Apple followed within days. Browsers also reject any certificate missing from the public Certificate Transparency logs, and nothing signed by these keys had appeared there before the report. But curl, Python and Node trust a file of certificates on disk and check neither, and when Helme forged a certificate with one of these keys, all three accepted it on every Linux and Mac he tried. Routers, printers and TVs that never get firmware updates will trust these keys until 2039. Anything you can update needs a fresh CA bundle and rebuilt container images. The curve did its job for seventeen months, it was just guarding the number four.

// source

This explainer is based on eMudhra: private key compromise of intermediate certificates by Mozilla ↗. The original reporting and technical work belong to its publisher.