eMudhra exits global TLS certificate market after signing-key compromise

eMudhra will exit the global SSL/TLS certificate business after attackers compromised private keys behind eight of its intermediate certificate authorities. The Indian digital trust company announced the withdrawal on October 22 and will offer customers certificates issued by rival CA Sectigo as a replacement.

The company's board decided "to voluntarily withdraw from the global SSL/TLS certificate business," eMudhra said in a press note. It cited rising complexity and cost driven by data sovereignty and compliance requirements. Chairman V Srinivasan pushed back on the reaction to the breach. "The level of social media amplification around this incident has brought scrutiny that is out of proportion to SSL/TLS's place in our business," Srinivasan said.

What happens to existing certificates?

eMudhra will contact affected customers and replace certificates free of cost through its partners. Revocation and certificate-status services (the online checks that tell clients whether a certificate remains valid) will keep running until every issued certificate has expired or been replaced.

"Our G1 root certificates remain active and continue to be fully supported," the company said in its customer update. The October 22 release said the G1 RSA roots "will continue to serve customers until this transition is complete." CertiNext users can request Sectigo certificates through their accounts; other customers must contact eMudhra support. Sectigo did not immediately respond to a request for comment.

Is the G1 root a safe bridge?

Niyati Daftary, principal analyst at Gartner, advised treating the G1 roots "as a possible bridge, not automatically as the final destination." She said the prudent course is to move critical services to an independent, fully trusted CA wherever the deadline allows, given that the remaining roots remain subject to browser scrutiny. If enterprises use G1 to prevent an immediate outage, she recommended setting a firm deadline and documenting a migration plan.

Yash Kadakia, co-founder and CTO of Security Brigade, warned that moving to another root run by the same company does not necessarily fix trust and governance concerns. "The last thing organisations need is to migrate twice," Kadakia said.

Why do Java and other systems need separate fixes?

Sakshi Grover, research director at IDC, said residual exposure lies in systems that keep their own trust stores and do not update on the browser schedule. The list includes Java keystores, language runtimes, container images, mutual TLS (mTLS) configurations, proxies, load balancers, VPN and security appliances, and embedded devices. "The harder finding for many organizations will be that they can't answer these questions at all," Grover said.

Grover noted Google found no certificates chaining to the affected intermediates in Certificate Transparency logs (the public audit records of issued TLS certificates) before the block. That reassures clients enforcing Certificate Transparency, but some non-browser applications and devices do not. Exploitation would still require an attacker positioned to intercept traffic, she said, calling the remaining risk limited and targeted rather than broad.

Java vendor Azul said Java does not check certificate revocation by default. An unpatched JDK could therefore continue to accept a forged certificate signed with a compromised intermediate key if the chain remains trusted. Azul has released updated Azul Zulu Builds of OpenJDK and Azul Prime, adding the eight affected certificates to the JDK's blocked-certificate list.

Grover recommended that security teams first map where trust decisions occur outside browsers and operating systems. They should prioritize systems accepting external connections and mutual TLS endpoints, then determine which systems can be updated to distrust a specific intermediate certificate or public key.

What is the Chrome deadline?

Mozilla has already removed emSign ECC Root CA – G3, the root that signed the eight compromised intermediates, from its trust store. Google said the root's removal from the Chrome Root Store is expected to reach all devices on the morning of October 27, Pacific time.

"To avoid breakage, website operators with certificates chaining to emSign ECC Root CA – G3 must immediately acquire and install a new TLS certificate," Google said in a blog post.

Daftary said enterprises often know their certificate reseller but not the CA hierarchy beneath it. "That creates an unrecognized fourth-party risk capable of affecting thousands of services at once," she said. She urged CISOs to include issuing CAs, roots, cross-signing arrangements and revocation infrastructure in third-party cyber risk assessments.

"You can outsource a service, but you cannot outsource accountability," Kadakia said.