eMudhra, an Indian company whose business is selling digital trust, is giving up one kind of it: the TLS certificates that tell your browser a website really is the website it claims to be. As Dan Goodin reported at Ars Technica, the company announced the exit on Thursday. That was two days after researchers made public that eMudhra had issued eight intermediate certificates whose private keys could be cracked in milliseconds. One of those keys was 4.
Not 4 kilobits or 4 anything else. The number 4.
Some background on why that matters. Your browser ships with a short list of root certificate authorities it trusts. The roots sign intermediate certificates, and the intermediates sign the certificates for individual websites. If you hold an intermediate’s private key, you can write a certificate for any website or mail server you like, and software that trusts the root will accept it. That software includes every major browser, plus a long tail of email servers, IoT gadgets, Docker containers, neglected Linux boxes and command-line tools that carry their own copy of the root list. The private key is the entire product. The rest is paperwork.
The certificates used NIST P-384 elliptic-curve keys. The private key there is supposed to be a random number with about 384 bits of entropy, so there should be roughly 2^384 possibilities, a number 116 digits long. The eight eMudhra keys ranged from 3 to 8 bits. They were 4, 56, 66, 115, 155, 156, 230 and 237. Each certificate publishes its public key, which is just the private number multiplied against a fixed point on the curve. So the attack goes like this: try 1, try 2, try 3, and stop when the answer matches. You never get past 256. Mozilla’s incident bug says it recovered the keys itself without knowing the reporter’s method, and Scott Helme told The Register that he pulled them out on his laptop in under a second.
How you get a key of 4
eMudhra’s explanation in the Mozilla bug goes back to a key ceremony on April 30, 2025, held to create 24 subordinate CAs. A flaw in a wrap/unwrap step produced a second set of weak P-384 keys next to the proper ones. Their labels looked like the good keys’ labels, and the weak ones were mistakenly used for eight of the intermediates. According to the bug, six were TLS intermediates trusted by the Chrome, Mozilla, Microsoft and Apple root programs, and two were code-signing certificates trusted by Microsoft. Ars described all eight as TLS credentials. The company says its systems were not breached and that the intermediates never issued certificates to end users. The flaw sat unnoticed for roughly 18 months, though not for want of clues: the bug notes that revocation lists for the six TLS intermediates had been failing verification since late May 2025, a problem raised in a June 2025 bug opened by Sectigo. As rews has covered, those keys made it through audits and root-program checks the whole time.
Once someone did notice, things moved fast. Mozilla says the report reached it at 20:06 UTC on October 17, sent on by the Chrome Root Program from a researcher named Wayne, with proof of control over all eight keys. Firefox’s distrust was in place by 22:59 UTC, under three hours later. eMudhra marked the certificates revoked at 09:38 UTC on October 18, about 13 and a half hours after the report. The Hacker News reported that Google found no website certificate from the six TLS intermediates in Certificate Transparency logs before Chrome blocked them.
Proportion
Then came the announcement. Chairman V. Srinivasan pointed to the rising cost and complexity of compliance and to the fact that TLS brought in only 1 percent of revenue. He also said free certificate providers had cut the returns compared with eMudhra’s other products. And then this, from the company’s post:
However, the level of social media amplification around this incident has brought scrutiny that is out of proportion to SSL/TLS’s place in our business. In view of this, after detailed deliberations our board has concluded that withdrawing from global SSL/TLS is the right decision for eMudhra and its shareholders.
Translation: people online were mean about the key that was 4, and the line of business wasn’t worth the trouble anyway. eMudhra’s press release also has Srinivasan saying the company dealt with the incident diligently, revoking the affected CAs within 14 hours and disclosing promptly. On the timestamps above that is accurate, though Firefox had stopped trusting the certificates more than ten hours before eMudhra revoked them.
I think “out of proportion” is the most revealing phrase here, because it is correct in a way the company may not intend. Imagine you run a company and one division brings in 1 percent of revenue, earns thin margins against free competitors and requires expensive audits. You would sensibly give it about 1 percent of your attention. The trouble is that an intermediate CA key is not a 1 percent kind of asset. Its value to eMudhra was a sliver of revenue. Its value to an attacker was the power to impersonate any website to billions of devices. The scrutiny was sized to the second number, and the company’s investment was sized to the first. A system that relies on lots of small businesses each guarding a master key will keep running into this gap, and this time the gap was as wide as it gets.
As for what comes next, eMudhra says its G1 RSA roots will keep serving customers through a transition. Affected customers will get free replacement certificates from partners it has not named, and it has given no date for the exit. Revocation and status services will run until every issued certificate expires or is replaced, and it will finish its obligations to the root programs, including a full root-cause report. The Hacker News reported that Chrome and Firefox are also withdrawing trust in eMudhra’s ECC root. The digital signature certificate and eSign businesses carry on, and the company says its global TLS infrastructure is kept separate from them.
Which seems wise. Those are the parts of the business with a reason to have their keys generated properly.