India-based certificate authority eMudhra Limited says it will leave the global SSL/TLS certificate business. The decision follows the discovery of eight intermediate TLS certificates whose private keys were so weak that they could be recovered almost instantly. Anyone who recovered one of those keys could mint TLS certificates for any website or mail server. One key was a value of just 4.
The company announced the decision in a Thursday post, two days after researchers disclosed the problem, according to the report by Ars Technica. Chairman V. Srinivasan cited rising costs and growing compliance requirements. He also said SSL/TLS accounts for only about 1 percent of the company's revenue, and that free TLS certificate providers had reduced the return on the business compared with eMudhra's other products and services. In the post, eMudhra said that social media attention had put scrutiny on the incident out of proportion to the role TLS plays in its operations, and that its board had concluded that withdrawal was the right choice for the company and its shareholders.
Key sizes far below the expected strength
Researchers found that the eight certificates were issued with private keys of between 3 and 8 bits. The keys were meant to be NIST P-384 elliptic curve keys, which should carry roughly 384 bits of entropy. The defective keys' values were 4, 56, 66, 115, 155, 156, 230 and 237. The strongest of them allowed at most 256 possibilities, compared with the roughly 2^384 possibilities a correct key should offer, a number of 116 digits.
According to the researchers' account, the weakness was easy to exploit. Recovering a key took only milliseconds. Once a key was recovered, an attacker could use it to create certificates that major browsers would trust, and those certificates could in turn be accepted by a large and unknown number of email servers, IoT devices, Docker containers, old Linux machines and unmaintained command-line tools that carry their own copies of the root certificates.
Browser makers blocked certificates issued under the affected intermediates within a day or two of the discovery. Ars Technica noted that other devices that depend on the same certificates may need much longer to take the same step, and that some embedded devices may never be able to block them. Ars also said eMudhra probably faced the possibility that the CA/Browser Forum, the industry group that sets the rules for the TLS certificate program, could remove its authority, a view that is Ars's assessment rather than a stated decision.
eMudhra's explanation
On Wednesday, eMudhra published a short explanation. It said the certificates were created under its ECC root during a Key Generation Ceremony (KGC) held on April 30, 2025, using FIPS 140-2 Level 3 Hardware Security Modules (HSMs). According to the company, a flaw in the KGC caused a wrap/unwrap step to produce a second set of weak keys next to the original strong keys, and it was the weak keys that were published to the browser root stores. eMudhra said it was still working to establish the root cause.
HSMs are dedicated devices for storing encryption keys and other sensitive data, and they are normally isolated from most of a network. Wrapping and unwrapping is the process used to move a key between HSMs: the sending device encrypts the key under a separate wrapping key, and the receiving device decrypts it on arrival.
In a Mozilla Bugzilla thread, eMudhra gave more detail. It said that the KGC script used on that day contained a flaw. The original ECC keys were generated on the device as expected. An approved change to the usual procedure, meant to test a wrap/unwrap for keys intended for export, was introduced. A code flaw then caused a second, weaker key pair to be generated on the device. Because the key labels were similar, the weaker pair was mistakenly used to create the certificate signing request, which the root then signed. eMudhra said the CSR made from the weak keys was also sent to Sectigo for cross-signing, and that the company had checked the files it sent.
eMudhra also said that its certificate revocation lists (CRLs) were first signed with the original, correctly generated private keys. Those signatures came out incorrect, so the CRLs were re-signed with the flawed keys. Ars Technica asked why the company did not investigate the cause of that signing failure sooner. The company said human errors at several steps had caused significant weaknesses in the key lifecycle integrity process for that ceremony. It said it was examining code flaws, process gaps and maker/checker controls, and that it would reverify every key ceremony it had performed over the following week.
