Clés de CA d'eMudhra compromises : Go, Firefox et NSS publient des correctifs

Les clés privées de huit certificats intermédiaires d'eMudhra, une autorité de certification indienne, ont été exposées, ont confirmé Mozilla et Google le 20 octobre 2026. Quiconque détient ces clés pourrait émettre des certificats HTTPS acceptés par les navigateurs pour des sites qui ne lui appartiennent pas. Les navigateurs ont bloqué les certificats en quelques heures, mais de nombreuses applications hors du navigateur restent exposées jusqu'à leur mise à jour.

Ce qui est arrivé aux clés d'eMudhra

Une autorité de certification, ou CA, se porte garante des sites web en signant leurs certificats. Les grandes CA signent au moyen de certificats « intermédiaires », placés entre leur racine et chaque site web. Si la clé privée d'un intermédiaire fuit, un attaquant peut fabriquer un certificat d'apparence valide pour n'importe quel domaine.

Un chercheur a signalé les huit clés aux éditeurs de navigateurs le samedi 17 octobre. Il l'a prouvé en signant un message avec chaque clé : « We have a problem here - Wayne. » (Nous avons un problème ici - Wayne.) Six des intermédiaires émettent des certificats de sites web (TLS) et deux signent du code logiciel, rapporte The Hacker News.

Les clés étaient aussi faibles, selon le chercheur en sécurité Scott Helme. Chacune était un nombre minuscule, et il a retrouvé les clés privées des 16 certificats liés en moins d'une seconde. Les intermédiaires datent d'avril 2025 : n'importe qui aurait donc pu en faire autant pendant environ 17 mois. Helme cite l'explication d'eMudhra : un bug de script a créé une seconde paire de clés, faible, et le personnel a choisi la mauvaise, car les noms se ressemblaient.

Selon The Hacker News, on ignore comment les clés sont sorties d'eMudhra et qui d'autre les détient. L'analyse de Helme ajoute qu'il est impossible de savoir si quelqu'un les a retrouvées avant aujourd'hui.

Le 22 octobre, eMudhra a annoncé quitter entièrement le marché mondial des certificats SSL/TLS, comme l'explique eMudhra quitte le marché mondial des certificats SSL/TLS après sa faille de clés faibles.

La vitesse de réaction de chaque éditeur

Quand (UTC)	Action
17 octobre, 18:05	Le programme de racines de Chrome reçoit le signalement
17 octobre, 19:45	Chrome bloque les six intermédiaires TLS via CRLSet, sa liste de révocation
17 octobre, 20:06	Mozilla reçoit le signalement
17 octobre, 22:59	Le blocage OneCRL de Firefox atteint les utilisateurs aux réglages standard
19 octobre	Apple bloque les certificats
20 octobre	Microsoft les bloque ; les versions de Go, Firefox et NSS sont publiées

Mozilla indique que Firefox n'a eu besoin ni de mise à jour ni de redémarrage pour le blocage. Mozilla a aussi publié Firefox 158.0.1, ESR 115.43.1 et ESR 153.5.1 pour les utilisateurs dont les réglages personnalisés bloquaient les mises à jour de OneCRL. NSS 3.131.1, la bibliothèque de sécurité de Mozilla, retire la racine emSign ECC Root CA - G3, qui a signé les intermédiaires. Chrome retirera la même racine dans la version 43 du Chrome Root Store.

Chrome n'a pas bloqué les deux intermédiaires de signature de code, car ses vérifications de sites web n'y passent jamais. Chrome a aussi indiqué avoir contrôlé toutes les autres CA de son magasin et n'avoir « trouvé aucun autre cas de ce mode de défaillance ». Aucun certificat de site web journalisé ne remontait aux six intermédiaires TLS avant le blocage de Chrome, rapporte The Hacker News.

Pourquoi les applications hors du navigateur restent exposées

Les navigateurs reçoivent automatiquement les listes de blocage. La plupart des autres logiciels ne vérifient pas du tout la révocation. Ils font confiance à une liste de CA intégrée jusqu'à ce que quelqu'un en livre une nouvelle.

Helme l'a testé avec un certificat falsifié pour api.stripe.com. Avec les réglages par défaut, curl, Python et Node l'ont accepté sous Linux et macOS. Sous Windows, la bibliothèque cryptographique du système l'a accepté, sauf si la vérification de révocation était activée.

Go a eu besoin d'une modification de code pour la même raison, explique Cyber Kendra. Son vérificateur de certificats ne lit pas les listes de blocage des navigateurs, donc les programmes Go font confiance aux clés jusqu'à leur recompilation. Voici les versions corrigées citées dans les différents articles :

Logiciel	Version corrigée
Go	1.27.3 et 1.26.10 (CVE-2026-111943) ; 1.25 et antérieures ne sont plus prises en charge
Firefox	158.0.1, ESR 115.43.1, ESR 153.5.1
NSS	3.131.1
Python certifi	2026.10.19
Rust webpki-roots	1.0.10
Electron	44.9.1, 43.8.1, 42.11.16

Ce que cela signifie pour les développeurs

Les navigateurs sont couverts. Vos serveurs, outils de build et conteneurs ne le sont probablement pas, tant que vous ne les mettez pas à jour.

• Recompilez vos services Go. Un binaire Go embarque ses propres vérifications de certificats. Recompilez avec Go 1.27.3 ou 1.26.10 et redéployez ; mettre à jour la seule liste de CA de la machine n'aide pas.
• Mettez à jour les listes de CA intégrées. Mettez à jour certifi dans les projets Python, webpki-roots en Rust et Electron dans les applications de bureau. Reconstruisez les images de conteneurs pour qu'elles récupèrent le nouveau bundle système. Les versions de Python du 21 octobre intègrent le correctif pour les nouvelles installations, comme l'explique Python 3.15.1, 3.14.9 et 3.13.17 livrent pip 26.2.2.
• Inspectez vos propres chaînes. Si un fournisseur ou un service interne utilise un certificat eMudhra, sachez-le avant que les racines disparaissent. Collez un certificat dans un décodeur de certificats et lisez son champ d'émetteur.
• Activez la vérification de révocation là où c'est possible. Le test de Helme sous Windows n'a détecté le certificat falsifié qu'avec la vérification de révocation activée. Considérez ce réglage comme une partie de votre configuration TLS, pas comme un bonus.