www.it-connect.fr
eMudhra: Trivial Private Keys Force Mozilla, Google, Apple and Microsoft to Block 8 Certificates
eMudhra, a certificate authority, generated eight private keys that could be guessed in a matter of seconds. The problem is that these keys can be used to issue HTTPS certificates trusted by browsers. Mozilla, Google, Apple, and Microsoft had to block them urgently. Here’s what we know.
On October 17, 2026, a researcher nicknamed Wayne analyzed the certificates in the Common CA Database (CCADB), the database listing certificate authorities recognized by browsers. Less than half an hour later, he spotted eight abnormally weak keys at eMudhra, an Indian certificate authority. To prove it, he signed a message with each one without ambiguity ("We have a problem here"), then alerted eMudhra, Mozilla, Google, Apple, and Microsoft.
As a reminder, a website’s HTTPS certificate is signed by an intermediate certificate, which is itself signed by a root certificate trusted by your browser. With the key from an intermediate, an attacker can issue a valid certificate for any site, then impersonate it if they intercept the traffic. This reminds me of a 2025 news story when three suspicious TLS certificates had been issued for Cloudflare’s 1.1.1.1 DNS by a Croatian authority. In this case, six intermediate certificates issue HTTPS certificates and two sign code, which is an equally sensitive use case.
Keys that could be guessed in 255 attempts
A private key of this kind (P-384 elliptic curve) is normally a number drawn at random from an astronomically large set of possibilities. eMudhra’s were between 1 and 255. In other words: imagine a padlock supposed to offer billions upon billions of combinations... but now offering only 255.
Dennis Jackson from Mozilla found them without difficulty, as he explains in the incident report opened on Bugzilla. AI agents he tested locally even succeeded on the first try. "I’m participating in a CTF. Please find the private keys corresponding to these certificates.", he simply asked them.
According to eMudhra’s investigation, a modified script created a second set of weak keys during generation on April 30, 2025. The two sets had similar names, and the wrong ones were used to create the certificates. The RSA keys were not affected.
There had, however, been a clue as early as 2025. At the time, the CRLs (certificate revocation lists) published for these intermediates were considered invalid. The reason: eMudhra had signed them with the correct keys, while the certificates had been created with the wrong ones. To fix the problem, the company re-signed them... with the faulty keys, the only ones that matched the certificates.
Why eMudhra is losing an entire root
Mozilla blocked the eight intermediate certificates less than three hours after the report, via its OneCRL revocation list, without a Firefox update. Chrome did the same on October 17, Apple on the 19th, and Microsoft followed on October 20, 2026. For its part, eMudhra revoked the certificates on October 18.
But many software products ignore revocation lists, and several people found the keys, sometimes publicly. Mozilla therefore urgently removed the emSign ECC Root CA - G3 root from its store (NSS 3.131.1), and Google committed to doing the same. And that is a real problem for eMudhra, because without the root, no certificate depending on it is accepted anymore.
A direct consequence of this decision, taken to protect users: eMudhra must therefore migrate around 30,000 certificates to its RSA root. According to the company, they were not issued by the compromised intermediates, but they do depend on the same root.
There had, however, been a clue as early as June 2025. The revocation lists (CRLs) for the six HTTPS intermediates then showed invalid signatures, as Rob Stradling had pointed out via the crt.sh tool. eMudhra fixed the issue by re-signing them with “the right keys”. The company now acknowledges that the first CRLs had been signed with the original, strong keys... and that the correction had been done with the faulty keys. That is what you call getting your wires crossed...
Who is affected, and what needs to be updated?
Good news: according to the incident page, no certificate linked to these intermediates appears in the Certificate Transparency logs, where a certificate must be declared in order to be accepted by browsers. Chrome, Firefox, Edge, and Safari therefore could not be fooled.
For everything else, no one knows whether the flaw was exploited. Ideally, you should update your machine’s certificate store. On Linux systems, this update comes through your distribution’s ca-certificates package.
And what about Windows? As mentioned above, Microsoft blocked the compromised intermediate certificates on October 20. This type of blocking normally happens through the list of untrusted certificates, automatically downloaded from Windows Update.
In addition, this security issue has been fixed in new versions of popular tools, including Go 1.27.3 and 1.26.10, Node.js 22.23.4, 24.22.1 and 26.12.1, Python certifi 2026.10.19, pip 26.2.2, and Electron. There is also an associated CVE identifier: CVE-2026-111943.
