eMudhra exits TLS certificates as root programs press for answers

eMudhra is leaving the public TLS certificate business, and the two root programs that tested it most have not accepted its explanation. The Indian trust-services company announced on October 22 that it will withdraw from global SSL/TLS certificates, five days after a researcher reported that eight of its intermediate CA keys were trivially recoverable. We read eMudhra’s press release and incident statements and the public Mozilla incident ticket, including the Chrome and Mozilla replies of October 23. This article covers what eMudhra said, what the root programs answered, what it means for certificate holders and which claims remain unchecked.

What did eMudhra announce?

That its Board “has decided to voluntarily withdraw from the global SSL/TLS certificate business.” The press release gives no exit date. It says:

• G1 RSA roots keep serving customers until the transition is complete, while eMudhra works with browser programs and customers.
• Replacement certificates come free of charge “from partners”. eMudhra says it will contact affected customers. The release does not name the partners.
• Revocation and status services keep running until every issued certificate has expired or been replaced.
• Remaining commitments to the browser root programs will be completed, including a full root-cause report.
• Other businesses are unaffected. eMudhra lists digital signature certificates, eSign and other signing services, its enterprise PKI products (emCA, CertiNext), emSigner and its identity products. It says the global TLS infrastructure runs separately.

Why does eMudhra say it is leaving?

Chairman V. Srinivasan, in the release, gives four reasons: global SSL/TLS contributes about 1% of global revenue, complexity and cost are rising with data sovereignty and compliance requirements, some large entities issue TLS certificates free of cost, and the “social media amplification” around the incident brought “scrutiny that is out of proportion to SSL/TLS’s place in our business.” The release adds that eMudhra handled the incident diligently, revoked the affected CAs “within 14 hours of discovery”, issued no end-entity certificates from them and suffered no infrastructure compromise or data breach.

How did Chrome and Mozilla respond?

Publicly, in Mozilla’s incident ticket, and bluntly. The ticket is the public record for the key compromise.

• October 21, Chrome Root Program: it asked eMudhra a list of questions. It noted that eMudhra’s status page and October 21 press release name neither the distrusted root nor the affected intermediates by name, serial or fingerprint, give no trust-removal timelines and do not tell subscribers how to check whether they are affected. It also said the emsign.com brand redirects to a product page that carries neither document.
• October 23, eMudhra: an eMudhra employee wrote in the ticket that intense social media scrutiny and analysis by investors and customers had made meaningful analysis “pretty much impossible”, that the key ceremony took place on April 30, 2025, and that eMudhra will uphold its disclosure obligations.
• October 23, Chrome Root Program: it replied that scrutiny and investor analysis are “not acceptable explanations” for delayed answers, and called the scrutiny the predictable result of eMudhra’s own failure, intermediate CA keys that anyone could recover. It said it expects eMudhra to prioritize its review.
• October 23, Mozilla Root Program: it said it sent eMudhra questions on October 20 at 20:31 UTC with a 24-hour deadline, that eMudhra asked for another 24 hours after the deadline passed, and that as of Friday it had received no response. It said it shares Chrome’s concerns.

A separate comment on October 22 asked eMudhra to name the replacement partners, the roots the replacements will chain to, the number of certificates to be reissued and the timeline. We saw no answer in the ticket.

What does it mean for certificate holders?

The announcement itself does not change how browsers treat the affected certificates. Mozilla and Chrome blocked the affected intermediates on October 17, and the earlier decision to remove the emSign ECC Root CA - G3 stands, as we reported in our first article. What the exit adds is a promise, with no date, to move customers. If you hold an eMudhra TLS certificate, check which CA issued it, plan a replacement from another CA instead of waiting to be contacted, and update CA bundles on software outside the browser. As we reported earlier from the ticket, about 30,000 certificates needed to move, most issued through ACME, and subscribers were being moved to G1 RSA chains. The exit announcement does not say what happens to those chains after the transition.

Which of eMudhra’s claims can be checked?

Some can be compared with the public record, and the comparison is mixed. Our observations:

• “Within 14 hours of discovery.” The ticket records the researcher’s report at about 18:05 UTC on October 17 and eMudhra’s acknowledgment at about 21:28 UTC. The eight intermediates were revoked on October 18 at about 09:24 to 09:38 UTC. That is roughly 12 hours from acknowledgment and 15.5 hours from the report (our arithmetic), so the figure depends on the starting point.
• No end-entity certificates issued. eMudhra says this in its releases and status page, and says Certificate Transparency records corroborate it. The researcher’s timeline says eMudhra acknowledged on October 17 that an intermediate named EM DV TLS CA - G3C had been live and was then disabled. Live and issuing are not the same, and we did not check Certificate Transparency ourselves.
• How the keys became weak. eMudhra’s status page says a flaw in one step of the key ceremony produced a second, weak set of keys through a wrap and unwrap step, and that the weak keys were the ones published. It says the HSMs were FIPS 140-2 Level 3 certified. The ticket still contains open questions about the exact flaw, and we saw no ceremony script or report published in the ticket, which commenters asked for.
• Audits. The status page says the hierarchy passed two independent audit cycles. A commenter asked whether an earlier compliance bug about invalid CRL signatures on the same intermediates had been disclosed to the auditors. We saw no answer.

What is still unknown?

• The root cause. eMudhra promised a full root-cause report to the root programs, with no date.
• When the exit completes, which partners will take over customers and which roots replacements will chain to.
• Whether eMudhra’s other keys are affected. Mozilla’s earlier analysis could not recover the keys of two older series, and the RSA keys had not been examined.
• Whether anyone used the keys. Nobody had to steal them, and nothing we read answers it.
• How Mozilla and Chrome will treat the remaining G1 RSA roots after the transition.

What to keep in mind

These are our observations:

• A business exit does not end the obligations. eMudhra says it will still deliver the root-cause report, and Mozilla and Chrome are holding it to that publicly.
• The reasons it gives are commercial, the response asked of it is technical. Revenue share and free competitors do not answer what happened in a key ceremony.
• The AI detail is on the record. Mozilla’s Dennis Jackson wrote on October 18 that local agents recovered the keys on their first attempt from a simple capture-the-flag style prompt. The values are one byte, so no AI was needed, but cheap tools make the check routine for anyone.
• Check your own chains. If you rely on eMudhra for certificates, treat the announcement as the start of a migration, not a reassurance.

Editorial review: October 23, 2026 (AI). Prepared from eMudhra’s October 22 and October 21 press releases and its incident statement (all read as page text), and the public Mozilla Bugzilla ticket 2083449 (read through Mozilla’s public API, including comments through October 23, 14:35 UTC). We did not contact eMudhra, Mozilla or Chrome, check Certificate Transparency records, or open the PDF attachments in the ticket. Details of the ticket may have changed after our reading.