Eight CA keys smaller than 256: why eMudhra is leaving the TLS business

Summary

On 22 October 2026, the Indian certificate authority eMudhra announced that it is withdrawing from the global TLS certificate business. The trigger was an incident in which the private keys of eight intermediate certificates had been generated so weakly that anyone could recover them from the certificates and use them to issue certificates for any domain. This post puts the press release into context using Mozilla's bug report and shows why browsers were protected quickly while many other programs still need an update.

What happened

On 17 October 2026 at 18:05 UTC, a researcher who appears as Wayne in the Mozilla bug report told the root programs of Apple, Chrome, Microsoft and Mozilla, as well as eMudhra, that they held the private keys of eight eMudhra intermediate certificates. As proof, the message “We have a problem here” was signed with each key without handing over the keys themselves. Mozilla was able to recover the keys on its own at 21:48 UTC without any hint about the method and blocked the certificates via OneCRL by 22:59 UTC.

Six of the intermediate certificates are for TLS (DV, OV and EV, each in the G3B and G3C series) and were issued by the root emSign Root TLS CA - G3. It is cross-certified by emSign ECC Root CA - G3, which all four major root programs trusted. Two more are for code signing and were trusted by Microsoft. Sectigo had additionally cross-certified all eight via its root AAA Certificate Services, which Apple and Microsoft still trust; Sectigo revoked these cross-certificates on 19 October. eMudhra itself revoked the eight intermediates on 18 October between 09:24 and 09:38 UTC with the reason cACompromise.

How keys this weak could come about

A P-384 private key is a random number between 1 and the group order, a number with 116 decimal digits. According to Dennis Jackson of Mozilla, all eight affected keys were smaller than 256, so apart from the last byte they consisted of zeros. Anyone who knows this finds them almost instantly. Mozilla reports that local AI agents found them on the first attempt with a simple prompt.

The keys come from a key ceremony on 30 April 2025 that created 24 intermediate certificates in three series, each with RSA-4096 and P-384. Exactly the P-384 keys of series B and C are affected. According to eMudhra's preliminary account, correct keys were first created in the HSM. An approved deviation from the procedure was meant to test the export process (wrap/unwrap), because the keys were intended for data centres in the US and Europe. A flaw in the script created a second, weak key pair, which was used by mistake for the certificate signing requests because the labels were similar.

It remains open how a Utimaco HSM certified to FIPS 140-2 Level 3 could produce such keys at all. In the bug report, participants are asking for the ceremony script, the logs and the exact call that created the second key pair. One participant notes that a value below 256 cannot come from regular key generation inside the module, only from key material that was supplied or imported from outside.

Who was protected and who was not

Firefox and Chrome have blocked the intermediates since 17 October, Microsoft since the 20th and Apple since 22 October. Browsers fetch revocation information through their own channels such as OneCRL, CRLite and CRLSets. They also require Certificate Transparency: a certificate that is not in any public log is rejected. According to the information page on the incident, there are no log entries for these intermediates since April 2025, so as far as is known, browsers could not be attacked.

Things look different for programs that do not fetch revocation lists and do not check Certificate Transparency, such as curl, libraries with their own certificate list and Electron applications like Slack and Discord. They need a software update. On 20 October, Go released versions 1.27.3 and 1.26.10 with a fixed denylist in crypto/x509 (CVE-2026-111943); Python certifi, curl, Node.js, Electron and the Linux distributions followed. According to the information page, it is not known whether anyone exploited the weakness against such clients since April 2025.

Because several people had found the keys independently by then and mitmproxy added an option to sign with one of the keys, Mozilla removed all trust from the root emSign ECC Root CA - G3 on 20 October; Chrome announced the same. eMudhra stopped issuance under this root. By its own account, about 30,000 certificates have to move, about 97 percent of which were issued via ACME.

What the press release says

eMudhra justifies the exit with rising costs and requirements and with large providers issuing TLS certificates for free; the business brings in only about one percent of revenue. The RSA roots of the G1 generation are to keep running until the transition is complete, and affected customers are to receive replacement certificates from partners free of charge. Revocation services such as CRL and OCSP are to keep running until every issued certificate has expired or been replaced, and a full root-cause report for the root programs is to follow.

