Daniel Nashed's Blog

eMudhra CA Key Compromise – Why This Is a Serious Security Issue

On October 17, 2026, a serious security issue involving eight eMudhra intermediate Certificate Authorities (CAs) was reported.
The private signing keys of these CAs were generated with extremely weak randomness and can be recovered from publicly available information.

This means anyone who knows these keys can issue certificates for virtually any domain, not just domains previously using eMudhra certificates.

An attacker able to intercept network traffic could present a forged certificate for a legitimate website or API endpoint.
A vulnerable TLS client might accept that certificate as trusted, allowing the attacker to impersonate the server and potentially read or modify encrypted traffic.


Why Revoking Existing Certificates Is Not Enough

The compromised intermediate CA certificates have been revoked. However, revocation only protects clients that actually check and enforce it.
Many TLS implementations do not check certificate revocation by default. They validate the certificate chain against trusted root certificates but may never discover that an intermediate CA has been revoked.

As long as a client continues to trust the affected certificate chains without effective revocation checks, newly forged certificates can still be accepted.


What Administrators Should Do

There are two important actions:

1. Update trust stores and remove trust in the affected CA chains. This includes operating systems, applications, runtimes and containers. Removing an entire root CA may be necessary where more targeted distrust mechanisms are unavailable.
2. Verify certificate revocation handling. Ensure applications enforce revocation or another reliable mechanism for rejecting compromised CA certificates. Do not assume that certificate chain validation alone is sufficient.

Where to Check

• Browsers: Chrome, Firefox, Edge and Safari have already deployed protections.
• Operating systems: Windows, Linux and macOS trust stores need to be considered.
• Mobile devices: Android and iOS have received protections, but application-specific TLS implementations may behave differently.
• Applications: Java, OpenSSL, Go, Python and other runtimes may use independent certificate stores or verification mechanisms.
• Containers: Updating the host does not automatically update certificate bundles inside container images.

What About HCL Domino?

Domino administrators need to consider multiple certificate stores:

• cacerts.pem in notesdata directory: Contains affected trust anchors and needs to be reviewed and updated.
• Java cacerts: The bundled JVM uses a separate certificate trust store. Its contents and revocation behavior need to be verified for the specific Domino release.
• Domino Directory: The standard Domino Directory does not contain these public CA roots by default.
• Operating system: Linux and Windows certificate stores may be used by other applications and components running alongside Domino.
• certstore.nsf: Only contains Let's Encrypt roots by default and would only need to be checked if you added those roots

Updating one trust store does not necessarily protect applications using another.

How Can You Test Your Systems?

Dennis Jackson has published an excellent resource explaining the incident, providing cryptographic proof of the compromised keys and offering live tests for TLS clients.

https://emudhra.we-have-a-problem.com/


The tests can help determine whether a particular TLS client still accepts certificates issued through the compromised CA chains.
A successful test with your browser or curl does not automatically mean that other applications on the same machine are protected.

The most important lesson: Trusting a root CA without reliable revocation handling means trusting every certificate that can be issued through its subordinate CAs — including certificates signed with compromised keys.

Maybe we should start looking into the CA bundles we trust more closely. That's probably something to look at after this is resolved.
A while ago I looked into the list of root certs in trust stores. Usually vendors use the trust stores of the security stack they use (libcurl, JVM, etc).

• Comments [1]