eMudhra weak keys explained: 8 CA private keys under 256

Eight intermediate CA certificates from eMudhra (emSign) had P-384 private keys that were tiny numbers, such as 4, so the keys could be recovered from the public keys. eMudhra revoked all eight on 18 October 2026, and Mozilla and Google blocked the six TLS ones. Your action: update browsers, operating systems, runtimes and container images, and replace any certificate that chains to the emSign ECC Root CA - G3.

Does "4" mean four certificates were compromised?

No. "4" is the value of one private key. There were eight affected intermediate certificates, and Mozilla says the recovered private values were all below 256, per the Mozilla incident record and CERT-In.

An elliptic-curve private key should be a huge random number. These were small enough to guess. A key like that offers no secrecy, so anyone who worked it out could in principle sign a certificate that chains to the matching intermediate.

Which of the eight did browsers actually block?

Not all eight, according to the sources we read. They differ in wording, so here is each one with its date.

The two code-signing intermediates are the gap. At our checks on 24 and 28 October 2026, no source we read shows a browser or operating system block for them. The Mozilla record says Microsoft still trusted them when the report was filed. That is a trust-store question for code-signing, not for HTTPS, and eMudhra revoked both.

Who is affected?

Three groups, in different ways:

• Everyone who browses. The six TLS intermediates are blocked in Firefox and Chrome as dated above. Keep your browser and OS current.
• Site owners with an emSign certificate. If your certificate was issued under eMudhra's emSign ECC Root CA - G3 hierarchy, it will lose trust when the root is removed. The Mozilla record says eMudhra estimated about 30,000 certificates need migration and that it stopped issuing from that hierarchy. This is a replacement job and your server is not at fault. If you want to know how common bad certificates already are, how many sites run on expired certificates puts a number on it.
• Anyone running software with its own trust store. Mozilla says its NSS update helps applications that use a Mozilla-derived trust store and do not receive OneCRL updates. Red Hat says systems are at risk while the ca-certificates package still includes trust for the compromised certificates, and lists related CVEs for Go (CVE-2026-111943), Java (CVE-2026-91403) and Perl Mozilla::CA (CVE-2026-113812).

CERT-In says eMudhra's India-regulated DSC and eSign services are unaffected. That is CERT-In's report of eMudhra's position.

What are the traps with this incident?

1. Revoked and distrusted everywhere are different things. The certificates were revoked on 18 October. A client only rejects them if it receives that revocation data or a trust-store update. Old curl, wget, Java, Go and container setups can lag. Server-to-server calls can also break from the clientAuth removal that affects mTLS, a separate certificate change.
2. A browser check proves little about your servers. Your browser may be updated while the base image in your pipeline still carries the old bundle.
3. There is no confirmed attack, but forged certificates exist. CERT-In says the public disclosures it cites "do not establish confirmed malicious exploitation". Google reported no certificates chaining to the six TLS intermediates in Certificate Transparency logs before it blocked them. eMudhra says no affected intermediate issued end-entity certificates and only one was deployed in production. Those are eMudhra's statements as quoted by CERT-In. After the block, a commenter on the Mozilla record found 107,107 certificates signed with six of the keys in public logs. They show the keys were usable by anyone. See the section on exploitation below.

How do I fix it?

If you own a website with an emSign certificate

Open your site in a browser and view the certificate chain. If the root is emSign ECC Root CA - G3, or an issuer name contains eMudhra or emSign, ask your CA or reseller:

For [your domain], does my certificate chain to emSign ECC Root CA - G3 or to one of the eight revoked eMudhra intermediates? If so, please reissue it from a hierarchy that is not affected, and tell me the new chain and the date it is valid from.

• Read the issuer and root from the chain your server actually sends.
• Get a replacement from a CA whose root is unaffected. CERT-In advises replacing affected certificates, including legitimate ones that will lose trust.
• Install the new chain on every server, load balancer and CDN origin that holds the old one.
• Do not tell visitors to click through warnings. CERT-In advises against bypassing certificate warnings or disabling verification.

