--- title: "eMudhra: eight intermediate certificates with recoverable private keys" description: "The private keys of eight eMudhra intermediate certificates can be worked out from the certificates themselves, and Mozilla, Google, Apple and Microsoft blocked them between 17 and 20 October. Your browser is safe; everything else in your toolchain needs an update." canonical: https://inyourgeek.com/en/articles/2026-10-21-emudhra-huit-certificats-intermediaires-aux-cles-privees-recuperables type: article author: "Sébastien Soulier" publisher: "InYourGeek" language: en datePublished: 2026-10-21 dateModified: 2026-10-21 section: "Security" tags: ["tls", "certificats", "emudhra", "pki"] --- # eMudhra: eight intermediate certificates with recoverable private keys > The private keys of eight eMudhra intermediate certificates can be worked out from the certificates themselves, and Mozilla, Google, Apple and Microsoft blocked them between 17 and 20 October. Your browser is safe; everything else in your toolchain needs an update. October 21, 2026 · Security · 3 min On 20 October 2026, a dedicated site, [emudhra.we-have-a-problem.com](https://emudhra.we-have-a-problem.com/), went public with an incident reported to the root programmes on 17 October: the private keys of eight intermediate certificates belonging to the certificate authority eMudhra are compromised. Those intermediates chain up to roots trusted by the Mozilla, Microsoft, Apple and Chrome stores, as well as by many stores derived from them. The report also mentions Sectigo cross-signatures for the same intermediates. ## Keys you can read off the certificate According to the report, the private keys were generated incorrectly by the authority itself. The upshot: anyone can recover them from the certificates, with no break-in and nothing stolen. Think of a safe whose combination is engraved on the door. The person who filed the report proved the point by signing the same message with each of the eight keys; the verification archive and the matching OpenSSL commands are published on the site. The certificates were created in April 2025, and the weakness has been exploitable ever since. An attacker holding one of these keys could mint a valid certificate for any site or service and impersonate it. One detail offers partial comfort: the Certificate Transparency logs contain no entries for these intermediates over that period. Clients that require CT, meaning Firefox, Chrome, Edge and Safari, could therefore not have been targeted. For everything else, command-line clients, libraries, applications that never check CT, the report is blunt: nobody knows whether the flaw was exploited. ## Browsers have already pulled the plug The root programmes moved before the disclosure. The certificates have been blocked in Firefox and Chrome since 17 October, on Apple devices since 19 October and on Microsoft platforms since 20 October. Each vendor's own revocation channel, OneCRL, CRLite and CRLSets, pushed the block out. eMudhra, for its part, revoked all eight intermediates, and the derived trust stores were notified on 19 October. If you browse with an up-to-date browser on an up-to-date system, you are covered. The report's only advice is to update browsers and operating systems now rather than later. ## The real job: everything that isn't a browser The problem now shifts to software that ships its own list of trusted certificates and never consults any revocation data. For those, the authority's revocation changes nothing: only a package update removes the trust. Simon Willison sums it up on [his blog](https://simonwillison.net/2026/Oct/20/emudhra-certificates/): any software that bundles a list of trusted certificates needs updating. The site publishes a table of fixed versions, maintained through a GitHub repository. On the Linux side, Debian, Ubuntu, Fedora, Arch, Gentoo and Alpine have shipped new ca-certificates packages. On the tooling side, the versions to aim for are NSS 3.131.1, the curl CA bundle dated 20 October, Go 1.27.3 and 1.26.10, certifi 2026.10.19, pip 26.2.2, uv 0.13.4, rustls-webpki 0.103.16, webpki-roots 1.0.10 and Electron 44.9.1, 43.8.1 or 42.11.16. As of 20 October, Node.js, Bun and FreeBSD were still waiting for a fix. macOS deserves a line of its own: the system does block the intermediates, but the curl shipped in /usr/bin checks certificates against the file /etc/ssl/cert.pem, with no revocation check at all, and that file has not been updated. The site offers a procedure for stripping the affected roots out of it. ## Test your own stack The site provides twelve test hosts, one per affected chain. For a command-line client, a request to `https://dv-g3b-emudhra.we-have-a-problem.com/` should fail with a certificate error: that is the result you want. If the connection goes through, your client still trusts a compromised intermediate. An archive of the chains in PEM format lets you run the same check offline. The whole TLS trust chain rests on the assumption that every authority knows how to generate a key. Since 20 October, the job is to go through your tools one by one and make sure that assumption isn't still baked into some dependency you forgot you had. ## Sources - [eMudhra intermediate CA compromise](https://emudhra.we-have-a-problem.com/) — emudhra.we-have-a-problem.com - [eMudhra Intermediate CA Compromise](https://simonwillison.net/2026/Oct/20/emudhra-certificates/) — simonwillison.net _Article written with AI assistance from the cited sources, reviewed and approved by a human before publication._ --- Equivalent HTML page : https://inyourgeek.com/en/articles/2026-10-21-emudhra-huit-certificats-intermediaires-aux-cles-privees-recuperables Published by InYourGeek — https://inyourgeek.com/en/a-propos Method and safeguards : https://inyourgeek.com/en/methode All articles : https://inyourgeek.com/en/archives