On 23 October, Mozilla noted that eMudhra had not yet answered questions sent on 20 October. Chrome rejected eMudhra's reference to pressure from social media and investors: the attention was the predictable result of its own failure, which had allowed anyone to issue certificates for any domain.

Ideas

• A key ceremony is only as secure as the script that drives it.
• Similar key labels in the HSM make mix-ups between test and production keys possible.
• A signed message proves key possession without revealing the key.
• Browsers block intermediates within hours, other clients need a software update.
• Certificate Transparency only protects clients that actually enforce it.
• Invalid CRL signatures can be an early sign of mismatched keys.
• A public checker shows admins in seconds whether a client still trusts.

Insights

• The weakness was not in P-384 but in the procedure: a test step created extra keys, and nobody checked which key went into the certificate signing request. Certified hardware does not protect against a wrong call and a missing cross-check.
• Revocation works unevenly. Browsers have their own revocation channels, while many runtimes, libraries and applications ship their own certificate lists that only a new release cleans up. That is why a mistake by a single CA requires updates for Go, Python and Electron.
• The warning sign was visible since June 2025: back then, the revocation lists of exactly these intermediates already had invalid signatures (Mozilla bug 1970728). According to eMudhra, they were then re-signed with the weak keys instead of getting to the bottom of the mismatch.

Quotes

• “However, the level of social media amplification around this incident has brought scrutiny that is out of proportion to SSL/TLS’s place in our business.” (eMudhra, press release of 22 October 2026)

Facts

• The report reached the root programs on 17 October 2026 at 18:05 UTC; Mozilla blocked the certificates via OneCRL by 22:59 UTC.
• The eight P-384 private keys were smaller than 256 and come from a ceremony on 30 April 2025.
• Six TLS and two code signing intermediates are affected, as are Sectigo's cross-certificates.
• According to eMudhra, about 30,000 certificates under the root emSign ECC Root CA - G3 have to move, about 97 percent issued via ACME.
• Go 1.27.3 and 1.26.10 block the intermediates in crypto/x509 (CVE-2026-111943).

References

• eMudhra: eMudhra to Exit global SSL/TLS Certificate Business
• Mozilla Bugzilla 2083449: eMudhra: Private key compromise of Intermediate Certificates
• eMudhra Intermediate CA Compromise: explanation, checker and patch status
• Go-Issue 82345: crypto/x509: mitigation for security concerns with a specific Certificate Authority
• oss-security: Go 1.27.3 and Go 1.26.10 are released for CA certificate removal
• mitmproxy: Add --emudhra option (#8500)

Critique

• The press release names neither the affected root nor the intermediates and does not tell customers how to check whether their certificates are affected. It partly attributes the withdrawal to social media attention, even though anyone could recover the keys.
• The statement that the infrastructure was not compromised is only formally true: no break-in was needed for misuse, because the keys were unusable from the moment they were generated.

Remarks

• The symbolic image is an allusion. Randomart as drawn by ssh-keygen represents the hash of the public key and would look unremarkable even for a key with almost no randomness; the label RSA 2048 does not match the affected P-384 keys either. That is exactly the point: weak keys do not stand out when you look at them.
• According to eMudhra, only one of the TLS intermediates (EM DV TLS CA - G3C) was in operation and no end-entity certificates were issued from it. Without a root-cause report, this cannot be verified independently.

Recommendations

• On servers, in containers and on clients, run curl https://dv-g3b-emudhra.we-have-a-problem.com/: a certificate error is the desired result, a loaded page means the client still trusts the compromised keys.
• Update the distribution's ca-certificates (Debian 13: 20250419+deb13u1), rebuild Go programs with 1.27.3 or 1.26.10 and bring Python certifi to 2026.10.19 or later.
• Search your own certificate lists in Java keystores, container images, appliances and applications with a bundled list for emSign ECC Root CA - G3; consider Electron applications clean only after their own update.
• If you obtain certificates from eMudhra or emSign via ACME, switch the ACME client to another CA now.

Read the press release →

Search the Web Archive

Links to the original source and the Web Archive open in a new tab.