Keys to the Kingdom: The eMudhra Weak-Key Compromise

Eight eMudhra intermediate CAs were compromised by predictable ECDSA keys, making private-key recovery possible from public certificates.

In October 2026, researchers discovered that eight eMudhra intermediate certificate authorities had dangerously weak ECDSA P-384 private keys. The keys could be recovered from publicly available certificates with negligible computational effort, potentially enabling fraudulent TLS certificate issuance and code signing.

The affected intermediates belonged to the emSign certificate hierarchy, which had been trusted by major browsers and operating systems. Six intermediates were associated with TLS issuance and two with code signing.

All eight intermediates were revoked, and vendors introduced distrust measures across their platforms. eMudhra subsequently announced plans to wind down its publicly trusted TLS certificate business.

The failure was in key generation, not ECDSA itself. The result was a set of trusted certificate authorities whose private keys could be recovered from public data. 

The weakness dates back to a key-generation ceremony on April 30, 2025. According to eMudhra’s account to Mozilla, a change to the usual ceremony procedure introduced a key wrap/unwrap step. A flaw in the script generated a second, weak set of keys, and the wrong keys were used to create the certificate signing requests. eMudhra later acknowledged that a script error caused the incident. A full root-cause analysis was still pending.

The keys were generated using FIPS 140-2 Level 3-certified hardware security modules (HSMs). Despite these safeguards, the affected hierarchy passed two audit cycles before the weakness was discovered. Questions have since been raised about why the weak keys and earlier certificate-revocation-list signature failures were not detected sooner.

For ECDSA P-384, the private scalar should be selected unpredictably from a range containing approximately 2³⁸⁴ possible values. The eight affected scalars were 4, 56, 66, 115, 155, 156, 230, and 237.

Because every value was smaller than 256, recovering the private keys was trivial. Researchers could generate the first 256 candidate public keys and compare them with the public keys in the affected certificates. Mozilla independently reproduced the recovery using this approach and a discrete-logarithm technique.

No access to eMudhra’s internal systems or HSMs was required. Public certificate data was sufficient to recover the keys.

This was not a break of ECDSA or the P-384 curve. It was a failure of key generation that eliminated the unpredictability on which the algorithm’s security depends.

An intermediate CA sits between a trusted root and the certificates it issues. If its private key is compromised, an attacker may be able to issue certificates that clients trust.

• TLS impersonation: The six TLS intermediates could be used to create certificates for arbitrary domains. Intercepting traffic would still require an opportunity to redirect or intercept a victim’s connection, and the victim’s client would need to accept the fraudulent chain. Certificate Transparency policies may provide an additional layer of defence.
• Code-signing abuse: The two code-signing intermediates could be used to sign software that appears to come from a trusted publisher. This is a potential impact, not evidence that malicious signing occurred.
• Wider trust disruption: Distrusting the affected hierarchy can break legitimate services, including those whose certificates were not issued using the compromised keys.

Mozilla’s Certificate Transparency analysis identified approximately 30,800 unexpired precertificates chaining to the emSign ECC Root CA – G3 hierarchy. Of these, 30,791 were associated with two InCommon subordinate CAs.

These figures describe the broader impact of distrusting the hierarchy, not certificates issued by eMudhra using the eight compromised keys. eMudhra stated that the affected intermediates had not issued any end-entity certificates themselves.

However, subsequent analysis in Mozilla’s incident tracker documented 107,107 certificates signed with six of the compromised keys and logged to Certificate Transparency logs between October 20 and 21, 2026. This included 106,050 proof-of-concept certificates for google.com, as well as certificates for other domains. These findings demonstrate that the recovered keys were used to sign certificates after disclosure; they do not, by themselves, establish successful real-world impersonation of those domains.

For additional analysis, see Mozilla’s incident tracker, Palo Alto Networks Unit 42 and The Hacker News’ technical coverage.

Although the eMudhra incident originated from a certificate-authority key-generation failure rather than a vulnerability in a specific software product, its impact extended to applications, runtimes, and infrastructure that relied on the affected certificate chains.

Several vendors assigned CVE identifiers to track the resulting trust and certificate-validation issues, while others used them to document product-specific remediation.

Recovering these keys from public certificates does not necessarily leave evidence of the recovery in eMudhra’s systems. Defenders should focus on identifying affected certificate chains, checking which systems still trust them, and looking for signs of suspicious certificate issuance or use. 

On Linux systems using the conventional CA certificate directories, these commands provide an initial search:

ls /etc/ssl/certs | grep -i emsign

grep -i emsign /etc/ca-certificates.conf

These searches are indicative, not conclusive. Certificate filenames may not contain the issuer’s name, and /etc/ca-certificates.conf lists distribution-managed CA certificates rather than every certificate an application might trust. A missing match does not prove that the affected hierarchy is distrusted.

To search the macOS system-root keychain for certificates matching emSign, run:

