eMudhra Certificate Compromise: Browsers Are Protected. Is the Rest of Your Network?

Encryption only protects data when the certificates behind it can be trusted. On October 17th, a security researcher showed that eight intermediate Certificate Authority (CA) certificates belonging to eMudhra — an India-based CA operating under the emSign brand — could not be trusted. The private keys behind the certificates were mathematically defective, allowing anyone to compute them from public data.

Browser makers responded within hours. Most enterprise networks carry far more than browser traffic, however. Backend servers, containers, Internet of Things (IoT) devices, command-line tools and AI agents all establish Transport Layer Security (TLS) connections, and many of them never hear about a revoked certificate. ExtraHop researchers built a detector so RevealX customers can see whether any of those non-browser connections touch a compromised certificate chain.

What happened

eMudhra generated the eight intermediates in a key-generation ceremony on April 30th, 2025. A script error during the ceremony produced a second set of weak keys alongside the intended cryptographically strong keys. Staff selected the weak keys by mistake because their labels looked nearly identical to the labels of the correct keys.

Each weak key is a National Institute of Standards and Technology (NIST) P-384 elliptic-curve private key with a scalar value below 256. A properly generated key is a random number more than 100 digits long. An attacker needs to test at most 256 values to recover each key. Mozilla independently derived all eight keys within hours of the initial report.

The compromised intermediates break down into two categories:

• Six TLS intermediates for domain-validated (DV), organization-validated (OV) and extended-validation (EV) certificates. The G3B intermediates served European operations, and the G3C intermediates served US operations.
• Two code-signing intermediates, EM OV CS CA - G3B and EM OV CS CA - G3C.

eMudhra revoked all eight certificates on October 18th. The weak keys had been recoverable for roughly 17 months before disclosure.

How serious is the risk?

The early forensic evidence is reassuring. eMudhra reported that none of the eight intermediates had issued production end-entity certificates. Google didn’t find any certificates chaining to the six TLS intermediates in Certificate Transparency (CT) logs before Chrome blocked them. Browsers that enforce CT policies could not have trusted a forged certificate by default during that period. To date, no malicious exploitation has been confirmed.

The danger lies in what the derived keys make possible. A forged certificate lets an attacker impersonate a legitimate service, then decrypt, read, or alter encrypted traffic in an Adversary-in-the-Middle (AitM) attack. Exploitation requires two conditions:

1. An attacker who can intercept or redirect the victim's network traffic (via routing or Domain Name System manipulation).
2. A client application that still trusts the compromised certificate chain.

The second condition is where enterprise exposure compounds. Outside the browser, automated workloads and unpatched trust continue to accept revoked authorities without question.

Where trust breaks outside the browser

Chrome and Firefox blocked the certificates on October 17th, and Apple followed on October 19th. On October 20th, Microsoft updated the Windows Disallowed Certificate Trust List to block the affected CAs, pushing a separate block to Edge and WebView2.

Protection across the rest of the software ecosystem remains uneven. Many non-browser clients skip dynamic revocation checks, continuing to trust a chain until someone updates their certificate store or source code:

• Linux servers and containers rely on Operating System (OS)-level CA certificate packages, and container images retain whatever bundle they were built with.
• Embedded and IoT devices often ship with fixed trust stores that update only with firmware.
• Applications with their own trust stores, including Go binaries, Node.js and Python apps using the certificate bundle, accept the chain until a developer updates the runtime and rebuilds.
• Command-line tools such as curl and git on macOS check certificates against /etc/ssl/cert.pem, which skips Apple's block until a future macOS update.
• AI agents and automated workflows call cloud APIs, external microservices, and internal systems directly without a browser interface. An agent's trust decision depends on its runtime TLS library and underlying certificate store. An attacker who intercepts the connection could extract API credentials, inspect sensitive data, or manipulate the tool outputs and prompt instructions that govern automated decisions.

A second problem: legitimate certificates will break

Mozilla removed the parent emSign ECC Root CA - G3 from its trust store, and Google is removing the same root from the Chrome Root Store, with the change reaching devices on October 27th. Microsoft released an out-of-band Windows update on October 26th that removes seven certificates tied to the affected hierarchies — six eMudhra G3 roots and an AAA Certificate Services cross-sign — and plans the same removal for Edge on October 27th. Several Linux distributions dropped the root as well. 

Distrusting the root authority invalidates legitimate customer certificates issued by unaffected sibling intermediates under that hierarchy. Consequently, eMudhra estimates that approximately 30,000 active certificates require replacement.

Following the incident, the company announced on October 22nd that eMudhra will exit the global Secure Sockets Layer/Transport Layer Security (SSL/TLS) business entirely. Services and endpoints that depend on eMudhra’s certificates will fail to establish trust until administrators migrate customer domains to an alternative certificate authority.

Five strategic questions for security leadership

Enterprise defense leads should frame their response around five baseline diagnostics:

1. Which of our systems make TLS connections outside a browser, and who owns their trust stores? Servers, containers, appliances, IoT devices and AI agents all count.
2. Do our internal or customer-facing endpoints present certificates chaining up to emSign ECC Root CA - G3? If so, have migration schedules been finalized before client deprecation deadlines hit?
3. Are our AI agents and automation pipelines running updated TLS libraries or are they executing against static local certificates? An agent that trusts a forged certificate can leak credentials or act on false data.
4. Can we see certificate chains on our network, including inside TLS 1.3? Visibility into the chain shows whether a client ever received a compromised certificate.
5. Would we know if a device accepted a forged certificate? A successful AitM session looks like normal encrypted traffic to most tools.

