Were eMudhra intermediate CA keys stolen in a breach?

eMudhra reported that the keys were cryptographically weak (insufficient entropy from a key ceremony), not that production infrastructure was hacked. The weak keys were recoverable from the public certificates. eMudhra said no certificates had been issued from the affected intermediates.

How do I check if my website is affected?

Inspect your TLS certificate chain for the compromised eMudhra intermediates listed at emudhra.we-have-a-problem.com, or run a Lordevo Security Safe Scan which compares chain SPKIs against that set.

What should I do if my certificate is affected?

Replace the certificate with one from a currently trusted CA hierarchy, and keep client trust stores updated. Do not disable TLS verification.

eMudhra Compromised CA Certificates (Oct 2026): What Site Owners Should Do

Last updated: 22 October 2026 · Current status: Mitigated

Browsers and root programs have blocked the eight affected intermediates and eMudhra revoked them. Sites whose certificate still chains through one need a replacement certificate.

We re-check this status every day against our knowledge base and the CISA Known Exploited Vulnerabilities catalog (last check 25 Oct 2026, 01:39 UTC).

What happened

An independent researcher reported that private keys for eight eMudhra intermediate CAs (under eMudhra’s ECC / emSign hierarchy used for global TLS) had insufficient entropy from a key generation ceremony (April 2025). Anyone who recovered those keys could forge certificates trusted by clients that still trusted those intermediates.

eMudhra stated that its infrastructure was not breached, that no certificates had been issued from the affected intermediates, and that its India DSC / eSign businesses were separate and unaffected. Browser and root programs moved quickly to block the compromised intermediates (and in some cases distrust related roots). Downstream trust stores (OS packages, language runtimes, cloud clients) needed updates because many non-browser clients do not consume fast revocation channels like CRLSets.

Who should care

Site owners whose TLS certificate chains through an affected eMudhra / emSign intermediate or the impacted root hierarchy — you may need a replacement certificate from a still-trusted hierarchy.
Operators of TLS clients (servers that call APIs, IoT, language runtimes, containers) — update CA bundles so you no longer trust the compromised intermediates.

If your public site certificate is from another CA (Let’s Encrypt, DigiCert, Google Trust Services, etc.) and your chain does not include those intermediates, your server certificate is not “issued by the weak keys” — but you should still keep client trust stores updated.

How to check

Inspect your live certificate chain (browser padlock → certificate details, or openssl s_client -connect your.host:443 -servername your.host).
See whether any intermediate matches the compromised set published at emudhra.we-have-a-problem.com.
Run our free Safe Scan: we compare the presented chain’s subject-public-key hashes against the eight compromised intermediate SPKIs and note related emSign/eMudhra roots in a “recent threats” section.

Check my certificate chain (Safe Scan) Order Deep Scan

How to fix / mitigate

If your site certificate chains to an affected hierarchy: re-issue from a currently trusted CA hierarchy and install the new chain.
Update browsers, OS CA packages, language runtimes (e.g. Node, Go, Java, Python certifi) and tunnel/VPN clients per vendor advisories.
Do not “fix” certificate errors by disabling TLS verification.

What our scanner reports

Safe Scan and the Deep Scan baseline flag a fail if your chain includes one of the eight compromised intermediate SPKIs, or a warn/info if an emSign/eMudhra root appears so you can double-check. The report’s recent-threats section documents this October 2026 incident with references.

References

Scans require authorization. See terms.

eMudhra compromised intermediate CA certificates (October 2026)