# The eMudhra CA Key Compromise: What It Means for Signed Documents, and How to Check a Signature's Trust Chain

> Eight eMudhra intermediate CA keys were small enough to guess. What happened in October 2026, what was affected, and how to check who really vouches for a signed document.

*Published 2026-11-09 · 8 min read · TamperCheck.ai*

Canonical: https://tampercheck.ai/blog/emudhra-ca-key-compromise-signature-trust

---
On 17 October 2026, a researcher scanning public certificate data found that eight intermediate certificate authority (CA) keys belonging to eMudhra, an Indian CA operator, could be worked out from their public certificates. They hadn't been stolen. The keys were so small that anyone could guess them. Security researcher Scott Helme summed it up: "One of eMudhra's certificate authority private keys is the number 4" ([Help Net Security](https://www.helpnetsecurity.com/2026/10/21/emudhra-certificates-private-keys-compromised/)).

Browsers and operating systems blocked the certificates within days, and eMudhra has since said it will leave the global TLS certificate business. For anyone who accepts digitally signed PDFs (contracts, invoices, government letters, employment records), the incident raises a question that comes up more often than it should: **a signature says "valid", but who is actually vouching for it?**

## Key takeaways

- **The keys were guessable, not stolen.**: Each of the eight intermediate private keys was a number below 256, so it could be recovered from the public certificate in moments.
- **The response was fast.**: Chrome and Mozilla blocked the certificates on 17 October, and Apple and Microsoft followed. Mozilla removed the emSign ECC Root CA - G3 from its trust store on 20 October.
- **eMudhra says Indian DSC and eSign are unaffected.**: The company and MeitY officials say the CCA-regulated signing services are separate. According to eMudhra, none of the eight intermediates issued an end-entity certificate.
- **A valid signature is not the end of the check.**: You still need to know which CA chain the signer reaches, whether that chain is still trusted, and whether the document changed after it was signed.

## What happened, in order