Steps for practitioners

• Update operating system trust stores. Ubuntu (USN-8944-1 and USN-8944-2) and Debian (DSA-6572-1) shipped updated ca-certificates packages on October 20th. Red Hat rates the issue as “critical” in bulletin RHSB-2026-012 and has released updated ca-certificates packages for RHEL 10 (RHSA-2026:88455), RHEL 9 (RHSA-2026:88459) and RHEL 8 (RHSA-2026:88550). Red Hat also recommends rebuilding customer containers once RHEL and UBI base images are updated.
• Update runtimes and bundled stores, then rebuild. Fixed versions include Go 1.27.3 and 1.26.10, Node.js 26.12.1, 24.22.1 and 22.23.4, Python certifi 2026.10.19 and Rust webpki-roots 1.0.10. Go programs pick up the fix only after a rebuild.
• Rebuild container images once updated base images are available. Running containers keep their old bundle.
• Check disconnected Windows devices. Microsoft advises confirming that devices without automatic updates still receive the updated Disallowed Certificate Trust List and the trust-list changes.
• Patch macOS command-line tools. Apple has published optional steps to remove the affected roots from /etc/ssl/cert.pem ahead of a future software update.
• Contact vendors of embedded, IoT and OT devices to confirm firmware updates or trust-store changes.
• Replace your own certificates that chain to the emSign ECC Root CA - G3 before clients stop trusting them.
• Test clients against the test endpoints and affected-certificate list on the incident tracking site maintained by Mozilla's Dennis Jackson.
• Plan for breakage. Removing a root from a trust store also removes trust in legitimate certificates under that root, so test changes before broad rollout.

How ExtraHop RevealX detects compromised eMudhra certificates

Updating local trust stores eliminates the vulnerability going forward, but network evidence reveals whether an adversary exploited the flaw before remediation. Independent wire data also highlights which non-browser clients still require attention.

To address the risk, ExtraHop researchers developed a detector for the compromised intermediates and issued a threat briefing in RevealX, which customers received automatically.

The eMudhra Compromised Intermediate CA Certificates Briefing in RevealX 360. The Threat Briefing Status panel shows whether RevealX has found relevant detections or devices.

How the detector works

• Full certificate chain inspection. For each Transport Layer Security (TLS) session, RevealX reconstructs the complete certificate hierarchy presented by the server and cross-references the Secure Hash Algorithm 1 (SHA-1) fingerprint of each intermediate signing certificate against the eight compromised authorities.
• Issuer verification flags cryptographically valid forgeries. Because certificates generated with stolen private keys carry authentic mathematical signatures, conventional validation mechanisms accept them without warning. The RevealX detector triggers on the identity of the signing authority itself, surfacing forgeries that would otherwise bypass standard inspection.
• Coverage extends to every device on the wire. Because RevealX sensors operate out of band and require no endpoint agents, the detector monitors network traffic from Linux servers, containers, Internet of Things (IoT) devices, and AI agents that have not received trust-store updates.
• TLS 1.3 requires decryption. Because Transport Layer Security (TLS) 1.3 encrypts the certificate exchange, the certificate chain remains hidden from passive inspection. Organizations with RevealX decryption enabled maintain full visibility into these encrypted handshakes.

What customers need to do

RevealX customers receive the detector automatically. A banner in RevealX announces the threat briefing and links directly to the briefing page. The briefing includes:

• Threat briefing status: Reports "No Risk Identified" when RevealX detects no matching certificate anomalies or exposed network assets.
• The eMudhra certificate activity dashboard: Catalogs Transport Layer Security (TLS) sessions involving servers that present a compromised intermediate, updating in real time as detections occur.
• The "Review eMudhra Certificate Activity" threat hunting workflow: Guides analysts through triage, helping teams isolate unpatched clients, assess connection context, and inspect session records for signs of interception.

Analysts should treat any hit as a priority. A hit means a client received a certificate chain built on a compromised key. Identify the client, check whether its trust store is updated, and review the session for signs of interception. Preserve the transaction records and packets for the investigation.

Trust Needs Verification

The eMudhra incident shows how one error in a key ceremony can ripple across the internet for 17 months before discovery. Browser vendors can push a fix to billions of users in hours. The rest of the enterprise, from data center servers to AI agents, depends on security teams to find and fix every client that still trusts a broken chain. Independent network evidence equips security leaders to pinpoint vulnerabilities in non-browser assets, definitively verify whether an intrusion occurred and deliver an airtight accounting of risk to the board.

Learn more

• eMudhra statement on the certificate security incident
• Mozilla: Protecting Firefox users following the compromise of eMudhra intermediate certificates
• Mozilla Bugzilla incident report
• Microsoft: Response to compromised eMudhra certificate authority keys
• Red Hat: RHSB-2026-012 Certificate compromise - eMudhra
• Apple: About the compromised eMudhra intermediate CAs
• ExtraHop: PHP2Shell: How to Stay Ahead of a Zero-Day, from Asset Discovery to Threat Hunting