eMudhra CA keys compromised, triggering urgent browser and runtime fixes

Mozilla and Google’s Chrome Root Program confirmed on October 20 that the private keys for eight eMudhra intermediate certificate authority certificates have been compromised. This critical security incident prompted immediate emergency fixes across major web browsers and software runtimes to prevent potential man-in-the-middle attacks. The compromise was reported by a researcher on October 17, leading to rapid blocking actions by Chrome and Firefox within hours of verification.

What happened

The core of this incident involves the theft or unauthorized access of private keys belonging to eMudhra, an Indian certificate authority that issues digital certificates under the emSign brand. These specific keys belong to intermediate certificates, which are used to sign end-entity certificates for websites and software. Possession of these private keys allows an attacker to issue valid TLS certificates for any domain, which browsers would normally trust as legitimate. The compromise affects six intermediates used for TLS encryption and two used for code signing, spanning domain validated, organization validated, and extended validation certificate types.

A security researcher, identified only as Wayne, reported the issue to root program operators on the evening of October 17. Wayne demonstrated possession of the keys by signing a message with each of the eight compromised private keys. Chrome verified the findings and implemented a block via its CRLSet mechanism by 19:45 UTC on October 17. Mozilla followed suit, pushing a OneCRL block to Firefox installations by 22:59 UTC that same day. These mechanisms allow browsers to revoke trust in specific certificates without requiring a full software update or restart. Apple blocked the certificates on October 19, and Microsoft followed on October 20.

Crucially, no TLS certificates chaining to the six affected web intermediates had been logged to Certificate Transparency logs before Chrome implemented its block. This suggests that while the keys were compromised, they may not have been used to issue fraudulent certificates that were publicly visible and trusted by default in Chrome. However, it remains unknown how the keys were exfiltrated, when the breach occurred, or if other actors besides the reporting researcher possess them. Go, the programming language, also released urgent security updates on October 20 to reject chains containing these keys, treating the issue with maximum severity due to the potential threat to ecosystem integrity.

Key details

• Eight eMudhra intermediate CA private keys were compromised, affecting both TLS and code-signing certificates.
• Chrome and Firefox blocked the certificates within hours of the report on October 17, using CRLSet and OneCRL respectively.
• No fraudulent TLS certificates chaining to the affected intermediates were found in Certificate Transparency logs prior to the block.
• Go released versions 1.27.3 and 1.26.10 on October 20 to hard-reject these keys, requiring developers to rebuild their applications.
• Mozilla removed the emSign ECC Root CA - G3 from its NSS trust store, which may cause connectivity issues for servers still using this root.
• Python’s certifi bundle and Rust’s webpki-roots have updated to drop the affected root, requiring package updates for backend services.

Background

To understand the severity, it is necessary to distinguish between root and intermediate certificates. A root certificate is the ultimate anchor of trust in a browser or operating system. Intermediate certificates act as bridges, signed by the root, which then sign the actual certificates used by websites. This hierarchy allows CAs to keep their highly sensitive root keys offline and secure. When an intermediate key is compromised, as in this case, the damage is contained more easily than a root compromise, but it still allows attackers to impersonate any website trusted by that intermediate.

Certificate Transparency (CT) is a public ledger system that records all issued TLS certificates. It serves as an audit trail, allowing domain owners and browsers to detect misissued certificates. The fact that no CT logs existed for the compromised eMudhra intermediates before the block is a positive sign, indicating that large-scale misuse may have been prevented or went undetected by public monitoring. However, many backend systems and older clients do not strictly enforce CT logging or check revocation lists like CRLSet, making them vulnerable until their trust stores are explicitly updated.

Why it matters

For teams running self-hosted software, this incident highlights the fragility of implicit trust in third-party certificate authorities. While web browsers receive automatic revocation updates, many server-side applications, internal tools, and microservices rely on static trust bundles or system-level certificate stores that do not update automatically. For example, Python applications using the certifi bundle or Go binaries compiled with older versions will continue to trust the compromised keys until the underlying libraries are updated and the application is redeployed. This creates a window of vulnerability for internal APIs and service-to-service communication that relies on TLS mutual authentication.

Furthermore, the removal of the emSign ECC Root CA - G3 from trust stores like Mozilla’s NSS and Python’s certifi means that any legitimate services still using certificates chained to this root will suddenly become unreachable. This is not just a security fix but a potential availability incident. DevOps engineers must verify if any of their external dependencies or partner integrations use eMudhra certificates. If so, those connections will fail until the remote party reissues their certificates under a different, trusted root. This underscores the need for active monitoring of certificate validity and issuer changes, rather than assuming set-and-forget reliability.

What you can do

• Update all Go installations to version 1.27.3 or 1.26.10 immediately and rebuild any affected binaries to ensure the new rejection logic is active.
• Check your Python environments and update the certifi package to version 2026.10.19 or later to remove the untrusted root from your bundle.
• Audit your server logs for any connections to services using eMudhra certificates, as these may now fail due to root removal in updated trust stores.
• Verify that your internal monitoring systems are checking for certificate issuer changes, not just expiry dates, to detect similar migrations or compromises early.
• Ensure your Firefox installations are updated to version 158.0.1, ESR 115.43.1, or ESR 153.5.1 if they cannot receive Remote Settings updates automatically.
• Review your dependency management for Rust and Node.js projects, watching for pending updates to webpki-roots and Node.js itself that address this compromise.