> ## Content Index
> Fetch the complete content index at: https://f4n6.co.uk/llms.txt
> Use this file to discover other available public pages before exploring further.

# eMudhra CA withdraws after weak keys enable MITM attacks
- URL: https://f4n6.co.uk/security-feed/emudhra-ca-withdraws-after-weak-keys-enable-mitm-attacks/
- Published: 2026-10-22T19:22:59.000Z
- Updated: 2026-10-22T19:22:59.000Z
- Author: Jeff Davies
- Tags: #security-feed

## 1\. Executive summary

eMudhra, one of the few Indian certificate authorities whose root is trusted by major browsers, is withdrawing from the global SSL/TLS certificate business after eight of its intermediate certificates were found to have weak private keys. One key was the number four rather than a random 384-bit value; others were 56 and 115\. The certificates were issued in an April 2025 ceremony and the flaw survived 18 months and two independent audits before researcher Scott Helme reverse engineered the keys. No CVE has been assigned and there is no CISA KEV entry; the risk is not a software vulnerability to patch but a trust-anchor failure that propagates through every product carrying an embedded certificate store. For EMEA financial services the exposure is TLS interception and impersonation against any client, partner or internal system that still trusts the affected chains, and the remediation burden falls on asset owners who may not know where those trust stores live.

## 2\. Regulatory framing

| Article            | Trigger (the fact in this item)                                                                                                                                                                            | Practical impact                                                                                                                                                                                        |
| ------------------ | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| DORA Art. 28       | A certificate authority in the ICT third-party chain issued intermediates with weak private keys, and clients may hold eMudhra-issued certificates or trust stores in products and services they depend on | Identify every eMudhra-issued certificate and every embedded trust store in the estate, and record the CA as an ICT third-party dependency with its migration timeline                                  |
| DORA Art. 30       | eMudhra is withdrawing from the business and transitioning customers to other CAs, which changes the contractual relationship mid-term                                                                     | Review certificate and PKI contracts for revocation, transition and exit provisions, and confirm the replacement CA's obligations are documented before the old certificates expire                     |
| NIS2 Art. 21(2)(d) | The weak keys sit in a supplier's certificate issuance process, and the fix depends on downstream vendors shipping updated trust stores                                                                    | Treat certificate authority and embedded trust-store suppliers as supply chain dependencies, and require confirmation of updated bundles from vendors whose products carry their own certificate stores |

## 3\. Technical analysis & attack chain

The failure is in key generation, not in a protocol implementation. During an April 2025 ceremony eMudhra generated private keys for eight intermediate certificates. At least one 384-bit key was the integer four; others were 56 and 115\. A private key of that size is trivially recoverable, and anyone holding it can sign certificates that chain to the eMudhra root and validate in any client that trusts that root.

Confirmed sequence:

1. eMudhra generated intermediate certificate key pairs during an April 2025 ceremony. One step of the ceremony procedure produced weak private keys.
2. The weak keys went undetected for 18 months and passed two independent audits.
3. Scott Helme reverse engineered the keys and published the finding.
4. Google, Mozilla, Apple and Chrome moved to block the affected certificates.
5. eMudhra revoked the affected certificates within 14 hours of discovery, per chairman V. Srinivasan.
6. eMudhra announced voluntary withdrawal from the global SSL/TLS certificate business and committed to running revocation and certificate status services until every issued certificate has expired or been replaced.

The attack primitive is certificate forgery. An adversary who recovers a weak intermediate private key can issue a certificate for any domain, chain it to a trusted root, and present it to a client that trusts the eMudhra root. Cloudflare's assessment, cited in the reporting, is that because the certificates were widely trusted by its systems, browsers and operating systems, an attacker could forge a certificate for any domain and impersonate servers to intercept or modify traffic. CERT-IN's alert states the same capability enables credential theft, sensitive data exposure and financial fraud, and adds that fraudulent certificates would let malicious software appear digitally signed by a trusted publisher. That last point matters for financial clients: code-signing trust and TLS trust draw on the same class of anchor, and a forged certificate can defeat signature checks that rely on the compromised chain.

No exploitation in the wild is reported. Srinivasan said there were no compromises or data breaches as a result of the issue. India's Ministry of Electronics and IT said it is investigating and disputed the severity of social media commentary. Those are the company's and the ministry's positions; the reporting does not include independent confirmation that no forged certificate was ever used, and revocation within 14 hours limits but does not exclude a window of misuse.

The remediation problem is distribution, not cryptography. Brian Fox of Sonatype told Recorded Future News that trust stores are embedded in dozens of products, each needing its own update, rebuild or release, and that most organisations have no inventory of where they live. The original eMudhra-issued intermediates were not due to expire until April 2040, so clients that do not process revocation information may keep trusting the affected chains long after the revocation. That is the concrete exposure for a bank: an internal appliance, container base image or vendor tool with a pinned trust store that never checks OCSP or CRL will accept a forged chain until the bundle is replaced.

