eMudhra to Exit Global SSL/TLS Certificate Business After Weak CA Private Keys Discovered

Indian certificate authority eMudhra has decided to withdraw from the global SSL/TLS certificate business following the discovery that private keys belonging to eight of its intermediate certificate authorities could be recovered. The decision, announced on October 22, 2026, comes as major browser vendors move to distrust affected certificate infrastructure.

The incident has triggered changes to browser trust policies and raised questions about the company's certificate management and incident response practices. eMudhra said it would provide affected customers with replacement certificates through partner providers at no cost, although it has not announced a definitive exit date or identified all replacement partners.

The company stated that its global SSL/TLS business contributes approximately 1% of its revenue. It cited the growing complexity and cost of data sovereignty and compliance requirements, competition from providers offering free certificates, and the scrutiny generated by the incident as reasons for its decision.

Weak Private Keys Trigger Browser Distrust

On October 17, a researcher reported recovering the private keys associated with eight eMudhra intermediate certificate authorities to Apple, Google, Microsoft, Mozilla, and eMudhra.

The keys were expected to contain large, unpredictable random values. Instead, all eight were smaller than 256, making them recoverable almost immediately.

Six of the affected intermediate certificates were used for website TLS certificates. Google Chrome and Mozilla Firefox moved to block the six intermediates within hours of the disclosure.

Chrome is also preparing to distrust the associated root certificate, emSign ECC Root CA - G3, with the change expected to reach users on the morning of October 27, Pacific time. Mozilla announced on October 20 that it would stop trusting the same root in Firefox.

Removing a root certificate from a browser's trusted store affects legitimate certificates that depend on that root, not just certificates potentially associated with malicious activity.

According to figures cited in the incident discussion, approximately 30,800 unexpired certificates chained to the affected root remained as of October 21. Around 99.9% were issued through InCommon, a certificate service created by Internet2 for the higher education community. InCommon moved the service to eMudhra's CertiNext platform between April and July 2026.

Google has instructed affected website operators to obtain and install replacement TLS certificates from another publicly trusted certificate authority hierarchy included in Chrome's Root Store.

eMudhra Says the Weak Keys Were Not Used to Issue Certificates

eMudhra stated that it had not used the eight affected intermediate certificates to issue certificates to websites or users and that its systems had not been breached.

Google also noted that no website certificates issued through the six affected TLS intermediates had appeared in public Certificate Transparency logs before Chrome blocked them. As a result, Google said, those certificates could not have been used against Chrome or other software that requires Certificate Transparency logging.

Nevertheless, the discovery of recoverable CA private keys created a serious trust issue because control of a certificate authority's signing key can undermine the integrity of certificates issued under that authority.

eMudhra said its G1 RSA root certificates would continue serving customers during the transition. The RSA hierarchy is separate from the affected ECC root, but Chrome is still evaluating whether to retain eMudhra's remaining certificate authorities in its root store.

The company also said its certificate revocation and status services would remain operational until every SSL/TLS certificate it had issued had expired or been replaced. Its other businesses, including digital signature certificates, eSign services, and the CertiNext platform used by InCommon, are expected to continue.

The announcement did not specifically address InCommon's future arrangements or clarify whether eMudhra would continue issuing new certificates under its G1 hierarchy until its global SSL/TLS exit is complete.

What Affected Certificate Holders Should Do

Google has urged operators with certificates chaining to the affected ECC root to replace them immediately with certificates from another trusted public key infrastructure hierarchy.

Universities and other organizations have begun issuing guidance to their certificate holders.

Cornell University advised affected users to request RSA certificates instead of ECC certificates, explaining that RSA certificates use an unaffected root and should continue to work. The university reported having more than 300 affected certificates.

The University of Michigan stated that InCommon's RSA certificates were not currently affected, while cautioning that their root could potentially face distrust in the future. Its recommended alternative includes Let's Encrypt.

eMudhra has estimated that approximately 30,000 certificates need to be migrated, with roughly 97% issued through ACME, the protocol widely used to automate certificate issuance and renewal.

However, automated renewal does not necessarily guarantee an immediate replacement. Google has warned that standard ACME clients may not replace certificates outside their normal renewal windows unless they support ACME Renewal Information (ARI) or an administrator intervenes manually.

Moving from the affected ECC hierarchy to an RSA hierarchy may also require changes to certificate-client configuration.

Organizations should inventory their certificates, identify the issuing CA and root chain, obtain replacements from a currently trusted hierarchy, and verify that the new certificates are installed and served correctly.

Questions About eMudhra's Remaining RSA Certificate Infrastructure

Although Mozilla has not announced the removal of trust in eMudhra's G1 root, emSign Root CA - G1, questions have emerged about the handling of certificate revocation lists associated with the company's remaining infrastructure.

InCommon certificates used at institutions such as Stanford chain to the G1 root through an eMudhra CA called emSign Root TLS CA - G1.

On October 14, eMudhra published a certificate revocation list (CRL) for emSign Root TLS CA - G1. A CRL identifies certificates that a certificate authority has revoked.

The researcher who reported the weak keys said the CRL's signature did not verify against the relevant CA's own key. During the subsequent public discussion, a participant suggested that the list appeared to have been signed using the key of an eMudhra Online Certificate Status Protocol (OCSP) certificate, which is used to sign responses about certificate revocation status.

That participant said the evidence appeared more consistent with the use of an incorrect signing key than with the discovery of another weak key.

Google raised questions about the CRL on October 21, asking which key had signed it and whether eMudhra maintained multiple key pairs for the affected CA or any of its roots.

The company also asked how customers were transitioning to replacement infrastructure, whether they were moving to G1 or another provider, and when the migration would be completed ahead of Chrome's planned October 27 distrust date.

eMudhra previously described G1 as its only available alternative. It later stated that it was issuing fresh certificates to affected U.S. customers through an alternate, independently operated, publicly trusted CA hierarchy.

Earlier CRL Incident Raises Additional Concerns

The current incident has also brought renewed attention to a certificate revocation list issue reported in 2025 involving six of the same intermediate authorities.

In its earlier incident report, eMudhra said it corrected invalid CRLs by regenerating them using the appropriate private key for each intermediate CA.

On October 19, 2026, the company told Mozilla that the original lists had initially been signed with the keys it intended to use. After those signatures proved invalid, the lists were reportedly signed again using flawed keys that were subsequently recovered by the researcher.

Google said this disclosure raised serious concerns about eMudhra's transparency and incident handling, particularly because the 2025 report had not mentioned that two key pairs existed for each of the affected certificate authorities.

As of 13:31 UTC on October 22, eMudhra had not publicly answered Google's questions in the Mozilla bug discussion. Its most recent visible comment there was dated October 20.

What Happens Next?

The planned withdrawal marks a major change for eMudhra's global TLS certificate operations, but the immediate priority for website operators is replacing certificates that depend on the affected ECC hierarchy before browser distrust takes effect.

Organizations should not assume that a certificate remains trusted simply because it has not expired. They need to verify the complete certificate chain, confirm the replacement hierarchy is trusted by their target browsers, and check whether automated certificate management will renew or replace certificates in time.

Meanwhile, questions about the remaining G1 infrastructure, the earlier CRL incident, and the company's handling of the recovered keys remain important to the wider trust assessment.

The incident demonstrates how weaknesses in certificate authority private keys can affect thousands of otherwise legitimate websites and organizations. It also underscores the importance of strong key generation, reliable certificate lifecycle management, transparent incident disclosure, and rapid migration plans when browser trust is withdrawn.