eMudhra certificate incident 2026: trust-store next steps

What the organizations disclosed

Mozilla stated that it received the report on 17 October and blocked the affected intermediates in Firefox through OneCRL. It also described updates for other trust-store consumers. The risk involved fraudulent certificates that could support impersonation where an attacker could intercept a connection.

eMudhra’s published statement acknowledged weak intermediate keys, described revocation and customer transition work, and said its investigation had found no compromise of infrastructure or customer data. Keep these distinct statements attributed to their sources. Weak CA keys do not establish that every customer connection was intercepted.

References: [1] Mozilla, [2] eMudhra

Map the trust decisions your software uses

Inventory TLS clients as well as public-facing certificates. An API client, packaged runtime, container, mobile application, and browser can depend on different trust stores or update channels. A browser’s emergency protection may not automatically change an application with a bundled certificate store.

Record who supplies and maintains each trust store, how updates reach production, and where applications override defaults. Include internal proxies and custom certificate configuration. This produces a concrete update list instead of relying on the assumption that an operating-system patch reaches every client.

References: [1] Mozilla, [3] AWS

Follow vendor remediation without disabling verification

Use the affected product and trust-store vendor’s current guidance for updates or certificate transition. If your certificate chain depends on a distrusted issuer, coordinate replacement and verify the resulting chain from the clients that matter to your service.

Do not address a connection failure by turning off TLS certificate validation. That removes the identity check the system needs. Separate compatibility testing from the security decision: confirm a trusted chain, a matching hostname, and a supported update path while preserving verification.

References: [1] Mozilla, [4] OWASP

Test trust and operational recovery

Document successful connections from representative runtimes after updates. Where you control a safe test environment, confirm that an explicitly untrusted chain is rejected. Include background jobs and integration clients that may not exercise connections during a normal browser smoke test.

Review certificate inventory, renewal ownership, and emergency replacement procedures. Retain the relevant chain and runtime evidence in the change record. This incident is a reminder that TLS assurance depends on maintained trust decisions across the system, not just the padlock shown by one browser.

References: [2] eMudhra, [3] AWS

Your next steps

1. Inventory application certificates, client runtimes, bundled roots, and custom trust stores.
2. Check the current remediation instructions from each affected product vendor.
3. Coordinate necessary certificate replacement and trust-store updates.
4. Verify representative clients while keeping hostname and chain validation enabled.