About 30,000 TLS certificates face move after weak CA keys
TLS certificates covering about 30,000 websites need to be moved after eight intermediate certificate authority keys were found to be easily guessable. eMudhra's board has decided to withdraw from the global Secure Sockets Layer and Transport Layer Security (SSL/TLS) certificate business, which provides the digital credentials browsers use to establish trusted, encrypted website connections.
A researcher reported recovering the private keys for eight eMudhra intermediate certificate authority (CA) certificates on October 17. An intermediate CA sits between a trusted root and the website certificates issued beneath it. Its private key is the secret value used to sign certificates and related records. According to the report, each of the eight values was below 256, rather than being a very large random number, making them almost immediately discoverable. Six of the eight intermediates were intended for TLS certificates.
The researcher notified Apple, Google, Microsoft, Mozilla and eMudhra. Chrome and Firefox blocked the six TLS intermediates within hours. Google said no website certificate issued from those intermediates had appeared in public Certificate Transparency (CT) logs before Chrome acted. CT logs are public records of issued website certificates, and software that requires certificates to appear in them therefore could not have accepted certificates from those intermediates before the block. eMudhra said the eight intermediates had never issued certificates to websites or users, and said its systems had not been breached.
The wider impact comes from browser action against emSign ECC Root CA - G3, the trusted root above the affected intermediates. Mozilla decided on October 20 to stop trusting that root in Firefox. Chrome's removal is expected to reach users on the morning of October 27, Pacific time. Removing a root also invalidates otherwise legitimate TLS certificates that lead back to it, so website operators must replace those credentials even if their own systems were not compromised.
Chrome counted about 30,800 unexpired certificates connected to the root in public CT logs as of October 21. It said 99.9% had been issued through InCommon, the certificate service created by Internet2 for the higher education community. InCommon transferred that service to eMudhra's CertiNext platform between April and July. Google has instructed affected operators to obtain and install a new TLS certificate from a different public key infrastructure hierarchy that remains in the Chrome Root Store.
eMudhra estimated that about 30,000 certificates must move and said roughly 97% were issued through Automated Certificate Management Environment (ACME), a protocol that servers use to request and renew certificates automatically. Chrome warned that ordinary ACME clients generally will not replace a certificate before its normal renewal window unless they support ACME Renewal Information (ARI), or an administrator intervenes manually. Moving from the affected ECC hierarchy to the separate RSA hierarchy may also require changes to client settings.
Cornell advised its certificate holders to request RSA certificates because those currently use eMudhra's unaffected root. The university identified more than 300 affected certificates of its own. The University of Michigan likewise said InCommon RSA certificates were not currently affected, while cautioning that their root could also lose trust. It identified Let's Encrypt as its main alternative for now.
The separate G1 RSA hierarchy will continue serving customers during the transition. Mozilla said on October 20 that it was not, at that point, removing emSign Root CA - G1. Chrome was still considering whether eMudhra's remaining CA certificates should stay in its root store. At Stanford, InCommon certificates connect to G1 through an eMudhra authority named emSign Root TLS CA - G1.
Questions have also emerged over a certificate revocation list (CRL) published for emSign Root TLS CA - G1 on October 14. A CRL is a CA-signed record of certificates that are no longer valid. The researcher said in Mozilla's public incident report that this list's signature could not be verified with the CA's own key. Another participant reported on October 22 that it appeared to have been signed using an eMudhra Online Certificate Status Protocol (OCSP) certificate, which normally signs responses about whether individual certificates have been revoked. That participant assessed the mismatch as an apparent use of the wrong signing key, rather than evidence of another weak key.
Chrome raised the invalid list among 12 questions posted on October 21. It asked which key signed the list, whether eMudhra maintained multiple key pairs for that CA or any root, where customers were being moved and when the migration would finish. eMudhra had said on October 20 that G1 was the only available alternative, then said the following day that affected US customers were receiving new certificates from another independently operated, publicly trusted CA hierarchy.
The questions also revisit six invalid CRLs eMudhra published for the same intermediates in 2025. Its incident report at the time said the lists had been regenerated using the appropriate private key for each intermediate CA. On October 19, eMudhra told Mozilla that the lists had initially been signed with the intended keys, but were later signed again using the flawed keys after the first signatures proved invalid. Chrome said this raised serious concerns about the transparency and handling of the 2025 incident, including why the earlier report had not disclosed two key pairs for each affected CA. As of 13:31 UTC on Thursday, eMudhra had not publicly answered Chrome's questions in the bug report, and its most recent visible comment was dated October 20.
eMudhra said affected customers would receive free replacement certificates from partners, but did not identify those partners or set an exit date. It will operate revocation and status services until every SSL/TLS certificate it issued has either expired or been replaced. The announcement did not say whether new certificates would continue to be issued through G1 during the withdrawal. Its digital signature certificate, eSign and CertiNext operations will continue.
The company said global SSL/TLS services represent about 1% of its revenue. It cited the cost and complexity of data sovereignty and compliance requirements, competition from large providers offering free certificates, and scrutiny following the incident as factors surrounding its exit.
Website owners should identify who issued every active TLS certificate, confirm which root it uses and replace affected credentials rather than waiting for an automated renewal. For WordPress operators reviewing certificate changes alongside their hosting security, AEU Hosting provides managed WordPress hosting secured end to end.