eMudhra Exits Global SSL/TLS Business Amid Certificate Security Concerns

All eight private keys were below 256, so anyone could work them out almost instantly.

eMudhra's board decision and customer-facing commitments

eMudhra's board has decided to withdraw the company from its global SSL/TLS certificate business, a move announced five days after a researcher reported recoverable private keys for eight of its intermediate CA certificates. The company said it will replace affected customers' certificates with free ones from partners, but its announcement did not name the partners or set a date for the exit.

eMudhra said it never used the eight weak keys to issue certificates to websites or users and that its systems were not breached. It also said it will keep revocation and status services running "until every SSL/TLS certificate it issued has expired or been replaced." The company added that its other businesses — digital signature certificates, eSign, and the CertiNext platform used by InCommon — will continue.

Browser responses: Chrome's planned distrust and Mozilla's removal

Chrome will stop trusting the eMudhra ECC root certificate, emSign ECC Root CA - G3, and that change is expected to reach users on the morning of October 27, Pacific time. Google has told website operators they "must immediately acquire and install a new TLS certificate from another PKI hierarchy included in the Chrome Root Store." Mozilla decided on October 20 to stop trusting the same root in Firefox.

Chrome and Firefox blocked the six TLS intermediates within hours of the disclosure. Google noted that "no website certificate from them had appeared in CT logs before Chrome's block, so none could have been used against Chrome or other software that requires CT logging."

Scope of the impact: InCommon, higher education, and automated renewals

Chrome's count of public Certificate Transparency logs showed about 30,800 unexpired certificates chained to the ECC root as of October 21. Of those, 99.9% were issued through InCommon, the certificate service Internet2 created for the higher education community. InCommon moved the service onto eMudhra's CertiNext platform between April and July of this year.

eMudhra estimated roughly 30,000 certificates need to be moved and said about 97% of them were issued using ACME, the protocol many servers use to request and renew certificates automatically. Chrome warned that standard ACME clients do not replace certificates outside their renewal window unless they support ACME Renewal Information (ARI) or someone steps in manually. Moving from the ECC hierarchy to the RSA hierarchy may also require changes to client settings.

Individual institutions have begun advising customers: Cornell told its certificate holders to request RSA certificates instead of ECC ones because "RSA certificates use eMudhra's unaffected root and should work." The university reported more than 300 affected certificates of its own. The University of Michigan said InCommon's RSA certificates are not currently affected but warned that their root "could become distrusted, too," and noted that its main alternative for now is Let's Encrypt.

Questions about the RSA (G1) root and past CRL problems

Mozilla said on October 20 that it was not removing trust in the G1 root, emSign Root CA - G1, for now. Some customers' chains — for example, Stanford's InCommon certificates — link to that root through an eMudhra CA named emSign Root TLS CA - G1.

Trouble with certificate revocation lists (CRLs) has deepened scrutiny. On October 14, eMudhra published a CRL for emSign Root TLS CA - G1 whose signature "does not verify against that CA's own key," the researcher reported in Mozilla's public bug. A participant in the same bug report said the list appears to have been signed with the key of an eMudhra OCSP certificate and that the match "appears to be a case of using the wrong signing key, rather than evidence of another weak key."

Chrome raised that CRL on October 21 as one of 12 questions in the public bug report, asking which key signed it and whether eMudhra holds more than one key pair for that CA or for any of its roots. Chrome also asked whether customers are moving to G1, to another company's CA, or both, and when all of them will have moved given Chrome's planned October 27 removal.

eMudhra told Chrome on October 20 that G1 was "the only alternative available," and the following day said it is issuing affected U.S. customers fresh certificates "from an alternate, independently operated, publicly trusted CA hierarchy." The record shows that in 2025 eMudhra previously published invalid CRLs for six of the same intermediates and said it fixed them by "regenerating the CRLs using the appropriate private key associated with each Intermediate CA."

As of 13:31 UTC on Thursday, eMudhra had not answered Chrome's questions publicly on the bug report; its last visible comment there was posted on October 20.

How technologists, InCommon/higher education operators, and browser vendors are responding

• Technologists and security teams: They are racing to replace roughly 30,000 certificates, often constrained by ACME client behavior and renewal windows; Cornell recommends switching to RSA certificates tied to eMudhra's G1 root where feasible.
• InCommon and higher-education IT operators: Institutions that moved to CertiNext this year now account for the bulk of affected certs; universities are both tracking replacements (Cornell reported 300+ affected certs) and planning fallbacks such as Let's Encrypt where RSA options are not viable.
• Browser vendors and platform operators: Chrome has set an aggressive trust-removal timetable (expected Oct 27 Pacific) and publicly posed detailed questions about key management and past CRL handling; Mozilla has already removed trust for the ECC root and is for now retaining trust in the G1 root.

eMudhra characterized the global SSL/TLS business as bringing in about 1% of its revenue, citing data-sovereignty and compliance costs and noting that some large providers give certificates away free. The company also said that the incident's spread on social media has brought "scrutiny that is out of proportion to SSL/TLS’s place in our business." What remains concrete is the clock: Chrome's planned distrust on October 27 and unanswered technical questions on the public bug report leave certificate holders and browsers aligned on one urgent point—replacement must happen now, and clarity from eMudhra on key management and migration timelines remains outstanding.

Original report — The Hacker News