The eMudhra SSL certificate trust removal requires operators to replace any certificate chain ending at emSign ECC Root CA – G3. Google scheduled Chrome’s removal for the morning of October 27, 2026, Pacific time, while Apple began blocking the root on October 23, 2026. Check every public TLS endpoint, install a chain under a trusted root, and test it externally.
Why is Chrome removing trust in the eMudhra root?
Chrome is removing emSign ECC Root CA – G3 because the root signed a hierarchy containing compromised eMudhra intermediate certificate authority keys. Google scheduled the root’s removal from the Chrome Root Store for October 27, 2026, after blocking the affected intermediate keys through CRLSet on October 17, 2026.
The eMudhra SSL certificate trust removal followed a report that private keys for eight intermediate CA certificates were recoverable because the keys had insufficient randomness. According to Google’s October 2026 security notice, six intermediates were used for TLS and two for code signing.
An intermediate certificate authority is a CA that signs certificates beneath a trusted root, creating a verifiable path between a website certificate and the root stored by a browser or operating system. Possession of one of the six TLS intermediate keys could have allowed an attacker to create apparently valid certificates for arbitrary websites on clients that had not blocked the key.
Google said in October 2026 that no publicly trusted end-entity TLS certificates had been issued from those six compromised intermediates before the block. The danger was the exposed signing capability, not evidence of widespread forged website certificates.
eMudhra revoked all eight intermediates within approximately 14 hours during October 17–18, 2026. The weak keys belonged to intermediate CAs rather than the root itself, but Google removed emSign ECC Root CA – G3 as a precaution because it anchored the compromised hierarchy.
Are all 30,800 affected certificates forged?
No. The approximately 30,800 unexpired certificates or precertificates identified through Certificate Transparency on October 21, 2026, were legitimate certificates chaining to emSign ECC Root CA – G3. Mozilla’s incident analysis did not classify those certificates as forgeries; root distrust made their trust path the operational problem.
The distinction matters. A compromised signing key creates the capability to forge certificates, while a legitimate certificate can become unusable simply because browsers stop trusting a root elsewhere in its chain. Treating every affected certificate as malicious overstates the incident and can distract from the replacement work.
| Certificate path or group | Reported count | What the count means |
|---|---|---|
| InCommon Intermediate CA – OVG3C | 23,806 | Legitimate certificates associated with an Internet2/InCommon subordinate CA |
| InCommon Intermediate CA – DVG3C | 6,985 | Legitimate certificates associated with an Internet2/InCommon subordinate CA |
| Two InCommon intermediates combined | 30,791 | Certificates requiring migration from the affected root path |
| eMudhra-operated intermediates | 18 | Additional certificates reported in the Certificate Transparency review |
| Rounded affected population | Approximately 30,800 | Unexpired certificates or precertificates chaining to the distrusted root |
The two displayed subtotals, 30,791 and 18, add up to 30,809. That exceeds the rounded “approximately 30,800” headline figure, so you shouldn’t force the published values into a falsely exact total. Mozilla’s October 2026 discussion also reported eMudhra’s estimate that about 97% of roughly 30,000 certificates had been issued through ACME.
That concentration explains why university and research networks using Internet2/InCommon deserve particular attention. A large certificate count under two subordinate CAs doesn’t mean thousands of independent compromises occurred. It means one trust decision can have broad downstream effects.
How do you check for an affected eMudhra certificate chain?
Check an eMudhra certificate chain by inspecting what the live server sends, searching the issuer path for “emSign” or “eMudhra,” and identifying the terminal trust anchor. A chain ending at emSign ECC Root CA – G3 is affected by the October 2026 distrust even when the leaf certificate remains unexpired.
SSL.com’s October 2026 guidance recommends querying the endpoint with openssl s_client -connect hostname:443 -servername hostname -showcerts. Replace both instances of hostname with the real DNS name. Server Name Indication matters because a shared IP address may return a default certificate when -servername is omitted.
Read the returned certificates in order and examine each subject and issuer. Don’t stop after checking the leaf. The eMudhra SSL certificate trust removal concerns the certification path, so an ordinary-looking domain certificate can still fail when the server supplies an affected intermediate or the client builds toward the removed root.
One commonly missed pitfall is testing only the main website. Inventory API hostnames, authentication portals, CDN origins, mail services, load balancers, gateways, staging systems, container ingress points and vendor-managed endpoints. Operators responding to other urgent issues, such as an actively exploitable GitLab vulnerability, already know that forgotten secondary services often extend incident cleanup.
How do you replace an affected certificate before distrust?
Replace an affected certificate by obtaining a new leaf certificate that chains to a currently trusted hierarchy, installing the complete intended intermediate chain, and deploying it to every TLS termination point. eMudhra began offering Sectigo-issued replacements through CertiNext or eMudhra support on October 22, 2026.
The following October 2026 remediation sequence covers the failure points most likely to leave a hostname broken:
- Inventory every website, API, CDN, load balancer, mail server, gateway, container ingress and other public TLS endpoint.
- Inspect each live path and flag chains containing eMudhra, emSign or emSign ECC Root CA – G3.
- Request a replacement certificate from a CA whose chain remains trusted by your required browsers, operating systems and application runtimes.
- Install the new leaf certificate and complete intermediate bundle at every termination layer, including vendor-managed edges.
- Force or reconfigure ACME issuance when the normal renewal date falls after the October 2026 distrust deadline.
- Retest each hostname from outside your network and confirm the chain received by current clients.
ACME automation is not proof of safety. Mozilla’s October 2026 incident discussion explicitly warned operators not to assume a normal renewal schedule would replace the affected path in time. Force renewal where needed, then inspect the resulting chain rather than trusting a successful job log.
A concrete calculation shows the risk: a 90-day certificate with 45 days remaining and an ACME client configured to renew at 30 days remaining won’t attempt routine renewal for another 15 days. If root distrust arrives today, automation is working exactly as configured while the site still fails today.
Honestly, replacing only the public web server is a poor shortcut. Certificate deployment resembles broader emergency response work: the inventory discipline used for unpatched backup-server incidents also applies to TLS endpoints hidden behind proxies and gateways.
How can you verify the replacement really works?
Verify the eMudhra replacement by testing every public hostname from an external network, confirming the server sends the intended intermediates, and connecting with current Chrome and other major clients. Google’s October 2026 guidance also calls for updating runtimes, base images and applications that maintain independent certificate trust stores.
Start with another openssl s_client query against the live endpoint, not a local certificate file. Confirm the old eMudhra path is absent and that the server supplies the necessary intermediate certificates. Then use current browser releases and representative operating systems from outside the corporate network.
Apple adds an awkward edge case. Apple reported on October 23, 2026, that some macOS command-line tools, including curl, git, Python, Ruby, Perl and OpenSSL, could continue using /etc/ssl/cert.pem until a future software update, independently of Apple’s platform block. A successful curl request therefore may not prove that Safari or another platform-trust client will accept the same chain.
Apple began blocking 12 certificates representing the six TLS intermediate keys under eMudhra and Sectigo paths on October 19, 2026, then blocked emSign ECC Root CA – G3 on October 23, 2026. Mixed results across applications are plausible because browsers, operating systems and bundled runtimes can consult different trust stores.
Record the hostname, observed chain, client version, operating system and test time for each result. That evidence is far more useful than a screenshot saying “works for me,” especially when a security team is also tracking browser-specific trust risks such as Chrome extension trust failures.
What does eMudhra’s exit from global SSL/TLS mean?
eMudhra’s board decided on October 22, 2026, to leave the global SSL/TLS certificate business. eMudhra said its G1 RSA roots would continue operating during migration, while revocation and certificate-status services would remain available until issued certificates expire or customers replace them.
The company reported that global SSL/TLS represented approximately 1% of its global revenue in 2026. On October 26, 2026, eMudhra acknowledged that its own script error caused the weak-key incident, apologized, and said an independent expert review and a full Common CA Database root-cause report would follow.
According to eMudhra’s account, the eight intermediate CAs originated during an April 30, 2025 key-generation ceremony. A wrap/unwrap script error created a second set of weak keys, and that set was mistakenly used for certificate-signing requests.
The eMudhra SSL certificate trust removal doesn’t automatically mean every G1 RSA certificate fails on October 27, 2026. Trust depends on the exact path a client builds. Still, eMudhra’s business exit makes planned migration more sensible than waiting for the final day of each certificate’s validity.
FAQ about the eMudhra certificate incident
Was the eMudhra root private key compromised?
The emSign ECC Root CA – G3 private key was not reported compromised in October 2026. The recoverable keys belonged to eight intermediate CAs, while the root was removed because it anchored the affected hierarchy.
Will an unexpired eMudhra certificate still show a warning?
An unexpired certificate can show a warning when its chain ends at emSign ECC Root CA – G3 after a client removes trust. Certificate validity dates do not override a browser’s root-store decision.
Does revoking the intermediates fix existing websites?
Revocation of the eight intermediate certificates on October 18, 2026, reduced abuse risk but did not migrate legitimate sites away from the distrusted root. Affected operators still need a replacement chain under a trusted hierarchy.
Can a successful OpenSSL test prove Chrome will work?
An OpenSSL success does not guarantee Chrome acceptance because OpenSSL and Chrome may use different trust stores and path-building rules. Test the live hostname with current Chrome after confirming the certificate chain at the command line.