eMudhra, the certificate authority that issued eight intermediate TLS credentials so weak that anyone could mint certificates for any website or mail server—one had a private encryption key of just 4—said it’s getting out of the business.

V. Srinivasan, chairman of India-based eMudhra Limited, cited increasing costs and complexities of compliance requirements—paired with the business generating just 1 percent of its revenue. He also said that the emergence of organizations providing TLS certificates free of charge further reduced returns on investment when compared to other products and services the company offers.

Don’t let the door hit you on the butt

“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,” the company continued in a Thursday post. “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 researchers revealed eMudhra had issued eight certificates with private keys so defective they were trivial to discover. Anyone who took the time—which was measured in milliseconds—could crack them and then use them to generate TLS certificates that would be trusted by all major browsers, as well as an untold number of email servers, IoT devices, Docker containers, forgotten Linux machines, and unmaintained CLI tools that ship their own copy of the roots.

Whereas NIST P-384 elliptic curve cryptography private keys—used in the type of certificates eMudhra issued—are supposed to contain roughly 384 bits of entropy, the eight compromised certificates had key sizes ranging from 3 to 8 bits. Stated differently, whereas there are supposed to be 2³⁸⁴—a number with 116 digits—different key possibilities, the strongest of the defective keys had a maximum of just 256. The private keys were 4, 56, 66, 115, 155, 156, 230, 237.

Browser makers blocked certificates that were issued with the intermediate certificates within a day or two of them being discovered. eMudhra almost certainly faced the prospect of its certificate authority status being pulled by the CA/Browser Forum, an industry-wide group that sets rules for admittance into the TLS certificate program.

What went wrong? A partial explanation.

On Wednesday, eMudhra provided a brief explanation for the debacle. 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),” the company said. “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.”

HSMs are dedicated devices for storing encryption keys and other highly sensitive data. They are generally segregated from most of a network to prevent leakage. Wrapping and unwrapping refers to the process that occurs when keys are being transferred from one HSM to another. Before the handover, the HSM storing the key wraps it in a separate key. Once the encrypted key is moved to a new HSM, the latter unwraps the key.

In a thread on Mozilla’s Bugzilla forum, eMudhra provided more details: Among them:

[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).

Additionally, eMudhra said:

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.

A CRL, short for certificate revocation list, is a digitally signed list published by a certificate authority identifying certificates that have been revoked before their expiration dates. The revelation that the initial signing resulted in incorrect CRL signatures raises the question: why didn’t eMudhra investigate the cause of the failure?

With the intermediate certificates blocked by browsers, much of the threat is gone. But plenty of other devices that rely on the same certificates require much longer windows to take the same action. Still other devices, such as embedded devices, may never be able to block them.