The eMudhra CA key compromise: why your certificate authority belongs in the vendor risk register

One of the private keys was the number 4. Not a long number that happens to start with 4: the integer 4. On 17 October 2026 a researcher credited only as Wayne told the browser root programmes and eMudhra, the Indian certificate authority (CA) that sells under the emSign brand, that he held the private keys of eight eMudhra intermediate CA certificates. Mozilla recovered the same keys on its own in under two hours, without knowing his method. Mozilla's incident report gives the reason: every one of the eight keys was an integer below 256.

Browser vendors have distributed protections. Enterprises still need to establish which other clients and trust stores require updates. A CA supplies trust that software inherits, so its incident notifications and remediation dependencies belong in the vendor-risk review.

What happened

The eight certificates are six TLS intermediates and two code-signing intermediates. The TLS six cover DV, OV and EV, each in a G3B version for eMudhra's Netherlands entity and a G3C version for its US entity. All eight came out of a single key generation ceremony on 30 April 2025, and a second CA cross-signed all eight in May 2025 using the same public keys.

They are elliptic-curve keys on the P-384 curve. A P-384 private key should be a random number of about 384 bits. These were 4, 56, 66, 115, 155, 156, 230 and 237, so recovering one means computing at most 255 candidate public keys and comparing each with the certificate. Mozilla independently recovered the keys, confirming that the flawed generation was trivial to exploit.

eMudhra's account on the incident report is that the ceremony included an approved deviation to test key wrapping, because these keys were meant for export to US and European data centres. A flaw in the ceremony script created a second, weak key pair on the hardware security module (HSM), and because the key labels were similar, the weak keys were used by mistake for the certificate signing requests. eMudhra says its HSMs are FIPS 140-2 Level 3 devices, that the hardware does not appear to be at fault, and that it will re-verify every key ceremony it has run.

eMudhra's public statement says the incident is limited to these intermediates and its root CA private keys are unaffected. The CA says only one of the eight was deployed in production and none issued an end-entity certificate. The disclosure reports no corresponding Certificate Transparency (CT) entries for the affected TLS intermediates. CT is evidence about logged TLS issuance; it does not establish the absence of code-signing activity or activity outside the logs. The compromised intermediates sit in eMudhra's emSign hierarchy for the global browser root programmes. That hierarchy is separate from the Root Certifying Authority of India, under which eMudhra issues digital signature certificates as a licensed Certifying Authority, and the public record describes no effect on those.

There was an earlier signal. In June 2025 the same six TLS intermediates published revocation lists with invalid signatures, and eMudhra's incident report at the time said the alert email had been quarantined by its own mail filters. eMudhra now says those lists were first signed with the original, strong keys, which did not match the certificates, and were then re-signed with the flawed ones.

Chrome and Firefox blocked the intermediates on 17 October, within hours of the report. Apple followed on 19 October and Microsoft on 20 October, and eMudhra revoked all eight on 18 October. Several people then recovered the keys independently and some published them. On 20 October Mozilla removed emSign ECC Root CA - G3 from its trust store and asked eMudhra to stop issuing under it. Chrome is removing the same root and has said it is evaluating the status of eMudhra's remaining root. eMudhra says about 30,000 legitimate certificates under the removed root need to move to its other root.

Who was exposed, and who still is

For CT-enforcing browser TLS validation, the disclosure explains why the absence of corresponding CT entries prevented exploitation through that path. That conclusion is specific to the clients and validation policies described. It does not extend automatically to code signing, non-browser software or custom trust configurations.

Certificate validation also happens in application runtimes, containers, build runners, appliances and system-to-system integrations. Trust-store location, revocation checks and CT enforcement vary by client and configuration. The disclosure warns that many clients outside the browser ecosystem need software or trust-store updates; a browser update alone does not establish that those systems are protected. The flawed certificates date from April 2025. The public disclosure does not establish whether these weaknesses were exploited against non-browser clients.

The disclosure includes test endpoints and signed proof of key control. Expiry alone is not a timely defence; whether a particular device accepts an affected chain depends on its validation policy and updates. The two code-signing intermediates also need to be considered separately from the six TLS intermediates. Check vendor guidance for supported, older and offline systems.

What to check this week

Test your clients. The disclosure site runs test hosts that serve certificates chaining to the compromised intermediates. Run these from every class of client you care about, including inside containers and on build runners:

