Indian Certificate Authority eMudhra Exits TLS Business After Catastrophic Key Generation Failure

India-based eMudhra Limited has decided to cease operations in the certificate authority sector, according to a statement from V. Srinivasan, the company's chairman. The decision follows the revelation that eMudhra had distributed eight intermediate TLS credentials with severely compromised private keys—one containing merely 4 bits of entropy instead of the required 384 bits. These defective certificates would have allowed attackers to forge credentials trusted by all major web browsers, email servers, IoT devices, Docker containers, and countless other systems relying on the company's root certificates.

Srinivasan attributed the exit to mounting compliance expenses and the complexity of regulatory obligations, combined with the TLS business representing only 1 percent of eMudhra's total revenue. He also noted that the proliferation of free certificate providers, such as Let's Encrypt, had eroded the financial viability of the business relative to the company's other product lines.

Reputational Damage and Industry Consequences

In a statement posted Thursday, eMudhra acknowledged the severity of the public backlash: "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."

The announcement came two days after security researchers disclosed the existence of the eight certificates with defective private keys. Cracking these keys required only milliseconds of computational effort, after which attackers could generate TLS certificates that would be accepted by all major browsers and countless other systems. Browser vendors moved quickly to block certificates issued with these intermediate credentials within one or two days of the discovery. eMudhra faced the imminent threat of losing its certificate authority status through the CA/Browser Forum, the industry body that governs participation in the TLS ecosystem.

The Technical Failure

The eight compromised certificates should have contained NIST P-384 elliptic curve cryptography private keys with approximately 384 bits of entropy, providing 2384 possible key combinations—a number with 116 digits. Instead, the defective keys ranged from 3 to 8 bits in size, with the strongest offering only 256 possible values. The actual private keys were 4, 56, 66, 115, 155, 156, 230, and 237 bits.

On Wednesday, eMudhra released a preliminary technical explanation. The company stated that the certificates were "created under eMudhra's ECC root in a Key Generation Ceremony (KGC) held on April 30, 2025, using FIPS 140-2 Level 3 Hardware Security Modules (HSMs). A flaw in the KGC caused a wrap/unwrap step to produce a second set of weak keys alongside the original strong keys. The weak keys were the ones published to the browser root stores. eMudhra is working to establish the root cause."

Hardware Security Modules are specialized devices designed to store encryption keys and other sensitive cryptographic material in isolation from network infrastructure. The wrap/unwrap process occurs when keys are transferred between HSMs: the source device encrypts the key using a separate wrapping key before transmission, and the destination device decrypts it upon receipt.

Detailed Account of Process Failures

In a more detailed explanation posted to Mozilla's Bugzilla forum, eMudhra provided additional context:

[T]here appears to be a flaw in the KGC script that was used on that specific day to create these ECC issuers. As for these ECC keys, our review of the KGC, assessment of the code and view of HSM keys so far indicate that a) a set of original ECC keys were created onboard as expected b) an approved deviation to our usual KGC to test a wrap/unwrap was introduced as these keys were meant for export for this instance c) a flaw in the code resulted in the second pair of keys being created onboard which were weaker d) these second pair of weaker keys were used by mistake to create the csr [certificate signing request] (because the key labels were similar) and signed by our root e) the CSR from these weaker keys were also sent over to [fellow certificate authority] Sectigo for cross signing (we verified the files sent over to Sectigo).

eMudhra, in Mozilla Bugzilla

The CRL's were signed with the original private keys (which were supposed to be the correct keys with appropriate entropy) but given that this resulted in incorrect signatures, they were resigned with flawed keys. There were human errors in multiple steps of the process that resulted in significant flaws in the key lifecycle integrity process for this KGC. We are now digging deeper for code flaws, process gaps, maker/checker controls specific to this issue. Over the next week, we will reverify every key ceremony we have done.

eMudhra, in Mozilla Bugzilla

A certificate revocation list (CRL) is a digitally signed document published by a certificate authority to identify certificates that have been revoked before their scheduled expiration. The fact that eMudhra's initial CRL signatures were incorrect raises a critical question: why did the organization not investigate the cause of these signature failures at the time they occurred?

Ongoing Risk

Although browser vendors have successfully blocked the compromised intermediate certificates, the threat persists across a broader ecosystem. Many devices that depend on these certificates operate on much longer update cycles than web browsers. Embedded systems and other specialized hardware may never receive updates capable of blocking these credentials, leaving them potentially vulnerable to certificate forgery attacks.