- Researcher Scott Helme recovered the private keys of eight eMudhra intermediate certificates in under a second; one was the number 4. eMudhra says it will stop issuing TLS certificates.
- Chrome and Firefox blocked the keys within hours; Apple and Microsoft took until Monday and Tuesday. Helme's tests found curl, Python and Node trusted a forged chain by default.
- Inventory every place a CA bundle lives outside browsers, update it, and rebuild container images. Devices that cannot be updated need a separate plan.
A lock whose key was the number 4
Every certificate authority (CA) rests on a secret number. A CA is a body that vouches for websites. If the number can be guessed, the trust built on it fails. Independent researcher Scott Helme found that one eMudhra CA key was the number 4. Others were 56 and 115. He recovered them from the public certificates on his laptop. It took less than a second.
On Thursday, the Indian certificate authority said it will stop issuing SSL/TLS certificates, CyberScoop reported. Its digital signature and enterprise security services continue. The episode shows how trust fails in practice. Chrome and Firefox blocked the keys within hours. Apple blocked them on Monday and Microsoft on Tuesday. Much software outside browsers had no such safety net.
How the keys could be found so fast
The eight keys use elliptic-curve cryptography on the P-384 curve. The private key is a number, called d. The public key sits in the certificate for anyone to read. It is d multiplied by a fixed point on the curve. Going from d to the public key is easy. Going backwards is considered impractical. That holds only if d is huge.
A P-384 key should be a random number with roughly 10 to the power of 115 possibilities, Helme writes. Instead, each eMudhra key was 47 bytes of zeros followed by one final byte. One byte has 256 values. Finding the key takes at most 255 tries.
Nothing in the certificates looked wrong. A key built from d = 4 is a valid point on the curve. The encoding is fine. Every structural check passes. Helme says the only way to find the flaw is to try.
How a weak key reached production
eMudhra gave its account on Mozilla's incident ticket, Helme says. A bug in a script used during the key ceremony created a second, weak key pair on the hardware security module. The names were similar. A human error then led to the wrong keys being used. CyberScoop reports the ceremony took place in April 2025.
eMudhra says its infrastructure was not compromised and no data was breached. It says none of the eight intermediates issued end-entity certificates. Nobody had to steal these keys. Helme says anyone who looked at the certificates since April 2025 could have recovered them. That is a 17-month window. He says there is no way to know whether anyone did.
There is some reassurance. Chrome noted that no TLS certificates chaining to these CAs appeared in Certificate Transparency (CT) logs. CT is a public record of issued certificates. Helme adds that CT detects wrongly issued certificates but does not prevent them. Much software does not check it. CyberScoop reports that India's national response team, CERT-In, had seen no malicious use of the keys as of Wednesday.
Browsers moved fast. The rest did not.
Helme says a researcher reported the problem on Saturday, October 17. Chrome blocked the intermediates that evening. Firefox followed a few hours later. Mozilla then removed the eMudhra root. Helme says Chrome has confirmed the root will go in Chrome Root Store v43.
Most other TLS clients differ, Helme explains. They trust a CA bundle stored on disk. They do not check revocation by default. They do not check CT. So a revocation notice never reaches them.
He tested a certificate for api.stripe.com on a local server. With default settings, curl, Python and Node accepted it on every Linux and macOS machine he tried. On Windows, the chain was accepted unless revocation checking was switched on. An attacker would still need a place on the network path.
Helme lists where the exposure sits. It includes install scripts that download over HTTPS, build pipelines holding cloud keys, server-to-server API calls, and IoT and industrial devices. He also names Windows code signing, which trusts the eMudhra code-signing root directly. CyberScoop reports that Go, Node.js, Python's certifi bundle and several Linux distributions have shipped updates.
The business verdict
eMudhra's chairman, V. Srinivasan, cited rising data sovereignty and compliance costs. He also cited competitors that issue certificates free. He said social media amplification brought scrutiny "out of proportion" to the unit's place in the company. CyberScoop reports the shares fell 40% in the two days after disclosure.
What the episode shows
This shows that trust fails at the weakest client, not the strongest. Browsers have fast blocklists and CT. A build server running curl has neither.
Helme also reports that an AI agent recovered the keys from a single prompt. That is one researcher's result. It suggests this check is cheap to run, for defenders as well as attackers.
Questions for your team
Ask where CA bundles live outside browsers. Examples are operating system packages, certifi, Node, Homebrew and container base images. Ask who rebuilds container images once the base images update. Ask which devices run frozen firmware. Helme says those will trust the certificates until they expire in July 2039.
Revoking a key helps only the clients that ask. The task now is to find the ones that do not.
Produced by the WebPulse Newsroom with AI assistance from the original reporting credited below, and checked against that source by our editorial review. How we use AI.
Original reporting: Scott Helme (independent security researcher, scotthelme.co.uk).
