Menu
Breach Value Calculator

eMudhra Certificate Compromise: What to Replace and Check

Eight eMudhra intermediate CA keys were recoverable from public data, reported 17 Oct 2026. Mozilla removed the root. What to check and replace.

By CyphrQ.ai

Written with AI assistance and human editorial review. Every figure linked to its source.

Identified: 17 October 2026Published 12 min read

What happened in the eMudhra certificate compromise? On 17 October 2026, a researcher reported that the private keys of eight intermediate certificates run by eMudhra, an Indian certificate authority (CA), could be worked out from public certificate data. eMudhra revoked all eight on 18 October 2026. Mozilla then removed trust in the root above them, and Chrome committed to the same path.

This is a CA key compromise, not an intrusion. eMudhra says its infrastructure was not compromised.

No source we read reports an attack using the keys, as of 3 November 2026. Once the keys were public, though, others signed more than 100,000 certificates with them on 20 and 21 October 2026, almost all described as proof-of-concept certificates (see below). The incident site run by Mozilla's Dennis Jackson says "We do not know if attackers exploited the flawed key generation to target these clients."

About 30,000 customer certificates need replacing, eMudhra told Mozilla. Other incidents from India and its neighbours sit under Breaches: Asia.

Case file

Field Value
Organisation eMudhra, through its emSign roots. The certificates name eMudhra BV and eMudhra Inc (Mozilla Bugzilla 2083449, comment 0)
Region India, where eMudhra has been a licensed Certifying Authority since 7 November 2008 (Controller of Certifying Authorities)
What was exposed The private keys of eight intermediate CA certificates: six that issue website (TLS) certificates and two for code signing (comment 0)
Cause Flawed key generation at a key ceremony on 30 April 2025. eMudhra says a second, weaker key pair was created and used by mistake "because the key labels were similar" (comment 11)
Identified 17 October 2026. The researcher, who signs as Wayne, emailed Apple, Chrome, Microsoft, Mozilla and eMudhra that day (comment 2). Mozilla received it at 20:06 UTC, forwarded by the Chrome Root Program (comment 0)
Revoked 18 October 2026, between 09:24 and 09:38 UTC, with the reason "cACompromise" (comment 10)
Trust removed Mozilla: emergency removal of emSign ECC Root CA - G3 (comment 18). Chrome: "a similar path" (comment 20). Mozilla is not removing trust in emSign Root CA - G1 "at this time" (comment 18)
Blocked by vendors Firefox and Chrome from 17 October 2026, Microsoft from 20 October, per Jackson's incident site. Apple's date is unconfirmed: 22 October per the incident site, 19 October per Help Net Security
Certificates to replace "About 30,000", of which about 97% were issued through ACME, the automated issuance protocol (eMudhra, comment 19)
Misuse No attack reported in the sources we read, as of 3 November 2026; Jackson's incident site says "We do not know". After the keys became public, others signed 107,107 certificates with six of them, 106,050 described as proof-of-concept (comment 44)
Status eMudhra is leaving the global SSL/TLS certificate business (press release, 22 October 2026). It has appointed KPMG to review the incident and expects to share its full report on 9 November 2026 (comment 73)

What is a CA key compromise, and why does one weak key matter?

A certificate authority is an organisation your browser trusts to confirm who owns a website. When it signs a certificate for a domain, your browser shows the padlock without asking further questions.

A CA key compromise is when someone other than the certificate authority can obtain a private key the CA uses to sign certificates.

Most CAs sign customer certificates with an intermediate certificate, which sits between the customer and the CA's root. Whoever holds an intermediate's private key can sign certificates that browsers accept.

That is why a weak key matters even if nobody broke into anything. Mozilla's incident bot put it plainly: "Anyone holding those keys could issue certificates Firefox would accept for any domain" (comment 9). Cloudflare says a forged certificate could be used to "impersonate servers to intercept or modify traffic" (Cloudflare).

How did the eMudhra keys become recoverable?

A private key is meant to be a very large random number. Mozilla found that the eight affected keys were integers below 256 (comment 5). With so few possibilities, the key can be found from the public certificate alone.

Mozilla was explicit that this was a key generation failure: "The original key generation was flawed - rather than any issue with the produced signatures." The keys were generated in hardware security modules (HSMs), eMudhra said (comment 10).

eMudhra's preliminary explanation is that "a flaw in the code resulted in the second pair of keys being created onboard which were weaker", and that this weaker pair was then used to create the certificate requests (comment 11).

The flaw sat in public view for about 17 and a half months, from the key ceremony on 30 April 2025 (comment 11) to the report on 17 October 2026. Jackson's site says recovering the keys "would have been possible since the certificates were created in April 2025."

