eMudhra Exits Global TLS Certificates After CA Key Compromise

eMudhra’s exit from the global SSL/TLS certificate business turns a certificate authority compromise into a broader migration challenge: replacing a website certificate may leave trust decisions in enterprise software and devices untouched. The company says it will provide free replacement certificates through Sectigo and maintain status services while its issued certificates remain active.

A transition with a defined support window

eMudhra’s board chose to withdraw from global SSL/TLS, citing rising complexity and costs tied to data sovereignty and compliance requirements. Chairman V Srinivasan said the incident’s social media attention had drawn scrutiny disproportionate to TLS’s role in the company’s business.

The company plans to contact affected customers and replace certificates at no charge. CertiNext customers can request Sectigo certificates through their accounts; other customers can contact eMudhra support. eMudhra says revocation and certificate status services will continue until every certificate it issued has expired or been replaced.

Its G1 RSA roots remain active during the transition. Gartner principal analyst Niyati Daftary advises treating them as a temporary bridge, since those roots remain subject to browser scrutiny. Where G1 prevents an immediate outage, she recommends setting a firm migration deadline and documenting the next step to an independent, fully trusted certificate authority.

Security Brigade co-founder and CTO Yash Kadakia cautioned that moving to another root operated by the same company may leave trust and governance concerns unresolved. “The last thing organisations need is to migrate twice,” he said. Sectigo had not responded to a request for comment.

Trust stores extend beyond browsers

Replacing a public-facing certificate can miss systems that maintain their own certificate stores or receive updates on different schedules. IDC research director Sakshi Grover pointed to Java keystores, language runtimes, container images, mutual TLS configurations, proxies, load balancers, VPN and security appliances, and embedded devices. Security teams may first need to map where these systems make trust decisions, especially for connections from external parties and mutual TLS endpoints.

Google reported that it found no certificates chaining to the affected intermediates in Certificate Transparency logs before blocking them. Grover said that offers reassurance for clients that enforce Certificate Transparency, while some applications and devices do not. Exploitation would also require an attacker positioned to intercept traffic, making the remaining risk limited and targeted, she said.

Java presents a specific complication: Azul says Java doesn’t check certificate revocation by default. An unpatched Java Development Kit could therefore continue to trust a forged certificate signed with a compromised intermediate key if the certificate chain remains trusted. Azul released updates to Azul Zulu Builds of OpenJDK and Azul Prime that add the eight affected certificates to the JDK’s blocked-certificate list.

Grover recommends identifying systems that can be updated to reject a particular intermediate certificate or public key, then prioritizing exposed systems and mutual TLS endpoints. The practical test for many organizations, she said, may be whether they can identify where certificate trust is enforced at all.

Browser changes create a deadline

Mozilla removed emSign ECC Root CA – G3, which signed the eight compromised intermediates, from its trust store. Google said Chrome’s removal of the root was expected to reach all devices on the morning of October 27, Pacific time. Google urged website operators with certificates chaining to that root to acquire and install replacements immediately to avoid service breakage.

Daftary said organizations may know their certificate reseller without knowing the certificate authority hierarchy behind it. That gap can create “an unrecognized fourth-party risk” affecting many services at once. She recommends including issuing authorities, root certificates, cross-signing arrangements, and revocation infrastructure in cyber risk assessments. Kadakia’s point is direct: “You can outsource a service, but you cannot outsource accountability.”