Huit certificats intermédiaires de l’autorité indienne eMudhra reposaient sur des clés privées si faibles qu’on les retrouve en moins d’une seconde : les navigateurs ont retiré leur confiance à la racine emSign ECC Root CA – G3, Chrome l’a supprimée de son magasin le 27 octobre, et eMudhra quitte le marché mondial des certificats TLS. Pour un développeur ou un admin, l’essentiel est de vérifier ses chaînes de certificats et de mettre à jour les magasins de confiance qui ne vivent pas dans un navigateur.
- 8 intermédiaires eMudhra (6 TLS, 2 signature de code) avaient des clés privées inférieures à 256, dont l’une valait littéralement 4.
- Révocation le 18 octobre, racine emSign ECC Root CA – G3 retirée par Mozilla puis par Chrome (Root Store v43, 27 octobre).
- Environ 30 800 certificats en cours de validité sont à remplacer, presque tous émis pour le réseau universitaire américain InCommon.
- Mises à jour à faire : Go 1.27.3 ou 1.26.10, certifi 2026.10.19 ou plus récent, paquets ca-certificates du système.
Plan de l'article
Que s’est-il passé chez eMudhra ? #
Le 17 octobre 2026, un chercheur qui signe « Wayne » a passé la base commune des autorités de certification (CCADB) au crible d’un nouvel outil. En une demi-heure, il a repéré huit certificats intermédiaires eMudhra dont la clé privée pouvait être reconstituée à partir du seul certificat public.
À lire Tests fonctionnels : Comment garantir la fiabilité de vos applications
Il a prévenu Apple, Google, Microsoft, Mozilla et eMudhra à 18 h 05 UTC, preuves signées à l’appui. Mozilla a confirmé la faille de son côté à 21 h 48 UTC, sans aucune indication sur la méthode, et a bloqué les certificats dans Firefox via OneCRL avant minuit.
Le danger était maximal : quiconque détient la clé d’un intermédiaire reconnu par les navigateurs peut fabriquer un certificat HTTPS valide pour n’importe quel domaine, puis intercepter le trafic d’un site qu’il ne contrôle pas.
Comment une clé privée peut-elle valoir 4 ? #
Une clé privée sur courbe elliptique P-384 est censée être un nombre aléatoire de plus d’une centaine de chiffres. Celles d’eMudhra étaient toutes inférieures à 256 : il suffisait d’essayer au plus 256 valeurs. Le chercheur Scott Helme a résumé l’affaire : « L’une des clés privées d’autorité d’eMudhra est le nombre 4. » D’autres valaient 56 ou 115.
Selon le communiqué d’eMudhra, les clés ont été générées le 30 avril 2025 sur des HSM certifiés FIPS 140-2 niveau 3. Une étape de test d’export (wrap/unwrap) ajoutée à la cérémonie a produit un second jeu de clés, faibles, et ce sont elles qui ont été publiées. L’entreprise parle d’une erreur de script, restée invisible pendant environ 18 mois et deux cycles d’audit.
À lire DevOps et SRE : Synergies et Spécificités pour une Fiabilité Logicielle Maximale
Le détail qui inquiète les spécialistes : contrairement à un vol de clé, il n’y a ici ni voleur ni date de compromission. La clé était de fait publique dès la naissance du certificat. Google indique n’avoir trouvé aucun certificat émis par les six intermédiaires TLS dans les journaux publics Certificate Transparency avant son blocage du 17 octobre.
Qui a bloqué quoi, et quand ? #
| Date (2026) | Événement |
|---|---|
| 17 octobre | Signalement du chercheur, blocage des intermédiaires dans Chrome et Firefox |
| 18 octobre | eMudhra révoque les 8 intermédiaires (motif : compromission de l’autorité) |
| 19 octobre | Go publie en urgence les versions 1.27.3 et 1.26.10 |
| 20 octobre | Mozilla rend l’incident public et retire sa confiance à la racine emSign ECC Root CA – G3 |
| 22 octobre | eMudhra annonce qu’elle se retire du marché mondial des certificats SSL/TLS |
| 27 octobre | Chrome Root Store v43 en version stable, sans la racine G3 |
| 28 octobre | eMudhra détaille la migration des quelque 30 800 certificats concernés |
| 30 octobre | eMudhra nomme KPMG pour une revue indépendante de l’incident |
Apple et Microsoft ont suivi, Microsoft couvrant aussi les deux intermédiaires de signature de code. Sectigo, qui avait contre-signé ces intermédiaires en mai 2025, a révoqué ses contre-signatures.
Pourquoi les navigateurs ne suffisent pas à vous protéger #
Un navigateur à jour est protégé depuis le 17 octobre. Le risque se loge ailleurs : dans tout logiciel qui embarque sa propre liste d’autorités et ne consulte pas les révocations. Mozilla l’a dit sans détour : c’est pour ces clients-là qu’elle a retiré toute la racine G3 en urgence, et pas seulement les huit intermédiaires.
Le cas de Go est parlant. Sous Windows et macOS, la bibliothèque standard délègue la vérification au système, mais sous Linux elle utilise son propre vérificateur. L’équipe sécurité de Go a donc livré un correctif en moins de sept heures et demie, sa toute première publication sur la voie « URGENT », avec un message volontairement flou pour ne pas guider les attaquants.
Côté Python, le paquet certifi, utilisé par requests et une bonne partie de l’écosystème, a retiré toutes les racines emSign dans sa version 2026.10.18, puis rétabli la racine RSA G1, non touchée, dans la 2026.10.19. Les conteneurs, proxys, équilibreurs de charge et objets connectés figés sur un vieux magasin restent les angles morts.
Et moi concrètement, je dois faire quoi ? #
Si vous gérez un site en France, il y a peu de chances que votre certificat vienne d’eMudhra : selon les données Certificate Transparency citées sur le bugzilla de Mozilla, 99,9 % des certificats sous la racine G3 ont été émis pour InCommon, le réseau des universités américaines. Le vrai chantier est côté clients et serveurs.
- Go : passez au minimum à 1.27.3 ou 1.26.10, puis recompilez vos binaires, car le vérificateur est embarqué dans l’exécutable.
- Python :
pip install -U certifipour obtenir 2026.10.19 ou plus récent, et reconstruisez vos images Docker. - Système : mettez à jour le paquet ca-certificates de vos distributions et de vos images de base.
- Vérification :
openssl s_client -connect votre-domaine.fr:443 -showcertspuis cherchez « emSign » dans la chaîne retournée.
Pour intégrer ce type de contrôle dans une démarche de fiabilité plus large, notre article sur DevOps et SRE aide à organiser ce genre de veille. Voir aussi notre guide du développement en Go.
Que devient eMudhra ? #
Le 22 octobre, le conseil d’administration d’eMudhra a décidé de sortir du marché mondial des certificats SSL/TLS. Son président, V. Srinivasan, a indiqué à Help Net Security que cette activité pesait environ 1 % du chiffre d’affaires mondial du groupe, qui revendique plus de 60 millions de certificats numériques émis toutes activités confondues.
Dans sa mise à jour du 28 octobre, eMudhra précise que l’écosystème américain concerné émet désormais via sa racine RSA G1, que Mozilla n’a pas retirée, et que cette émission s’arrêtera une fois la transition terminée. Les clients TLS non concernés sont migrés gratuitement chez d’autres fournisseurs, notamment Sectigo.
L’affaire n’est pas close. Sur le bugzilla de Mozilla, les contributeurs pressent eMudhra de questions sur un autre problème de signature de liste de révocation, et sur le périmètre de la revue confiée à KPMG le 30 octobre. Le rapport complet d’analyse des causes doit être publié via la CCADB.
Questions fréquentes #
Mon navigateur est-il protégé contre les faux certificats eMudhra ?
Faut-il remplacer un certificat émis par eMudhra ?
Quelles versions de Go et de certifi corrigent le problème ?
À retenir #
- Une erreur de script lors d’une cérémonie de clés en avril 2025 a produit des clés privées d’autorité devinables en moins d’une seconde.
- La racine emSign ECC Root CA – G3 n’est plus reconnue par Firefox ni par Chrome depuis le 27 octobre 2026.
- Les risques résiduels sont dans les binaires Go, les images Docker et les équipements qui embarquent un vieux magasin de certificats.
- eMudhra quitte le TLS public et a confié à KPMG une revue indépendante le 30 octobre.
Sources : Mozilla Bugzilla, incident 2083449 ; communiqué d’eMudhra (mis à jour le 30 octobre) ; blog de Go, 26 octobre ; Help Net Security ; Keyfactor ; historique de certifi sur PyPI.
