eMudhra Exits Global TLS Market After Key Compromise
Indian digital trust company eMudhra is leaving the global SSL/TLS certificate business after private keys behind eight intermediate CAs were compromised. Customers are being offered certificates from Sectigo as a replacement, and the window for acting is short: Google expects the removal of the root that signed the compromised intermediates to reach all Chrome devices by the morning of , Pacific time.

The decision to withdraw was made voluntarily by eMudhra’s board, according to a company press note. Chairman V Srinivasan said social media amplification around the incident brought disproportionate scrutiny to the SSL/TLS business, and that data sovereignty and compliance requirements had already added complexity and cost.

Mozilla has already removed emSign ECC Root CA, G3 from its trust store. That root signed the eight compromised intermediates. Google has told website operators to acquire and install a new TLS certificate immediately to avoid service disruption.

Free Replacements, With the G1 Roots as a Stopgap

eMudhra says it will contact affected customers and replace their certificates at no cost. It will also keep its revocation and certificate status services running until every issued certificate has either expired or been replaced. CertiNext users can get Sectigo certificates through their accounts, while other customers should contact eMudhra support. According to an release, the company’s G1 root certificates stay active and fully supported during the transition.

Outside analysts are not treating that as a clean fix. Gartner principal analyst Niyati Daftary sees the G1 roots as a temporary bridge and advises moving critical services to an independent, fully trusted CA wherever deadlines allow. Anyone who does lean on the G1 roots, she says, should document the follow-up migration plan to avoid an outage later.

Yash Kadakia, co-founder and CTO of Security Brigade, questioned the idea of moving to another root run by the same company. In his view that does not necessarily address the underlying trust and governance concerns, and he warned against migrating twice if the new setup proves insufficient.

The Trust Stores Browsers Will Not Warn You About

Swapping the certificate on a public website does not cover everything. Sakshi Grover, research director at IDC, pointed to leftover exposure in systems that keep their own trust stores, and noted that many organizations struggle to find where trust decisions are made outside the browser. The usual places include:

  • Java keystores
  • Language runtimes
  • Container images
  • VPN appliances

Java is a live example. Java vendor Azul confirmed that Java does not check certificate revocation by default, which could let unpatched JDKs accept forged certificates. Azul has released updated Azul Zulu Builds of OpenJDK and Azul Prime that add the eight affected certificates to the JDK’s blocked list.

Hashlytics Take

The press note leans on cost and social media scrutiny, but the sequence of events says otherwise. A key compromise behind eight intermediates is what ended this business, and the root that signed them is already out of Mozilla and on its way out of Chrome. The more useful detail sits in the Java findings. eMudhra is keeping revocation services alive, yet Java does not check revocation by default, so that promise does nothing for the systems most likely to be forgotten. Chrome’s cutoff on October 27 will fail loudly and get fixed fast. A JDK quietly accepting a forged certificate will not, which makes the unlisted trust store the real deadline for most teams.

Follow Hashlytics on Bluesky, Facebook, LinkedIn , Telegram and X to Get Instant Updates