curl https://dv-g3b-emudhra.we-have-a-problem.com/
curl https://dv-g3b-aaa-emudhra.we-have-a-problem.com/

Use an authorised test environment and confirm that any failure is specifically the expected certificate-validation rejection. A network, proxy or DNS error does not establish protection. Successful certificate validation against an affected test chain requires investigation. The disclosure also provides chains for offline verification.

Update the trust stores your stacks use. Consult the live developer-package table in the disclosure and the linked vendor advisory for each stack. Versions and release status are changing; record the advisory, deployed version, application owner and verification result for your environment.

Containers keep the bundle they were built with, so rebuild base images after updating. For Go software, check the advisory for the relevant release and rebuild requirements; ask suppliers about shipped binaries as well as the compiler installed on your own systems. For Java, check the JVM's cacerts file and any truststore an application bundles for the emSign roots. On macOS, the built-in /usr/bin/curl reads a bundle file that has not been updated and does not check revocation; the disclosure site gives a workaround. Where a distribution has not shipped an update yet, the same page carries manual distrust commands for Debian, Ubuntu, Alpine, the Fedora and RHEL family, openSUSE and others, recommended for expert users only.

Inventory certificates and chains. Two questions lead to different actions. First, does anything in your estate chain to the eight intermediates? The CA says they issued no end-entity certificates. An unexpected chain therefore needs investigation, provenance checks and incident triage, distinguishing known research/test artefacts from unauthorised issuance. A matching issuer name alone is insufficient: inspect the actual certificate and chain. Second, do your public sites, APIs or partner integrations use legitimate eMudhra certificates under emSign ECC Root CA - G3? Clients on updated Mozilla-derived trust stores will reject those, so find them now and plan re-issuance. Ask the same of suppliers whose endpoints your systems call.

What this means for vendor risk

Third-party risk programmes inventory the suppliers that hold your data. A CA holds something different: the authority to vouch for any website's identity to your software. An organisation may inherit these dependencies through its software suppliers. Operating system maintainers, language runtimes and appliance vendors made that choice when they shipped their trust stores, and a second CA's cross-signature carried the same keys into further stores. Trust is inherited through suppliers, and so is exposure. Check browsers, operating systems, application runtimes, payment integrations and build pipelines separately. They may receive protections through different update mechanisms.

CAs and other trust-service providers, including digital signature certificate providers, timestamping authorities and managed PKI or certificate lifecycle services, belong in the vendor register with their own assurance questions:

• Key generation evidence. Ask for the ceremony script, the witness record, and how any deviation from the standard procedure is approved and tested. In this incident, the approved deviation is where the process broke.
• HSM use and key checks. Ask which HSMs are used and at what FIPS level, and whether anyone checks generated public keys for known weaknesses before a root signs them. A test against small multiples of the curve's generator point would have caught all eight keys.
• Audits and incident history. Ask for current audit reports, and read the CA's public incident history in Mozilla's Bugzilla. The June 2025 revocation-list incident on these same intermediates sat there in public for sixteen months.
• CT logging and monitoring. For public TLS issuance, ask about applicable CT logging and monitoring. Ask separately about issuance records and monitoring for code-signing and private-PKI products; the same CT assumptions do not apply to all certificate types.
• Incident notification. Agree how quickly, through which channel and to whom it will report a compromise. Then ask whether you heard about this incident from your CA or from the news.
• Re-issuance and a second source. Ask how quickly it can move your certificates to another chain if a root is distrusted. Keeping a second CA approved for critical services removes a single point of failure.

Then follow the trust one step further. Ask critical suppliers, such as payment gateways, SaaS platforms, managed service providers and partners with system-to-system connections, whether the systems that connect to you have updated trust stores, and since when. For SEBI- and RBI-regulated entities, record the CA dependency, the affected systems, the update dates and each supplier's answer in your third-party records, so the evidence is ready when a supervisor or auditor asks.

How ShadowMap helps

ShadowMap's attack surface management observes certificates and other externally visible properties of internet-facing assets. That gives teams a starting inventory for their own certificate-chain review; it does not establish which trust stores an internal application uses.

The third-party risk view applies the same outside-in methodology to monitored vendors, with dated exposure observations and evidence. Vendor-side findings remain observed and untested without the necessary authorisation. Neither external view can inspect a CA's key ceremony or prove that a supplier has deployed a particular fix. The register entry, direct supplier confirmation and client-side verification cover those gaps.