A certificate from another issuer can still chain to emSign ECC Root CA - G3, because third-party subordinate CAs such as InCommon's were issued under it (Chrome comment 30 on the Mozilla record, figures as of 21 October 2026, read at our check on 24 October 2026). Read the root of the chain your server sends, or ask the CA, before assuming you are clear.

If you run servers, runtimes or containers

Read at our check on 24 October 2026. The RHEL 10 erratum names CVE-2026-114406 and says it distrusts eMudhra intermediate CA certificates. The bulletin lists RHEL 6 and 7 as affected and names no erratum for them. Rebuilds of other distributions use their own package versions.

• Update the operating system trust package. On Red Hat family systems, run rpm -q ca-certificates and compare the version with the erratum for your release.
• Update language runtimes that ship their own handling. Red Hat lists CVEs for Go, Java and Perl Mozilla::CA. Read each project's own release notes for the fixed version.
• Rebuild and redeploy containers. Red Hat says to rebuild customer containers when the base image updates. A fixed base image does nothing until your image is rebuilt from it.
• Find bundles you maintain yourself: pinned CA files, appliances, embedded devices and applications with a private store. CERT-In lists these.
• Do not hand-delete trust entries on a workstation as a first move. Updates from your OS or browser vendor are the supported route.

Am I affected? A three-state self-test

Was anything exploited?

No attack on real visitors is confirmed in the primary sources. CERT-In says the public disclosures it cites do not establish confirmed malicious exploitation of the affected keys. That is a statement as of 21 October.

Forged certificates do exist, though. In comment 44 on the Mozilla record (25 October), a commenter reports that between 09:40 UTC on 20 October and 22:02 UTC on 21 October, 107,107 certificates signed with six of the eight keys were logged to e-Szignó's Certificate Transparency logs. The commenter says every signature verifies under the matching CA key. Of these, 106,050 are proof-of-concept certificates whose only name is google.com. Other examples named are emsign.filippo.io and precertificates for emudhra.salesforce.com. The commenter says almost none carries a revocation pointer, so a client that checks revocation only on the site certificate has nothing to check. Only clients that check every certificate in the chain, get a pushed blocklist or have dropped the root reject them. That is one commenter's count, not Mozilla's or Chrome's. eMudhra says in comment 43 that it issued no end-entity certificates from the eight CAs, and the commenter agrees that others did.

The keys were recoverable, so the risk was real while they were trusted. Update your trust stores. Do not rely on revocation checks alone.

If you want to watch for abuse, CERT-In suggests monitoring Certificate Transparency logs for unauthorized issuance for your domains, as a supplement to revocation and trust-store updates. A rogue Google certificate case and the CAA records shows what that monitoring can catch.

How did the keys end up so weak?

According to eMudhra, as quoted by CERT-In: "A flaw in the key generation ceremony caused a wrap / unwrap step to produce a second set of weak keys." Per the Mozilla record, the eight keys came from a batch of 24 intermediates generated on 30 April 2025, and eMudhra's comment attributes the weakness to a flaw in code during an approved test deviation. Those are eMudhra's explanations.

Mozilla says it recovered the keys itself, on 17 October at 21:48 UTC. Mozilla's comment 42 says it had no response to its questions as of 23 October, and Chrome's questions were also unanswered. On 25 October eMudhra said it had decided to exit the public TLS business and would file its full report within the 14-day CCADB window. On 27 October it said it had answered Mozilla's questions in direct correspondence and would work with the browser programs on what can be made public (comment 51). The same day, the Chrome Root Program said its review of Chrome-trusted CA certificates found no other weak CA keys known to its tool (comment 50). The incident bug was still open on 28 October 2026.

What happened, and when?

Back to the October 2026 incident tracker. If you run a small business site, our page on October 2026 incidents for small businesses says which of this week's items need your action. For how a CA is meant to generate keys, see how certificate authorities generate keys. More certificate stories sit in the other TLS guides.