The eMudhra CA key compromise involves eight intermediate certificate authority (CA) certificates whose private keys were weak enough to be recovered from the public certificates. eMudhra has revoked all eight. The entire software industry is responding by issuing updates to reflect the revocation of the affected certificates, and major trust store operators are blocking and removing the affected root.
This is not the first time an incident of this nature has happened, and it won’t be the last one. The investigation is ongoing, so details may change as eMudhra and trust store operators publish more.
What happened with eMudhra’s intermediate CAs?
eMudhra describes itself as a global digital trust company and operates as a certificate authority (CA). As of October 2026, eMudhra had roots included in the Mozilla, Chrome, Apple and Microsoft root programs. A researcher found that eight eMudhra intermediate CA keys could be recovered from public data. Trust store operators such as browsers, operating systems and libraries blocked them, and eMudhra revoked all eight.
Weak keys in intermediate CAs
According to Mozilla incident bug 2083449, six of the compromised certificates were for TLS and two were for code signing. The bug reports that the two code signing CAs are trusted by Microsoft. Apple’s support note confirms the same split.
What caused the weak keys?
eMudhra attributes the weak keys to a flaw in its April 2025 key-generation process. In its comment on the incident bug, eMudhra describes a script flaw during the key ceremony. It adds that a weaker key pair was used by mistake to create the certificate signing request.
eMudhra’s incident statement says it hasn’t yet confirmed the exact root cause, so this account is preliminary. Its October 22 press release states that the company will deliver a full root-cause report to the browser root programs.
How did the software industry respond?
The industry blocked the affected intermediates within hours and days of the eMudhra CA key compromise report. Updates went out to browsers, operating systems, and language runtimes.
eMudhra itself reports having revoked the affected CAs within 14 hours of discovery. The incident bug records the revocations on October 18, and eMudhra’s statement says none of the eight issued end-entity certificates. Sectigo also revoked its cross-signed certificates following the release of the bug.
According to Google, Chrome blocked the affected keys less than two hours after the report was published. Mozilla also published its own steps to protect Firefox users.
The Go project released Go 1.27.3 and 1.26.10 to block trust in a small set of intermediate certificates. Python’s certifi package removed emSign roots in version 2026.10.19, and its maintainers later narrowed that removal.
Google found no certificates from the six TLS intermediates in public Certificate Transparency (CT) logs before its October 17 block. That finding covers only that period and doesn’t establish whether the keys were used elsewhere.
As of October 21, CERT-In reported that public disclosures did not establish confirmed malicious use of the keys. Since then, a comment on the incident bug reports about 107,000 certificates signed with the six TLS intermediates. Most were proof-of-concept certificates logged to CT on October 20 and 21.
The silver lining
There is a light shining through the cracks. It’s encouraging to witness how quickly the software industry handled this. In our view, response speed has improved by orders of magnitude since a decade ago, and recent industry work is paying off.
We’ll never be free of vulnerabilities, and incidents such as this one will happen again. Response speed makes a great difference and the good news is that response is getting faster, as methods keep improving year over year.
What changes in browser and platform trust?
Trust stores are dropping the root that signed the affected intermediates. eMudhra is also leaving the global SSL/TLS certificate business.
Removal of emSign ECC Root CA – G3
Several trust stores have removed or blocked the root CA that the compromised certificates chain to, emSign ECC Root CA – G3. The list includes Mozilla, Chrome, Apple, Ubuntu, Python, among others.
As warn by CERT-In, removal from browser and application trust stores makes these certificates under that root untrusted. Google advises website operators to install a new TLS certificate from another PKI hierarchy that is listed among the trusted in the Chrome Root Store.
eMudhra’s exit from the global SSL/TLS business
On October 22, 2026, eMudhra announced that its board had decided to withdraw from the global SSL/TLS certificate business. According to eMudhra’s announcement, its G1 RSA roots will remain in service during the transition.
eMudhra says revocation and certificate status services will keep running until every issued certificate has expired or been replaced. It also plans to contact affected customers about replacement certificates from partners, at no cost.
Who is affected by the eMudhra CA key compromise?
The eMudhra CA key compromise directly affects organizations with TLS or code signing certificates chaining to the affected root.
Browsers that enforce Certificate Transparency
CT-enforcing clients such as Chrome, some Apple platforms and Android apps, accept a certificate only if it appears in CT logs. According to Google, no TLS certificates chaining to the six intermediates were logged before its October 17 block. Therefore, none could have been used against CT-enforcing clients during that period, which began when the intermediates were created in April 2025. Certificates logged after the block, including the proof-of-concept certificates, fall outside that finding.
Clients outside the CT ecosystem
Command-line tools, language runtimes, libraries, and anything that ships its own CA bundle are harder to assess. For these clients lack the assurance that no certificates were created using the weak private keys. They will accept a certificate that was never logged, so a forged certificate could have been used against them without leaving a public trace. While there is no evidence that this occurred, it also can’t be ruled out.
A disclosure site run by a Mozilla engineer notes that many non-browser clients, including curl, OpenSSL, Python, Golang, etc, generally don’t enforce CT. Apple says that macOS command-line tools reading /etc/ssl/cert.pem don’t check its block or revocation status.
Mozilla also notes that many endpoints lack effective ways to get revocation information.
Exposure for these clients depends on five factors:
- Whether the client’s trust store held emSign ECC Root CA – G3
- Whether an attacker could get between the client and the server
- Which direction trust runs, such as a client validating a server or a server validating a client
- Whether the software has received the fix and the fix blocks the CAs
- Whether revocation is checked
Each organization has to judge from its own use case whether reviewing 18 months of logs is worthwhile.
What should you do right now about the eMudhra CA key compromise?
Software and trust store updates will keep arriving, and it’s necessary to watch for and apply them. But these updates only protect you going forward; they say nothing about what may have happened in the past. They also cover only the trust stores an organization knows it has. That’s why the first step is an inventory: find every certificate and trust store in your environment, then update each one.
Find every certificate and application that depends on the affected chain
Your eMudhra CA key compromise response starts here. Inventory public and trust stores across internal systems, load balancers, and devices. Look for chains that include emSign ECC Root CA – G3 or the eight intermediates, and record each system’s owner.
Also check applications that validate code signatures or pin specific CAs. Certificate management tools that discover certificates across CAs and endpoints shorten this search.
Update separate trust stores
Patch your systems, and be thorough. Browser fixes for the eMudhra CA key compromise don’t reach every trust store, so check these:
- Operating system trust stores on servers, desktops, and mobile devices
- Java keystores and runtime CA bundles
- Python, Go, and other language runtimes with their own bundles
- Network appliances, proxies, and load balancers
- Custom application trust stores and container base images
Clients that rely on a static CA bundle and do not check revocation remain exposed until their trust store is updated.
Replace certificates that chain to the affected root before October 27
Reissue every TLS certificate that chains to any eMudhra root CA from an alternative CA before root removals and expirations reach users. Google advises website operators to do this immediately.
Keep watching for updates
This story is still developing. Follow announcements from browser vendors, root programs, and eMudhra, including its root-cause report.
Lessons for long-term PKI resilience
Incidents like this reward three capabilities: visibility into certificate dependencies, automated replacement, and ability to change CAs. This isn’t the first mass revocation or the first CA exit from TLS, and it won’t be the last.
The eMudhra CA key compromise is one more reason to build them, whichever CAs you use.
Visibility into certificate dependencies
For self-managed systems, you need visibility into trust stores as well as certificates, plus automation to update them. Don’t rely on default trust store bundles for internal systems. Use explicit trust anchors limited to the CAs those systems need.
How can you avoid CA lock-in?
When an incident like this forces a root out of the major trust stores, the organizations that recover fastest are the ones that already know where every certificate lives and can change where certificates come from without rebuilding their processes. That starts with sound certificate management: a complete, continuously updated inventory of certificates across your environment, with clear ownership and policy for each. If certificates, automation and policies are tied to a single CA, switching means reworking each integration by hand. Maintaining relationships with more than one CA, and managing certificates through a CA-agnostic layer, lets you move issuance when a root’s trust status changes.
Keyfactor Command discovers, manages, and automates certificates from public, private, and cloud-based CAs from one console. That means a CA change doesn’t require rebuilding your renewal processes.
Automating replacement at scale
Replacing hundreds of certificates under a fixed deadline requires automated issuance and deployment through protocols such as ACME.
The same capabilities support broader cryptographic change, including responding to unexpected vulnerabilities found in libraries or cryptographic schemes, or the inevitable move to post-quantum cryptography (PQC). Our crypto-agility guide covers that transition.
To see how Keyfactor finds certificate dependencies and automates replacement, Request a Demo.
Frequently asked questions
Got questions about eMudhra CA key compromise? We’ve got answers.
Subscribe to The Source
Stay secure with Keyfactor's monthly newsletter, packed with expert insights and practical steps for quantum-readiness.