Here is the sequence as reported by [BleepingComputer](https://www.bleepingcomputer.com/news/security/mozilla-google-apple-block-compromised-emudhra-ca-certificates/), [The Hacker News](https://thehackernews.com/2026/10/eight-emudhra-ca-keys-compromised.html) and [Help Net Security](https://www.helpnetsecurity.com/2026/10/21/emudhra-certificates-private-keys-compromised/):

- **30 April 2025:** a key-generation ceremony created a batch of intermediates under eMudhra's ECC root. eMudhra later blamed a flaw in the key wrap and unwrap process for producing a second, weak set of keys.
- **17 October 2026:** a researcher reported the weak keys to the root programs. Chrome had a CRLSet block for the six TLS intermediates in place that evening, and Mozilla pushed a OneCRL block to Firefox the same night.
- **18 October:** eMudhra revoked all eight certificates.
- **19 to 20 October:** Apple and Microsoft blocked them. Mozilla shipped Firefox updates and removed **emSign ECC Root CA - G3** from NSS. Go issued **CVE-2026-111943** and rejects any chain containing one of the eight keys.
- **21 October:** India's CERT-In issued an advisory, and MeitY set up a team to investigate.
- **22 October:** eMudhra announced it would exit the global SSL/TLS business. Palo Alto Networks' Unit 42 published guidance describing the keys as [generated with insufficient randomness](https://unit42.paloaltonetworks.com/emudhra-certificate-compromise/).

Six of the eight were TLS intermediates (DV, OV and EV, in G3B and G3C variants). The other two were code-signing intermediates. Each one also existed as a copy cross-signed by Sectigo.

- **8**: intermediate CA keys recoverable from public certificates
- **< 256**: the size of each private key that should have been a 384-bit random number
- **~30,000**: customer certificates eMudhra estimates need replacing (Help Net Security)

## Was anything actually forged?

As of early November, no public report shows real-world abuse. eMudhra says only one of the eight intermediates was ever used in production, and that none of them issued an end-entity certificate. Help Net Security notes that nobody knows whether anyone else recovered the keys before the disclosure.

That uncertainty is the point. Helme described the problem as "the key was effectively public from the day the certificate existed." For about 18 months, anyone who checked could have computed a key that browsers trusted. A CA key is the thing that makes a signature mean something. If it's public, a certificate it signs proves nothing about who holds it.

> **INFO:** **Indian DSC and eSign users:** eMudhra's DSC, eSign and emSigner products sit under India's Controller of Certifying Authorities (CCA), not under the compromised global intermediates. eMudhra and MeitY officials both say these services are unaffected ([The Hacker News](https://thehackernews.com/2026/10/eight-emudhra-ca-keys-compromised.html)). If you receive a DSC-signed PDF, the relevant question is still the usual one: does the signer's chain reach a CCA-licensed CA, and is the signed content intact?

## Why this matters for signed documents, not just websites

Most coverage of the incident focused on HTTPS. Signed documents depend on the same machinery: a signer certificate, issued by an intermediate, chaining to a root that someone has decided to trust. The incident shows three things that document reviewers often skip.

1. **"Valid" usually means the maths checks out, not that the signer is trustworthy.** A PDF reader can report a signature as cryptographically valid even when the certificate chains to a CA nobody trusts for document signing, or to one that was distrusted last week.
2. **Trust is per program and it changes.** Adobe's AATL, the EU trusted lists, India's CCA, Microsoft's document-signing roots and Mozilla's web roots are different lists with different purposes, and they're updated on their own schedules. A root can disappear from one list overnight, as emSign ECC Root CA - G3 did from Mozilla's.
3. **A signature only covers the bytes it signed.** A document can carry a genuine, trusted signature and still have content added after signing, such as an incremental update that changes a figure on page 3.

## How TamperCheck checks a signature's trust chain

When a signed PDF is uploaded, TamperCheck's [PDF authenticity checks](https://tampercheck.ai/problems/verify-pdf-authenticity) do more than ask whether the signature verifies. The trusted-certificate detector:

- **Builds the chain from the certificates embedded in the PDF** and checks that each issuer really is a CA allowed to issue the certificate below it.
- **Reports trust per program, not as one yes or no.** The bundled trust stores cover Adobe AATL, the EU List of Trusted Lists, India's CCA roots and licensed CAs, Microsoft's document-signing roots, CCADB, the US Federal PKI, and the Japanese, Korean and Ukrainian government PKIs. A chain that reaches India's CCA but not Adobe shows up as regionally trusted, not as fake.
- **Separates web CAs from document-signing CAs.** A chain that only reaches a browser (TLS) root is reported as a recognised public CA, not as a document-signing authority. This matters here: the compromised intermediates were TLS and code-signing CAs.
- **Flags lookalike and self-made CAs.** A root named almost exactly like a trusted CA, but with a different key, is flagged as a lookalike, and a self-signed "CA" is reported as such.
- **Checks the signer certificate itself:** whether it was allowed to sign documents, and whether it was valid at the signing time.
- **Checks a denylist of distrusted CAs** and refreshes the trust stores from their official publishers on a regular schedule. A root that a program drops stops counting as trusted after the next refresh.
- **Checks what happened after signing.** The document timeline shows whether content changed after the last trustworthy signature, which is the edit that actually matters.

The result is a plain statement a reviewer can act on, for example "signed by a certificate that chains to an EU-qualified CA, signature intact, no edits after signing", rather than a green tick that hides which assumption it rests on.

**Check who really signed your PDF**. Upload a signed PDF and see which trust programs vouch for the signer, whether the signature is intact, and whether anything changed after signing. (https://tampercheck.ai)

## What to do now

- **If you run TLS certificates from eMudhra**, follow your CA's replacement guidance. eMudhra says affected customers are being moved to other providers.
- **If you accept signed documents**, don't treat a PDF reader's "signature valid" message as the whole answer. Check which root the chain reaches, whether that root is trusted for document signing in your jurisdiction, and whether the content changed after signing.
- **If you build verification workflows**, make sure your trust lists are refreshed and that a distrust event actually reaches your checks. Lists that were bundled years ago don't pick up a distrust from last month.

## FAQ

### What happened with eMudhra's certificates in October 2026?

A researcher found that eight eMudhra intermediate CA certificates had private keys that were numbers below 256, so anyone could recover them from the public certificates. The issue was reported on 17 October 2026. eMudhra revoked the certificates, browsers and operating systems blocked them, and Mozilla and Google moved to remove the emSign ECC Root CA - G3.

### Are eMudhra DSC and eSign signatures still valid?

eMudhra and MeitY officials say its Indian DSC and eSign services, which are regulated by the Controller of Certifying Authorities, were not affected. A DSC-signed document should still be checked as usual: the chain should reach a CCA-licensed CA, the certificate should have been valid when it signed, and the signed content should be unchanged.

### Were any documents or websites forged with the compromised keys?

No public report shows abuse as of early November 2026. eMudhra says none of the eight intermediates issued an end-entity certificate. Because the keys could be computed from public data for about 18 months, it isn't possible to prove nobody else recovered them.

### Why isn't 'signature valid' in a PDF reader enough?

It usually confirms that the signature's maths matches the signed bytes. It doesn't tell you whether the signer's CA is trusted for document signing in your jurisdiction, whether that CA has since been distrusted, or whether content was added after signing. Those are separate checks.

### How does TamperCheck verify a digital signature's trust?

It builds the certificate chain embedded in the PDF and matches it against trust stores from Adobe AATL, the EU trusted lists, India's CCA, Microsoft, CCADB, the US Federal PKI and several government PKIs. It then reports trust per program, flags lookalike, self-signed or distrusted CAs, checks the signer certificate's purpose and validity, and checks whether the document changed after signing.

## Sources

- Help Net Security, "eMudhra security blunder left trusted CA signing keys exposed to anyone", 21 October 2026 (updated 23 October). [helpnetsecurity.com](https://www.helpnetsecurity.com/2026/10/21/emudhra-certificates-private-keys-compromised/)
- BleepingComputer, "Mozilla, Google, Apple block compromised eMudhra CA certificates", 20 October 2026. [bleepingcomputer.com](https://www.bleepingcomputer.com/news/security/mozilla-google-apple-block-compromised-emudhra-ca-certificates/)
- The Hacker News, "Eight eMudhra CA Keys Compromised, Triggering Emergency Fixes Across Browsers and Software", 20 October 2026. [thehackernews.com](https://thehackernews.com/2026/10/eight-emudhra-ca-keys-compromised.html)
- Palo Alto Networks Unit 42, "eMudhra Intermediate CA Certificates Compromised", 22 October 2026. [unit42.paloaltonetworks.com](https://unit42.paloaltonetworks.com/emudhra-certificate-compromise/)
- Qualys, "How to Identify Compromised eMudhra Certificates With Qualys", 23 October 2026. [blog.qualys.com](https://blog.qualys.com/product-tech/2026/10/23/how-to-identify-compromised-emudhra-certificates-with-qualys-cve-2026-111943-and-cve-2026-111944)