security find-certificate -a -c emSign \

  /System/Library/Keychains/SystemRootCertificates.keychain

This only examines the specified keychain. Apple warns that some command-line tools, including curl, git, python3, and openssl, can use /etc/ssl/cert.pem and may continue accepting affected chains even when Apple’s networking frameworks block them.

Consult Apple’s security advisory before modifying trust configuration. Manually removing root certificates can also affect unrelated services that depend on them.

To test a server connection using OpenSSL’s configured trust sources, run:

openssl s_client \

  -connect HOST:443 \

  -servername HOST \

  -verify_return_error </dev/null

Replace HOST with the target’s hostname. Check the verification result and any reported certificate errors.

This tests the certificate chain presented by that server against OpenSSL’s configured trust sources. It does not establish whether every application on the host rejects the affected hierarchy. For a meaningful assessment, test the actual certificate chain and trust configuration used by the application under investigation.

The incident disclosure also provides proof material, test endpoints, and certificate chains for further investigation.

Additional defensive checks

• Certificate inventory: Identify certificates and services that depend on the compromised intermediates or the distrusted emSign ECC Root CA – G3 hierarchy.
• Certificate Transparency: Monitor CT logs for unexpected certificates issued for organizational domains. Investigate unfamiliar issuers and unauthorized issuance.
• Revocation validation: Review CRL and OCSP handling, including whether applications correctly validate revocation information and how they respond when it is unavailable or invalid.
• Application-specific trust stores: Assess containers, runtimes, browsers, and command-line applications that maintain their own CA bundles or use different validation mechanisms.

No single command proves that an environment is fully remediated. Confirm that the relevant applications reject the affected chains and that replacement certificates are trusted by the clients that use them.

• Replace affected certificates and verify the complete chain. Identify services that depend on the compromised intermediates or the distrusted emSign ECC Root CA – G3 hierarchy. Reissue affected certificates through an unaffected, trusted issuer. eMudhra has offered Sectigo-issued certificates as an alternative; other issuers may be suitable depending on the deployment. Verify the replacement chain against the trust stores used by your clients.
• Apply vendor trust updates. Update operating systems and browsers, and follow the relevant vendor guidance. Do not manually restore trust in removed roots without a documented security assessment. Root removal can affect unrelated certificates, so assess potential compatibility issues before making local trust changes.
• Patch applications with independent certificate-validation logic. Go released fixes for this incident in versions 1.26.10 and 1.27.3, blocking certificates chaining to the compromised intermediates. Upgrade to an applicable patched release and rebuild or redeploy applications that bundle their own Go runtime. See the Go incident response.
• For CVE-2026-114406, install the applicable distribution-specific ca-certificates security update. Consult your Linux vendor’s advisory, such as Red Hat RHSA-2026:88459, rather than assuming a single package version applies across distributions.
• Manage certificate replacement proactively. Do not rely solely on scheduled renewal to replace affected certificates. Initiate reissuance when necessary, account for compatibility requirements if changing from an ECC to an RSA chain, and confirm that the replacement certificate is deployed and accepted by the clients that use the service.
• Verify remediation at the application level. Updating an operating system does not guarantee that every browser, runtime, container, or command-line tool has stopped trusting the affected hierarchy. Test the actual trust configuration used by critical applications and confirm that replacement chains validate successfully.

• April 30, 2025: The affected intermediates were created during a key-generation ceremony.
• October 17, 2026: Mozilla received the report of the compromised private keys and began blocking the affected certificates in Firefox.
• October 18, 2026: eMudhra revoked all eight affected intermediates.
• October 19, 2026: Apple began blocking the affected TLS intermediate certificates.
• October 20, 2026: Microsoft published a Windows Disallowed Certificate Trust List update to block the affected certificate authorities.
• October 22, 2026: eMudhra announced plans to exit the publicly trusted global TLS certificate business.
• October 23, 2026: Apple began blocking the emSign ECC Root CA – G3.
• October 26, 2026: Microsoft released a Windows update removing seven certificates associated with the affected hierarchies.
• October 27, 2026: Microsoft scheduled the corresponding removal from the Microsoft Edge trust list.
• October 28, 2026: eMudhra updated its incident statement with further information on customer migration and its planned wind-down.

Trust-store changes do not reach every device or application simultaneously. Organizations should verify their own environments rather than assume that a published release date means remediation is complete.

For vendor-specific details, consult the Mozilla Security Blog, Microsoft’s response, Apple’s advisory, and eMudhra’s incident updates.

The eMudhra incident highlights the importance of understanding cryptography, secure key generation, and certificate validation. 

You can practice exploiting this vulnerability in a controlled environment through the OffSec lab: eMudhra Compromise – available in OffSec’s Offensive Cyber Range, exclusive to Learn Enterprise subscriptions. 

The following OffSec resources provide relevant background: