eMudhra Limited said on October 22, 2026, that its board had decided to voluntarily withdraw from the global SSL/TLS certificate business after the disclosure of weak private keys in eight eMudhra intermediate certificate authorities. The company said it revoked the affected CAs within 14 hours of discovering the issue, while browser vendors moved to block the certificates and customers began migrating an estimated 30,000 certificates.
Key Points
- eMudhra is leaving the global SSL/TLS certificate market and will focus on enterprise solutions and other trust services.
- A researcher found that private keys for eight eMudhra intermediate CAs could be recovered almost instantly.
- Chrome, Firefox, Android and other trust systems blocked the affected certificates without requiring most users to install a browser update.
- About 30,000 certificates require migration, although the companies involved said they found no evidence of exploitation.
- eMudhra said its other services, including digital signatures, eSign and enterprise PKI, are not affected.
How the weak keys were found
On October 17, 2026, a researcher identified in Mozilla’s incident record as Wayne reported that the private keys of eight eMudhra intermediate certificates could be recovered. The researcher provided proof of control for all eight keys and sent the report to Apple, Google, Microsoft, Mozilla and eMudhra. No full name or affiliation has been disclosed.
Mozilla’s incident record says six of the eight certificates were TLS intermediates trusted by the Chrome, Mozilla, Microsoft and Apple root programs. The other two were code-signing certificates trusted by Microsoft.
The eight affected keys were P-384 elliptic-curve private keys generated during a ceremony on April 30, 2025, as part of a batch of 24 intermediates. The batch was organized into series A, B and C, used RSA-4096 or P-384 keys, and covered domain validation, organization validation, extended validation and code-signing purposes. The affected keys were the P-384 keys in series B and C.
Mozilla said the eight private keys were integers smaller than 256. They could be recovered nearly instantly with the baby-step giant-step discrete-log algorithm or by generating the first 256 P-384 keys. Mozilla independently recovered the keys without knowing the original researcher’s method, confirming that the weakness was trivial to exploit.
In its October 21 incident update, eMudhra attributed the problem to a step in the key-generation ceremony. The company said a wrap/unwrap operation produced a second, weak set of keys alongside the original strong keys, and that the weak keys were published to browser root stores even though the keys had been generated on FIPS 140-2 Level 3-certified hardware security modules.
In comments recorded in Mozilla’s incident bug, eMudhra described the ceremony as involving an approved deviation to test a wrap/unwrap operation. The company said a code flaw created a second pair of weaker keys, and similar key labels caused the weaker keys to be used to create the certificate signing requests. eMudhra also said the CSRs were sent to Sectigo for cross-signing.
The affected intermediates were created for European and U.S. operations, including data-sovereignty requirements. eMudhra said seven of the eight were never used in production and that the one deployed intermediate had issued no end-entity certificates. Mozilla said eMudhra told it that the intermediates had not issued certificates beyond OCSP use for one CA, and that one intermediate had been live before being disabled. The two code-signing issuers were not put into production and issued no certificates.
eMudhra said the affected intermediates were created using Utimaco HSMs. It said its RSA issuers followed a different process and were not affected, while its A and A-1 series were created using Entrust HSMs.
eMudhra’s October 21 update said the issue had gone undetected for about 18 months and through two independent audit cycles. The company said it was not aware of evidence that the weak keys had been recovered or exploited before the disclosure.
Browser vendors moved to block the certificates
The researcher said the report and signed attestations were emailed at 18:05 UTC on October 17. Google said the Chrome Root Program received the report at that time. Mozilla said it received the report at 20:06 UTC after it was forwarded by the Chrome Root Program, acknowledged it at 20:08 UTC, verified the proof of key control and began distrusting the certificates in Firefox through OneCRL.
Google said Chrome had corroborated the findings by 19:45 UTC and deployed a CRLSet update that blocked the affected intermediates by their Subject Public Key Info hashes. The update protected Chrome users without requiring a browser update or restart.
Mozilla said it independently recovered the affected private keys at 21:48 UTC. By 22:59 UTC, its OneCRL update had reached Firefox users with standard configurations without requiring users to update or restart Firefox.
eMudhra said it revoked all eight intermediates on October 18. Mozilla’s incident record says the revocations were recorded on eMudhra’s certificate revocation list between 09:24 and 09:38 UTC that day.
Mozilla issued Firefox 158.0.1 for desktop and Android, Firefox ESR 115.43.1 and Firefox ESR 153.5.1 to extend protection to users whose custom settings might prevent OneCRL updates. Mozilla also released NSS 3.131.1 to remove the root certificate that signed the affected intermediates, protecting applications that use Mozilla’s trust store but do not receive OneCRL updates. On October 21 at 08:29 UTC, Mozilla released Firefox for Android 158.0.2 to fix an issue that prevented some clients from immediately applying changes to the bundled OneCRL blocklist after startup.
Google said Android devices and Googlebooks received equivalent protection through Google Play Services at about 22:00 UTC on October 19. Google said users could trigger an immediate update by restarting their device.
Certificate impact and customer migration
The affected TLS intermediates sat beneath eMudhra’s emSign ECC Root CA – G3. Mozilla said the root was being removed from trust as a precaution, and eMudhra said browser root programs had distrusted the ECC root.
Google said no TLS certificates chaining to the six affected TLS intermediates had been logged to Certificate Transparency before Chrome blocked them. Google said fraudulent certificates issued by those intermediates therefore could not have been used against clients enforcing Certificate Transparency, including Chrome’s default policy for publicly trusted certificates.
Google said it removed emSign ECC Root CA – G3 from the Chrome Root Store for applications that use that store but do not consume CRLSet updates. The planned removal was expected to reach devices on Tuesday morning, October 27, 2026, Pacific Daylight Time, with earlier availability on prerelease channels such as Chrome Canary and Chrome Beta.
Google warned that legitimate certificates chaining to the root would stop functioning in Chrome after the removal. It instructed affected website operators to immediately acquire and install a new TLS certificate from another PKI hierarchy included in the Chrome Root Store. Google also said it had reviewed other keys in its root stores and found no other keys sharing the same weak-entropy failure mode. It coordinated with browser vendors, root-store operators and software maintainers, and worked to ensure that Certificate Transparency logs rejected certificates chaining to the compromised CAs.
Mozilla said it was not removing trust in eMudhra’s emSign Root CA – G1 at the time of its incident update.
Mozilla’s incident record cited Certificate Transparency data dated October 21, 2026, showing approximately 30,800 unexpired precertificates chained to emSign ECC Root CA – G3. It said 30,791, or 99.9%, had been issued through two Internet2/InCommon subordinate CAs: 23,806 through InCommon Intermediate CA – OVG3C and 6,985 through InCommon Intermediate CA – DVG3C. The record said 18 were issued by eMudhra intermediates, excluding precertificates logged after October 17 under the compromised EM DV TLS CA G3B.
eMudhra estimated that about 30,000 certificates required migration and said about 97% had been issued through ACME. Mozilla noted that standard ACME clients do not replace certificates outside their normal renewal window unless they support ACME Renewal Information or receive manual intervention. Mozilla also said that changing from an ECC hierarchy to an RSA hierarchy might require client-configuration changes.
Why eMudhra is leaving the market
eMudhra said global SSL/TLS accounted for about 1% of its global revenue. The company cited increasing data-sovereignty and compliance requirements, rising complexity and costs, and competition from large providers that issue SSL/TLS certificates free of charge. It also cited social-media scrutiny that it considered disproportionate to the business’s role in its portfolio. eMudhra described it as “scrutiny that is out of proportion to SSL/TLS’s place in our business.”
The board’s decision followed the weak-key disclosure, but eMudhra said the global SSL/TLS business was being exited as part of a broader focus on enterprise solutions and trust services other than SSL/TLS.
In its announcement, eMudhra said:
“Our G1 RSA roots will continue to serve customers until this transition is complete as we work with browser programs and our customers to enable this transition.”
eMudhra
eMudhra said its G1 RSA roots would continue serving customers during the transition. The company said it would work with browser programs and customers, offer affected customers replacement certificates free through partners, and keep revocation and certificate-status services running until all issued certificates had expired or been replaced.
On October 22, eMudhra said it was making certificates issued by Sectigo available as an alternative to all customers. Customers could request them through CertiNext, eMudhra support or CertiNext U.S. support if they were in the United States. In its October 21 update, the company also said it was offering every enterprise TLS customer certificates from an additional publicly trusted CA as a redundancy measure and was reviewing its key-generation ceremonies and operational controls.
eMudhra said its global SSL/TLS infrastructure operates separately from its other operations. It said digital signature certificates, eSign, enterprise PKI solutions including emCA and CertiNext, emSigner, SecurePass and emAS were unaffected and would continue operating. The browser blocks, revocations and customer migration work remain in place while the company completes the SSL/TLS exit.
Sources
About the Author