What did eMudhra, Mozilla, Chrome and others say?

Organisation What it said or did Source
eMudhra Revoked the affected CAs "within 14 hours of discovery". "Its infrastructure was not compromised and no data was breached." Will replace affected certificates free of cost through partners. Its G1 RSA roots keep serving customers until the transition is complete Press release, 22 October 2026
eMudhra Has "ceased issuance from all intermediaries chaining up to emSign ECC Root CA - G3" Comment 21
Mozilla Removed trust in emSign ECC Root CA - G3 because "multiple individuals have independently recovered the private keys for these intermediates" Comment 18
Mozilla and Chrome The certificates "have been blocked in Firefox and Chrome since the 17th of October" 2026 Incident site
Chrome Root Program "Chrome has committed to a similar path as described by Mozilla" Comment 20
Microsoft Blocked on Microsoft platforms from 20 October 2026, shipped "through Windows' automatic certificate trust list updates" Incident site
Apple Apple's block date is unconfirmed: Jackson's incident site says 22 October 2026, Help Net Security says 19 October. Neither source is Apple Incident site; Help Net Security
Cloudflare Became aware on 19 October 2026 at about 17:00 UTC; "has not identified active exploitation of this issue on Cloudflare services" Cloudflare

Were any certificates issued from the compromised keys?

Yes, after the keys became public, but not by eMudhra, according to the Bugzilla thread.

  • eMudhra says it issued none itself. "There were no end entity certificates issued out of the affected CA's," its press release says. It told Mozilla the same in comment 10 and comment 43. That statement covers eMudhra's own issuance, not certificates others signed after the keys became public.
  • Others signed certificates once the keys were public. A commenter on Mozilla's bug reported that between 09:40 UTC on 20 October and 22:02 UTC on 21 October 2026, 107,107 certificates signed with six of the eight keys were logged to e-Szignó's Certificate Transparency (CT) logs, the public records of issued certificates. It says "Every signature verifies under the corresponding CA key" (comment 44). The same comment describes 106,050 of them as "proof-of-concept certificates whose only SAN is google.com", meaning google.com is the only domain they name.
  • Who signed them is not known. Comment 44 agrees "that eMudhra issued no end-entity certificates from these eight CAs" and says the certificates were issued "by others". It does not say who. No later comment in the thread repeats the count.
  • Chrome counted certificates under the root. Using CT data as of 21 October 2026, Chrome counted about 30,800 unexpired precertificates (the copies a CA logs before issuing) chaining to the G3 root: 30,791 from two InCommon subordinate CAs and 18 from other eMudhra intermediates, such as EM OV TLS CA - G3A-1 (comment 30). Chrome's count excludes precertificates logged after 17 October 2026 under the compromised EM DV TLS CA - G3B.

What this means for you: the 30,000 replacement figure follows from the root's distrust, not from certificates proven to be forged. If your certificate chains to emSign ECC Root CA - G3, it needs replacing either way.

Does the distrust cover code signing as well as websites?

On Windows, yes; elsewhere, no source says. Two of the eight compromised intermediates are code-signing CAs (EM OV CS CA - G3B and G3C, per comment 0), and Jackson's site says the Windows block covers chain validation "including Schannel TLS and Authenticode", Microsoft's code-signing format.

Mozilla's root decision in comment 18 does not state a scope for TLS, email or code signing in the text we read. We found no source stating the code-signing position for Apple or the other trust stores (the lists of root certificates a browser, operating system or program accepts), so we make no claim for them.

What should you check after the eMudhra certificate compromise?

If you run websites or APIs:

  1. Check who issued your certificates. Look at the issuer and chain of each certificate you serve. Anything chaining to emSign ECC Root CA - G3 needs replacing.
  2. Move to another CA. With about 97% of affected certificates issued through ACME, for most sites this is a change to the ACME directory and account settings, then a renewal.
  3. Check the certificates your systems trust, not only the ones they serve. Clients, partners' endpoints and internal services may present emSign certificates to you.

If you run laptops, servers or containers:

  1. Update browsers and operating systems. Firefox, Chrome and Microsoft blocked the eight intermediates centrally; Apple's date is in dispute (see the table).
  2. Find software with its own trust store. Jackson's site tracks fixes for NSS, the curl CA bundle, certifi, rustls-webpki, Node.js, Python, Java, Go, Electron, Docker, Git for Windows, GitLab and Visual Studio Code. An operating system update does not reach these.
  3. On Macs, check the developer tools. In an update on 28 October 2026, Jackson's site says git, curl and python3 on Apple systems still trust the compromised certificates, and that macOS 27.2 undid fixes users had applied.
  4. Cloudflare users: update the Cloudflare One Client or WARP app and move cloudflared to 2026.10.2, per Cloudflare's post.

