eMudhra quits global TLS certificate market after compromise of CA signing keys
if ( !emtpy($headline_subheadline ) ) : ?>
Security experts urge organizations to review certificate dependencies beyond browsers as trust-store changes take effect.
eMudhra quits global TLS certificate market after compromise of CA signing keys
if ( !emtpy($headline_subheadline ) ) : ?>
Security experts urge organizations to review certificate dependencies beyond browsers as trust-store changes take effect.
endif; ?>
Credit: Funtap / Shutterstock
Indian digital trust company eMudhra has announced that it is exiting the global SSL/TLS certificate business and is offering customers certificates issued by Sectigo as an alternative, following the compromise of private keys behind eight of its intermediate certificate authorities.
The company’s board decided “to voluntarily withdraw from the global SSL/TLS certificate business,” eMudhra said in a press note. It added that data sovereignty and compliance requirements had increased the business’s complexity and cost.
“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,” eMudhra Chairman V Srinivasan said in the announcement.
The company said it will contact affected customers to replace certificates free of cost. It also said it will keep revocation and certificate status services running until every issued certificate has expired or been replaced.
Sectigo offered as an alternative
In the customer update, eMudhra said it is making Sectigo-issued certificates available to all its customers.
“Our G1 root certificates remain active and continue to be fully supported,” the company said in the update. The October 22 release said the G1 RSA roots “will continue to serve customers until this transition is complete.”
eMudhra said it would provide replacement certificates free of charge through its partners and continue operating revocation and certificate-status services until all certificates it issued had expired or been replaced. CertiNext users can request Sectigo certificates through their accounts; other customers can contact eMudhra support, the statement added.
Niyati Daftary, principal analyst at Gartner, said organizations should view the G1 roots “as a possible bridge, not automatically as the final destination.”
“With the company exiting global SSL/TLS and its remaining roots still subject to browser scrutiny, the prudent course is to move critical services to an independent, fully trusted CA wherever the deadline allows,” Daftary said.
If G1 is used to prevent an immediate outage, she recommended setting a firm deadline and documenting a subsequent migration plan.
She recommended including issuing authorities, intermediate and root certificates, cross-signing arrangements, revocation infrastructure, and browser trust status in third-party risk assessments.
Yash Kadakia, co-founder and CTO of Security Brigade, said that moving to another root operated by the same company does not necessarily address concerns over trust and governance.
“The last thing organisations need is to migrate twice,” Kadakia said.
Sectigo did not immediately respond to a request for comment.
Java and other systems may need separate fixes
Replacing a website’s certificate may not address every dependency in an enterprise environment, according to Sakshi Grover, research director at IDC. She said residual exposure lies in systems that maintain their own trust stores and do not update on the same schedule as browsers. These include Java keystores, language runtimes, container images, mutual TLS 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, referring to where certificate trust decisions are made outside browsers and operating systems.
Grover noted that Google reported finding no certificates chaining to the affected intermediates in Certificate Transparency logs before they were blocked. She said that was reassuring for clients that enforce Certificate Transparency, but some non-browser applications and devices do not. Exploitation would also require an attacker to be positioned to intercept traffic, she said, describing the remaining risk as limited and targeted rather than broad.
Azul, a Java vendor, said in a statement that Java does not check certificate revocation by default. An unpatched Java Development Kit (JDK) could therefore continue to accept a forged certificate signed with a compromised intermediate key if the relevant chain remains trusted.
Azul said it released updated Azul Zulu Builds of OpenJDK and Azul Prime. The updates add the eight affected certificates to the JDK’s blocked-certificate list, the company said.
Grover recommended that security teams first identify where trust decisions occur outside browsers and operating systems, prioritising systems that accept connections from external parties and mutual TLS endpoints. Teams should then determine which systems can be updated to distrust a specific intermediate certificate or public key, she said.
Chrome deadline for certificate holders
Mozilla has removed emSign ECC Root CA – G3, the root that signed the eight compromised intermediates, from its trust store. Google said in a blog post that 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 the post.
Daftary said enterprises often know their certificate reseller but not the CA hierarchy underpinning their trust.
“That creates an unrecognized fourth-party risk capable of affecting thousands of services at once,” she said. She added that CISOs should include issuing CAs, roots, cross-signing arrangements, and revocation infrastructure in their third-party cyber risk assessments. “You can outsource a service, but you cannot outsource accountability,” Kadakia said.
Browser SecuritySecurityBrowsers
About Author
