eMudhra : huit certificats intermédiaires aux clés privées récupérables

Le 20 octobre 2026, un site dédié, emudhra.we-have-a-problem.com, a rendu public un incident signalé aux programmes racines dès le 17 octobre : les clés privées de huit certificats intermédiaires de l’autorité de certification eMudhra sont compromises. Ces intermédiaires chaînent vers des racines reconnues par les magasins de confiance de Mozilla, Microsoft, Apple et Chrome, ainsi que par de nombreux magasins dérivés. Le rapport mentionne aussi des signatures croisées de Sectigo pour ces mêmes intermédiaires.

Des clés qui se déduisent du certificat

Selon le rapport, les clés privées ont été incorrectement générées par l’autorité elle-même. Conséquence : n’importe qui peut les retrouver à partir des certificats, sans intrusion ni vol. La personne à l’origine du signalement en a apporté la preuve en signant un même message avec chacune des huit clés ; l’archive de vérification et les commandes OpenSSL correspondantes sont publiées sur le site.

Les certificats ont été créés en avril 2025, et la faiblesse était exploitable depuis cette date. Un attaquant disposant d’une de ces clés pouvait émettre un certificat valide pour n’importe quel site ou service et se faire passer pour lui.

Un élément rassure partiellement : les journaux de Certificate Transparency ne contiennent aucune entrée pour ces intermédiaires sur la période. Les clients qui exigent la CT, c’est-à-dire Firefox, Chrome, Edge et Safari, n’ont donc pas pu être visés. Pour tout le reste, clients en ligne de commande, bibliothèques, applications qui ne vérifient pas la CT, le rapport est explicite : on ignore si la faille a été exploitée.

Les navigateurs ont déjà coupé

Les programmes racines ont réagi avant la publication. Les certificats sont bloqués dans Firefox et Chrome depuis le 17 octobre, sur les appareils Apple depuis le 19 et sur les plateformes Microsoft depuis le 20. Les mécanismes de révocation propres à chaque éditeur, OneCRL, CRLite et CRLSets, ont diffusé le blocage. eMudhra a de son côté révoqué les huit intermédiaires, et les magasins de confiance dérivés ont été prévenus le 19 octobre.

Si vous naviguez avec un navigateur à jour sur un système à jour, vous êtes protégé. Le rapport recommande simplement de mettre à jour navigateurs et systèmes d’exploitation sans attendre.

Le vrai chantier : tout ce qui n’est pas un navigateur

Le problème se déplace vers les logiciels qui embarquent leur propre liste de certificats et ne consultent aucune information de révocation. Pour eux, la révocation par l’autorité ne change rien : seule une mise à jour du paquet retire la confiance. Simon Willison résume la situation sur son blog : tout logiciel qui embarque une liste de certificats de confiance doit être mis à jour.

Le site publie un tableau des versions corrigées, tenu via un dépôt GitHub. Côté distributions Linux, Debian, Ubuntu, Fedora, Arch, Gentoo et Alpine ont livré de nouveaux paquets ca-certificates. Côté outillage, les versions à viser sont NSS 3.131.1, le bundle CA de curl daté du 20 octobre, Go 1.27.3 et 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 et Electron 44.9.1, 43.8.1 ou 42.11.16. Au 20 octobre, Node.js, Bun et FreeBSD étaient encore en attente de correctif.

Le cas de macOS mérite une ligne : le système bloque bien les intermédiaires, mais le curl fourni dans /usr/bin vérifie les certificats contre le fichier /etc/ssl/cert.pem, sans contrôle de révocation, et ce fichier n’a pas été mis à jour. Le site propose une procédure pour en retirer les racines concernées.

Tester votre propre pile

Le site fournit douze hôtes de test, un par chaîne concernée. Pour un client en ligne de commande, une requête vers https://dv-g3b-emudhra.we-have-a-problem.com/ doit échouer avec une erreur de certificat : c’est le résultat attendu. Si la connexion aboutit, le client fait encore confiance à un intermédiaire compromis. Une archive de chaînes au format PEM permet le même contrôle hors ligne.

La chaîne de confiance TLS repose sur l’hypothèse que chaque autorité sait générer une clé. Depuis le 20 octobre, le travail consiste à vérifier, outil par outil, que cette hypothèse n’est plus codée en dur quelque part dans vos dépendances.