What to ask your vendors

  • Does your product use the operating system's trust store, or ship its own?
  • If it ships its own, which version removes the eMudhra intermediates and the G3 root, and when did it ship?
  • Do any of your services present certificates that chain to emSign ECC Root CA - G3?
  • Do you sign software or updates with a certificate from eMudhra?

Going deeper: for security and IT teams

How it works. The eight affected keys were elliptic-curve keys on P-384; Mozilla describes them as "all the P384 keys for the B and C series" from the 30 April 2025 ceremony (comment 5). An elliptic-curve private key is a single integer, and the public key in the certificate is derived from it. Security depends on that integer being drawn at random from a space of roughly 2^384 values. A key below 256 leaves at most 255 candidates, each checkable against the published public key. The curve and the signature algorithm were not the problem; the random number was. Mozilla's Dennis Jackson wrote that "some local agents" he tested, given a one-line prompt, "were able to recover the private key on their first attempt" (comment 5).

Threat model. The attacker needs only public data to obtain a key. To use it against TLS they also need a network position: a hostile Wi-Fi, a compromised router, DNS manipulation or a malicious proxy, where a forged certificate lets them read or change traffic. For the two code-signing intermediates, the risk is software that appears to come from a verified publisher. The exposure window opened in April 2025, when the keys were created, and closed per trust store as each blocked them.

Why the whole root went. Revocation of the eight intermediates came first, on 18 October 2026. Mozilla escalated to removing emSign ECC Root CA - G3 once "multiple individuals have independently recovered the private keys". Chrome describes its own response as "emergency containment" (comment 50).

Detection and evidence. The Chrome Root Program argued that the keys "could not have been exploited against Chrome users covertly without entering CT monitoring pipelines", because Chrome requires certificates to be logged (comment 50). That reasoning covers Chrome. A client that does not check CT gets no such protection. Practical steps:

  • Monitor CT for your domains and alert on any certificate whose issuer is one of the eight intermediates. Comment 0 lists their names, CCADB IDs and SHA-256 fingerprints; Jackson's site publishes them as impacted-intermediates.json, with the Sectigo cross-signs.
  • Test your clients. Jackson's site offers a checker and offline test chains (chains.zip). A client that completes a handshake with a test chain still trusts the compromised intermediates.
  • Inventory trust stores, not just certificates. JVM cacerts, Python certifi, Node.js's bundled store, container base images and appliance firmware each carry their own copy of the roots. Rebuild images after updating.
  • CAA records do not help here. They tell honest CAs whether they may issue for your domain. A forged certificate never consults them.

In practice: speed of response. Cloudflare's timeline runs from awareness on 19 October 2026 at about 17:00 UTC to "CDN and server-side Zero Trust mitigations fully deployed" at 19:20 UTC on 20 October, about 26 hours, with client updates in between (Cloudflare). eMudhra revoked the intermediates the morning after the report.

In practice: automation cuts both ways. eMudhra says about 97% of the roughly 30,000 certificates to migrate were issued via ACME (comment 19). ACME makes switching CA a configuration change. It also means many owners never chose eMudhra knowingly, so they may not know they are affected. Keep a second CA configured and tested in your ACME clients.

What to verify with your own team. Who owns the list of trust stores in your estate? How quickly can you push a root removal to all of them? Would anything alert you to a certificate for your domain from an unexpected issuer? The same inventory is the groundwork for post-quantum migration, covered in our post-quantum readiness checklist.

What is still open. eMudhra's full incident report, expected on 9 November 2026 after KPMG's review; Chrome's final decision on eMudhra's remaining roots; and who signed the certificates reported in comment 44, which the comment describes as almost all proof-of-concept.

Key takeaways

  • On 17 October 2026, a researcher reported that eight eMudhra intermediate CA keys were recoverable from public data because each was an integer below 256.
  • eMudhra revoked them on 18 October 2026; Mozilla removed trust in emSign ECC Root CA - G3, and Chrome committed to the same path.
  • About 30,000 certificates need replacing, eMudhra says.
  • No source we read reports an attack using the keys, as of 3 November 2026. Others signed 107,107 certificates with six of the keys after they became public, almost all proof-of-concept, per a Bugzilla comment.
  • Check the trust stores your software ships with, not only your operating system.

Sources

Read on 3 November 2026. The Bugzilla thread is long; facts above cite the comment they come from.

Spotted a mistake? Report a correction.