Single-source caveat: the key values (four, 56, 115), the April 2025 ceremony date, the 18-month detection gap, the two audits and the 14-hour revocation window all rest on eMudhra's statements and Helme's blog as relayed by Recorded Future News. The technical claim that the keys are recoverable is corroborated by Google, Mozilla, Cloudflare and CERT-IN; the timeline and audit details are not independently corroborated in the source material.

## 4\. Mitigation & containment

P1 (within 24 hours)

- Inventory every certificate in the estate that chains to an eMudhra root or intermediate, across internet-facing TLS, internal services, code signing and client authentication. Query certificate transparency logs and your CMDB; where inventory is incomplete, scan.
- Confirm the affected intermediates are revoked and that your clients check revocation. Test OCSP and CRL reachability from the segments that terminate TLS, and treat any client that fails open on revocation as exposed.
- Block the affected intermediates at the TLS inspection and forward-proxy layer, and add them to any certificate pinning or allow-list exceptions so a forged chain is rejected even where the trust store is stale.

P2 (within 72 hours)

- Identify embedded trust stores: container base images, appliances, embedded devices, Java keystores, vendor tools that ship their own CA bundles. Fox's point is that these are the long tail; enumerate them rather than assume browsers are the only surface.
- Replace eMudhra-issued certificates with ones from an unaffected CA, and update the trust stores that still carry the eMudhra root where the vendor has shipped a bundle update.
- Require vendors whose products embed certificate stores to confirm in writing whether the eMudhra root is present and when an updated bundle ships.

P3 (within 7 days)

- Review monitoring for anomalous certificate issuance and unexpected certificate changes on your domains, and alert on certificates chaining to the affected intermediates appearing after revocation.
- Record the CA transition in third-party risk records and track eMudhra's root-cause report and its commitments to the browser root programs.
- Where code-signing trust relies on the same anchors, re-verify signatures on recently delivered software and confirm the signing chain does not include the affected certificates.

## 5\. Indicators of compromise

No indicators of compromise available in the source material. The reporting names no malicious domains, hashes, IP addresses or forged certificates. The affected intermediates are identified only by count (eight) and by the weak key values, not by certificate serial numbers or subject names, so they cannot be listed as atomic indicators here.

Behavioural indicators

| behaviour                                                                                   | where to observe                                                     | confidence                                             |
| ------------------------------------------------------------------------------------------- | -------------------------------------------------------------------- | ------------------------------------------------------ |
| TLS certificate presented for a domain chains to an eMudhra intermediate after revocation   | TLS inspection logs, proxy logs, certificate transparency monitoring | medium                                                 |
| Client accepts a certificate chain that fails OCSP or CRL checks (revocation not processed) | Endpoint and appliance TLS logs, proxy revocation logs               | medium                                                 |
| Software signature validates against a chain including an eMudhra-issued certificate        | Code-signing verification logs, software intake                      | low, single-sourced inference from CERT-IN's statement |

## 6\. Detection

Insufficient indicators to author detection rules. The source material contains no distinctive strings, file paths, registry keys, command-line flags or network artefacts belonging to the threat. The only concrete values are the weak private key integers (four, 56, 115), which are properties of the certificates rather than artefacts a detection rule can match on, and the CA name, which would detect reporting about the incident rather than the incident itself. Detection here is a trust-store and revocation-checking control, covered in §4, not a signature.

## 7\. Sources

- Recorded Future News (Jonathan Greig), "Indian tech company eMudhra announces withdrawal from certificate business after security incident", https://therecord.media/indian-tech-company-announces-withdrawal-certificate-business-incident, 2026-10-22.
- Scott Helme, blog post on the weak eMudhra private keys, referenced in the above; URL not given in the source material.
- CERT-IN alert on the compromised private keys, referenced in the above; URL not given in the source material.
- Statements from Google, Mozilla, Cloudflare, India's Ministry of Electronics and IT, and Sonatype (Brian Fox), all as quoted in the Recorded Future News article.

## 8\. Adverse Trace position

Adverse Trace assesses this as a trust-anchor and supply chain event rather than a patchable vulnerability: no CVE, no CISA KEV entry, no reported exploitation, but a certificate authority whose intermediates could be used to forge certificates for any domain until revocation propagates everywhere. The severity to an EMEA financial client depends on how much of its estate still trusts the affected chains and whether its clients process revocation; the reporting gives no evidence of misuse, and the "no compromise" claim is eMudhra's own and not independently corroborated. We will track eMudhra's root-cause report and its commitments to the browser root programs, and we will re-issue this advisory if forged certificates chaining to the affected intermediates are observed or if the root-cause report contradicts the timeline given here. Clients should treat the embedded trust-store inventory in §4 as the priority action, because that is where the exposure outlives the revocation.

---

[Read the original source →](https://therecord.media/indian-tech-company-announces-withdrawal-certificate-business-incident?ref=f4n6.co.uk)

*Published via PulseTrace — Adverse Trace threat intelligence.*