Certificats eMudhra compromis : pourquoi vos serveurs sont concernés, pas seulement vos navigateurs

Toute la sécurité du web repose sur une chaîne de confiance. Votre navigateur fait confiance à quelques dizaines d'autorités de certification racines. Ces autorités signent des certificats intermédiaires, qui signent à leur tour les certificats des sites. Si la clé privée d'un intermédiaire est connue, n'importe qui peut fabriquer un certificat valide pour n'importe quel site.

C'est exactement ce qui s'est produit avec eMudhra, une autorité de certification indienne. L'incident a été géré très vite par les navigateurs, mais il montre que beaucoup d'autres logiciels dans l'entreprise gèrent leur propre liste d'autorités de confiance, et que personne ne les surveille.

Ce qui s'est passé

Le 17 octobre 2026, un chercheur a signalé aux programmes de certificats des navigateurs que les clés privées de huit certificats intermédiaires d'eMudhra étaient compromises. Pour le prouver, il a signé un message avec chacune d'elles. Un autre chercheur a ensuite montré qu'on pouvait retrouver les huit clés privées à partir des certificats publics, en moins d'une seconde.

Les clés n'ont pas été volées. Elles ont été générées avec trop peu d'aléa, au point que certaines correspondaient à de très petits nombres. Selon eMudhra, une erreur lors de la cérémonie de génération des clés, le 30 avril 2025, a produit un second jeu de clés faibles, et ce sont ces clés qui ont été publiées dans les magasins de confiance.

Les certificats concernés :

• six intermédiaires TLS (pour les sites web), rattachés à la racine emSign ECC Root CA G3 ;
• deux intermédiaires de signature de code.

Aucun faux certificat n'a été repéré dans les journaux publics de transparence des certificats. Mais les clés étaient calculables depuis avril 2025, et tous les certificats ne passent pas par ces journaux.

Une réaction rapide des navigateurs

• Chrome a bloqué les six intermédiaires TLS moins de deux heures après le signalement, et retire la racine emSign ECC Root CA G3 à partir du 27 octobre.
• Firefox a bloqué les certificats le soir même. Mozilla a ensuite retiré la racine de sa bibliothèque NSS.
• Apple et Microsoft ont bloqué les certificats les 19 et 20 octobre.
• Android a reçu un blocage par les services Google Play.

eMudhra a annoncé son retrait du marché mondial des certificats TLS. L'entreprise indique avoir émis plus de 60 millions de certificats au total. Selon les estimations publiées, environ 30 000 certificats de sites doivent être remplacés, alors qu'ils n'ont pas été compromis eux-mêmes, simplement parce que leur racine n'est plus reconnue.

Où se cache la confiance dans les certificats

Le vrai sujet : les magasins de confiance que personne ne voit

Les navigateurs vérifient la révocation des certificats et reçoivent des mises à jour automatiques. Beaucoup d'autres programmes, non. Ils utilisent leur propre liste d'autorités, figée au moment de leur installation ou de leur compilation. Tant que cette liste n'est pas mise à jour, ils continuent de faire confiance aux certificats compromis.

Voici les principaux endroits à vérifier dans une entreprise :

• Le système d'exploitation des serveurs : le paquet ca-certificates sous Debian, Ubuntu, Alpine, Fedora ou Red Hat.
• Les conteneurs : une image construite avant la mise à jour garde l'ancienne liste, même si le serveur qui l'héberge est à jour.
• Java : le JDK embarque son propre magasin cacerts, à mettre à jour avec le JDK.
• Python : la bibliothèque certifi est corrigée dans la version 2026.10.19. Certaines bibliothèques embarquent leur propre fichier de certificats.
• Node.js : corrigé dans les versions 22.23.4, 24.22.1 et 26.12.1.
• Go : corrigé dans les versions 1.27.3 et 1.26.10. Les applications doivent être recompilées. Les versions 1.25 et antérieures ne reçoivent pas de correctif.
• Les équipements et logiciels tiers : proxys, pare-feu qui inspectent le trafic chiffré, passerelles de messagerie, outils de supervision et applications métier embarquent souvent leur propre liste.

Le risque concret : un attaquant capable de se placer entre un serveur et un service distant, par exemple sur un réseau Wi-Fi ou via un DNS détourné, peut présenter un faux certificat signé avec une clé compromise. Un programme qui fait encore confiance à la chaîne eMudhra l'acceptera sans alerte et pourra lui envoyer des identifiants ou des données.

Le plan d'action

1. Mettre à jour les magasins de confiance connus

Mettez à jour ca-certificates sur tous les serveurs, reconstruisez les images de conteneurs à partir d'images de base corrigées, et mettez à jour les environnements Java, Python, Node.js et Go.

2. Chercher les magasins cachés

Recherchez les fichiers de certificats (PEM, keystores Java) présents dans le code, les images et les serveurs, et comparez leurs empreintes avec les racines concernées. Les bibliothèques qui embarquent leurs propres certificats ne se mettent pas à jour toutes seules.

3. Tester le comportement réel

Le site de divulgation de l'incident met à disposition des serveurs de test. Lancez une connexion depuis chaque application, dans son vrai environnement. Une erreur de certificat signifie que l'application rejette bien la chaîne compromise. Une connexion réussie signifie qu'elle lui fait encore confiance.

4. Remplacer les certificats rattachés à eMudhra

Si vous avez des certificats émis par eMudhra, remplacez-les par ceux d'une autre autorité avant leur rejet par les navigateurs. Pour Chrome, l'échéance est le 27 octobre.

5. Vérifier les équipements d'inspection TLS

Les pare-feu et proxys qui déchiffrent le trafic décident à la place des postes si un certificat est valide. Vérifiez que leur liste d'autorités est à jour, sinon ils pourraient valider un faux certificat et le re-signer avec votre propre autorité interne.

6. Regarder en arrière

Les clés étaient calculables depuis avril 2025. Pour les applications sensibles qui envoient des identifiants, examinez les journaux de proxy, d'inspection TLS et d'EDR à la recherche de certificats émis par les huit intermédiaires.

Ce que cet incident nous apprend

• La confiance est un actif à gérer. Chaque application qui fait des connexions chiffrées a une liste d'autorités de confiance. Elle doit figurer dans l'inventaire et dans le processus de mise à jour.
• Les conteneurs figent les vulnérabilités. Reconstruire régulièrement les images à partir de bases à jour est une mesure de sécurité, pas seulement d'exploitation.
• Votre propre PKI mérite la même rigueur. Si vous gérez une autorité de certification interne (pour le Wi-Fi 802.1X, le VPN ou les postes), la génération des clés, leur protection dans un module matériel (HSM) et la procédure de révocation doivent être documentées et testées.

Sources

• The Hacker News : huit clés d'autorités eMudhra compromises
• Endor Labs : les magasins de confiance oubliés
• eMudhra : déclaration officielle
• The Register : les clés privées d'eMudhra compromises

---

BigMind accompagne les entreprises dans la gestion de leurs certificats et de leur PKI interne : inventaire, renouvellement, protection des clés et automatisation. Parlons de votre situation.