eMudhra exits SSL/TLS certificate business after vulnerability disclosure

Key Takeaways

• eMudhra is exiting the global SSL/TLS certificate business due to a critical vulnerability involving weak private keys in eight intermediate Certificate Authority (CA) certificates.
• A researcher discovered that the P-384 elliptic-curve private keys lacked sufficient randomness, making them easily recoverable from their public keys.
• No end-entity certificates were issued by the compromised intermediate CAs, and eMudhra asserts no infrastructure breach occurred.
• Major browsers like Google and Mozilla have implemented emergency blocking measures and are moving to distrust eMudhra’s relevant root certificates.

eMudhra Exits SSL/TLS Business Amidst Private Key Vulnerability Fallout

In a significant development for the digital trust ecosystem, eMudhra Limited has announced its withdrawal from the global SSL/TLS certificate issuance business. This decision follows the disclosure of a critical vulnerability involving weak private keys within eight of its intermediate Certificate Authority (CA) certificates, leading to urgent protective actions by major web browsers and heightened scrutiny of the company’s certificate issuance practices. Despite this exit, eMudhra stated that its other digital trust services remain operational and unaffected.

The company’s board approved the voluntary departure on October 22, 2026, after a thorough review of the incident and its potential impact on the business outlook. According to an official announcement, eMudhra Chairman V. Srinivasan confirmed that all affected CA certificates were revoked within 14 hours of discovery, with prompt disclosure to relevant parties.

eMudhra emphasized that none of the compromised intermediate CAs had been used to issue end-entity certificates, which are utilized by websites and software publishers. The company also reiterated that its core infrastructure was not compromised, no data breach occurred, and all physical and logical security controls remained intact throughout the incident.

Weak Private Keys Trigger Emergency Browser Actions

The incident came to light on October 17, initiated by a report from a researcher identified only as Wayne. Mozilla’s public incident record indicates that the researcher provided proof of control over eight private keys. Mozilla subsequently independently verified these keys, confirming a severe flaw in their generation process. Six of the affected certificates supported TLS, while the remaining two were intended for code signing.

The root of the technical issue was a critical lack of randomness during the key generation process. India’s Computer Emergency Response Team (CERT-In) specified that the affected P-384 elliptic-curve private keys possessed values smaller than 256, enabling their recovery from public keys almost instantaneously. This vulnerability stemmed from the key generation methodology itself, not from any inherent weakness in the P-384 algorithm.

eMudhra’s preliminary investigation points to a key-generation ceremony conducted on April 30, 2025. During a key wrap and unwrap step, a flawed script inadvertently created a second set of weak keys. Subsequent human error, driven by similar key labels, led staff to utilize these weak keys in certificate signing requests instead of the original, strong keys.

The severity of this compromise prompted immediate emergency blocking measures by major browser vendors. The recovery of these private keys by an unauthorized entity could enable the issuance of fraudulent certificates. In scenarios where affected certificate chains were still trusted, an attacker intercepting network traffic could impersonate legitimate websites or tamper with communications.

Both Google and Mozilla swiftly blocked the compromised TLS keys on October 17. Additionally, both companies initiated steps to remove trust in the “emSign ECC Root CA – G3,” safeguarding clients who may not reliably receive or enforce intermediate certificate revocation information. CERT-In anticipated that Chrome’s root-store update would propagate to affected devices by October 27.

eMudhra estimated that approximately 30,000 certificates would require migration, a figure distinct from certificates issued by the eight vulnerable intermediates. As of October 21, CERT-In reported that public disclosures had not confirmed any malicious exploitation of the vulnerability.

This incident underscores the far-reaching implications of certificate authority failures, a phenomenon also observed when Google previously removed trust in other CAs from Chrome. Such browser trust decisions can compel website operators to replace otherwise valid certificates to maintain service accessibility for their users.

eMudhra stated that its global SSL/TLS business segment contributed approximately 1% of its total revenue. The company cited increasing data sovereignty requirements, escalating compliance costs, and fierce competition from free certificate providers as factors diminishing the profitability of this business. Chairman Srinivasan also suggested that the level of scrutiny from social media was disproportionate to the segment’s overall size within their operations.

The company plans to maintain its G1 RSA roots to serve existing customers during this transition period and will provide replacement certificates through partners at no additional cost. Revocation and certificate status services will continue until all issued certificates either expire or are replaced. eMudhra has also committed to fulfilling its obligations under browser programs, including delivering a comprehensive root-cause analysis report.

What You Should Do

• Administrators should immediately update all web browsers and trust stores across their networks.
• Review all active certificate chains to identify and replace any certificates issued by eMudhra that might be affected.
• Do not assume browser updates cover all systems; check separate certificate bundles within applications, containers, and network devices for any reliance on eMudhra certificates.
• Consult CERT-In’s advisory for further guidance and technical details.

Disclaimer: HackersRadar reports on cybersecurity threats and incidents for informational and awareness purposes only. We do not engage in hacking activities, data exfiltration, or the hosting or distribution of stolen or leaked information. All content is based on publicly available sources.