eMudhra SSL/TLS exit After Eight CA Keys Exposed

The eMudhra SSL/TLS exit follows the discovery of eight private keys that could be guessed in under a second. The flaw surfaced on October 17, 2026, when researcher Wayne exposed the issue to Mozilla. Mozilla recovered the keys, and Scott Helme demonstrated the weakness publicly, recovering all eight in less than a second. The keys were generated as small numbers in April 2025, instead of the large, unpredictable values expected for cryptographic security.

Browser Trust Actions

Mozilla blocked the affected intermediates through OneCRL and moved to remove trust in the emSign ECC Root CA – G3, the root that signed them. Google scheduled the removal from Chrome’s Root Store for October 27, and Chrome and Firefox had already blocked the six TLS intermediates. According to Google’s Certificate Transparency records, no TLS certificates chaining to the six affected website-signing intermediates appeared in the logs before they were blocked. However, about 30,800 unexpired certificates chained to the broader root hierarchy as of October 21, though not necessarily issued using the compromised keys.

eMudhra’s Response and Business Impact

eMudhra attributed the incident to a flaw in its key-generation process and said it is investigating the root cause. The company’s global SSL/TLS business accounts for roughly 1% of its revenue. Chairman V Srinivasan described the public scrutiny as disproportionate to the division’s overall importance. The company announced it would leave the global SSL/TLS certificate market, citing rising compliance costs and data sovereignty requirements.

Certificate Management History

Earlier warning signs surfaced when eMudhra published invalid certificate revocation lists (CRLs) in May 2025 for six intermediate authorities. Mozilla’s incident record shows that the earlier investigation did not identify that multiple key pairs had been generated for the affected authorities. The latest incident raises questions about the robustness of eMudhra’s certificate-management processes.

Operational Risks Beyond Browsers

The compromised keys affect more than just web browsers. Java keystores, container images, load balancers, and mutual TLS configurations may maintain separate trust stores. Java does not check certificate revocation by default, so unpatched environments may continue accepting forged certificates if they still trust the affected chain. On October 22, Azul confirmed that it had released updated Azul Zulu Builds of OpenJDK and Azul Prime versions that block the eight compromised certificates by adding them to the Java runtime’s blocklist.

Replacement and Revocation Services

eMudhra is offering free replacement certificates through partners and has committed to maintaining certificate revocation and status services until its issued certificates expire or are replaced. Seven of the eight intermediates had never been used in production, while the remaining one had not issued any end-entity certificates.

What Readers Should Verify

  • Check whether your organization’s certificates chain to the eMudhra intermediates or the emSign ECC Root CA – G3.
  • Verify that your browsers and Java runtimes have applied the latest trust store updates.
  • If you rely on eMudhra certificates, obtain replacements from the company’s partners.

Market and Regulatory Implications

The incident underscores the importance of secure key-generation practices in the certificate ecosystem. Regulators may scrutinize issuers’ random number generators more closely, and compliance costs could rise as issuers invest in stronger audit trails. The exit of a 1% revenue contributor from eMudhra’s portfolio may prompt other issuers to reassess their market positions.

For live crypto prices, see the live crypto prices.

Further Reading

Explore more on this topic