Certificats TLS : n’importe qui pouvait certifier un site via des clés passoires
eMudhra, une entreprise indienne qui se targue d’avoir délivré plus de 60 millions de certificats numériques, utilisait des clés privées très mal générées. Résultat : n’importe qui pouvait les utiliser pour certifier un site.
Huit clés privées utilisées par l’autorité de certification indienne eMudhra pour émettre des certificats TLS présentaient des failles majeures. Ces clés, générées en avril 2025, étaient si mal conçues que leur sécurité était quasi inexistante. Par exemple, l’une d’elles se réduisait au simple chiffre 4, une autre à 56, et une troisième à 115. Normalement, une clé sécurisée pour ce type de certificat (courbe elliptique P-384) devrait comporter 384 bits, soit 48 octets. Or, dans ces cas, seuls les derniers octets étaient utiles, les autres étant remplis de zéros. Retrouver ces clés ne nécessitait donc au maximum que 255 essais, ce qui les rendait extrêmement faciles à pirater. Ces clés permettaient à un attaquant de créer des certificats frauduleux pour n’importe quel site web, comme une banque ou un service en ligne, afin d’intercepter ou de modifier les communications.
Les certificats TLS (Transport Layer Security) sont essentiels pour sécuriser les communications sur Internet, notamment via le protocole HTTPS. Ils permettent à un utilisateur de vérifier l’identité d’un site web en s’appuyant sur une autorité de certification (CA, Certificate Authority) qui signe ces certificats avec une clé privée. Si une clé privée est compromise, un pirate peut émettre des certificats frauduleux et se faire passer pour un site légitime. Par exemple, un utilisateur pourrait croire visiter le site de sa banque, alors qu’il est en réalité redirigé vers une page malveillante contrôlée par l’attaquant. Ce risque d’usurpation d’identité (spoofing) menace la sécurité des transactions en ligne, des échanges de données sensibles et de la confidentialité des utilisateurs. Les huit clés d’eMudhra exposaient l’ensemble d’Internet à ce danger pendant 17 mois, jusqu’à leur révocation.
Dès le 17 octobre 2026, les principaux éditeurs de navigateurs (Mozilla, Google, Apple et Microsoft) ont réagi à la compromission des clés d’eMudhra. Mozilla a bloqué les certificats concernés dans Firefox via son système OneCRL en moins de trois heures après avoir été alerté. Google a fait de même pour Chrome via CRLSet, tandis qu’Apple et Microsoft ont désactivé ces certificats sur leurs plateformes. Les navigateurs ont également retiré le certificat racine d’eMudhra de leurs listes de confiance. Ces mesures visaient à empêcher l’utilisation de certificats frauduleux émis via les clés compromises. Les navigateurs appliquent aussi la transparence des certificats (Certificate Transparency), une technologie qui enregistre publiquement tous les certificats émis, permettant de détecter les anomalies. Aucun certificat frauduleux n’avait été enregistré avant le blocage, limitant ainsi les risques pour les utilisateurs.
Si les navigateurs ont rapidement bloqué les certificats compromis, d’autres services et logiciels moins protégés restent vulnérables. La plupart des outils utilisant des certificats TLS (comme curl, Python, Node.js, Go, Java, git, ou les gestionnaires de paquets) font confiance par défaut à un ensemble de clés racines stockées sur l’ordinateur. Ces outils ne vérifient pas toujours la révocation des certificats (leur invalidation en cas de compromission) ni leur enregistrement dans la transparence des certificats. Certains ont déjà publié des correctifs, comme Go, Python (certifi), ou Rust (webpki-roots). Cependant, les appareils ou logiciels ne pouvant pas être mis à jour continueront de faire confiance à ces clés jusqu’à leur expiration en juillet 2039. Les utilisateurs sont donc encouragés à mettre à jour tous leurs outils pour limiter les risques.
L’entreprise indienne eMudhra, basée en Inde, a reconnu l’incident le 20 octobre 2026 et affirme que sept des huit clés intermédiaires n’ont jamais été utilisées en production. Selon elle, seule une clé a été employée en production, mais n’a délivré aucun certificat. L’entreprise a révoqué ces clés et affirme avoir généré ses clés sur des **modules de sécurité matériels** (*HSM*, *Hardware Security Modules*) certifiés **FIPS 140-2 niveau 3**, des dispositifs conçus pour protéger les clés cryptographiques. Cependant, eMudhra admet qu’une faille dans une étape de génération des clés a conduit à la création d’un second jeu de clés, plus faibles, qui ont été publiées par erreur. L’enquête se poursuit pour déterminer l’origine exacte de cette faille. Pendant 17 mois, quiconque possédait ces clés pouvait émettre des certificats frauduleux, comme l’a démontré un chercheur en testant la création d’un certificat pour le site de paiement **Stripe**.
