eMudhra quitte le marché des certificats TLS après la découverte de huit clés intermédiaires devinables
Le 22 octobre 2026, l’autorité de certification indienne eMudhra annonce son retrait du marché mondial des certificats SSL/TLS, cinq jours après qu’un chercheur a retrouvé les clés privées de huit certificats intermédiaires, toutes inférieures à 256. Si votre organisation émet des certificats sous la racine emSign ECC Root CA - G3, vous avez jusqu’au 27 octobre pour basculer vers une autre hiérarchie.
17 octobre 2026. Un chercheur signale à Apple, Google, Microsoft, Mozilla et eMudhra qu’il a retrouvé les clés privées de huit certificats intermédiaires de l’autorité de certification indienne. 22 octobre 2026. Le conseil d’administration d’eMudhra décide de se retirer du marché mondial des certificats SSL/TLS. 27 octobre 2026. Chrome cessera de faire confiance à la racine emSign ECC Root CA - G3, au-dessus de ces intermédiaires. Pourquoi c’est important : une autorité de certification ne tombe pas sur un zero-day, elle tombe sur ses propres clés — et c’est la confiance de tout un écosystème qui s’effondre avec elle.
Huit clés privées « devinables » en un instant
Chaque clé privée d’un certificat intermédiaire devrait être un nombre aléatoire astronomiquement grand. Les huit clés récupérées étaient toutes inférieures à 256. N’importe qui pouvait les retrouver presque instantanément, sans factorisation ni calcul — une simple énumération de quelques centaines de valeurs. C’est l’équivalent cryptographique d’un coffre-fort dont la combinaison est réglée sur « 000 ».
Six de ces huit certificats étaient des intermédiaires TLS destinés à la délivrance de certificats de sites web. Les deux autres relevaient d’autres usages. Le chercheur a rapporté les clés faibles le 17 octobre ; Chrome et Firefox ont bloqué les six intermédiaires TLS « en quelques heures ». Aucun certificat de site web émis par eux n’était apparu dans les journaux publics de Certificate Transparency avant le blocage, ce qui signifie qu’aucun n’a pu être utilisé contre Chrome ou contre les logiciels qui exigent la journalisation CT.
eMudhra affirme que ses systèmes n’ont pas été compromis et qu’elle n’a jamais utilisé ces huit clés pour émettre des certificats à destination de sites ou d’utilisateurs. Le problème n’est donc pas une intrusion : il est structurel. Une autorité qui génère des clés inférieures à 256 a un défaut de génération d’aléa, pas un problème de pare-feu.
La racine qui entraîne 30 800 certificats
Le retrait d’une racine d’un navigateur coupe aussi les certificats légitimes émis en dessous d’elle. D’après le décompte de Chrome dans les journaux CT, environ 30 800 certificats non expirés étaient rattachés à cette racine au 21 octobre. Le chiffre le plus frappant est ailleurs : 99,9 % de ces certificats ont été émis via InCommon, le service de certificats qu’Internet2 a créé pour la communauté de l’enseignement supérieur.
InCommon a migré son service vers la plateforme CertiNext d’eMudhra entre avril et juillet 2026. Autrement dit, des universités et des institutions de recherche nord-américaines — Cornell, Stanford, l’Université du Michigan sont nommées dans les échanges publics — se retrouvent embarquées dans une sortie de scène qu’elles n’ont pas choisie. Cornell compte à elle seule plus de 300 certificats affectés et recommande désormais à ses titulaires de demander des certificats RSA plutôt qu’ECC, car « les certificats RSA utilisent la racine non affectée d’eMudhra et devraient fonctionner ».
Google a été direct avec les opérateurs concernés : ils doivent « immédiatement acquérir et installer un nouveau certificat TLS depuis une autre hiérarchie PKI incluse dans le Chrome Root Store ». Le délai est court — la matinée du 27 octobre, heure du Pacifique — et il ne se négocie pas.
Une migration piégée par l’automatisation
eMudhra estime qu’environ 30 000 certificats doivent être déplacés, et qu’environ 97 % d’entre eux ont été émis via ACME, le protocole qu’utilisent la plupart des serveurs pour demander et renouveler leurs certificats automatiquement. C’est là que la sortie de route devient piégeuse.
Chrome a prévenu eMudhra que les clients ACME standards ne remplacent pas un certificat en dehors de sa fenêtre de renouvellement, sauf s’ils prennent en charge l’extension ACME Renewal Information (ARI) ou qu’une intervention manuelle force le remplacement. Basculer de la hiérarchie ECC vers la hiérarchie RSA peut aussi exiger des changements de configuration côté client. La conclusion est brutale pour un administrateur : l’automatisation qui vous a fait gagner du temps ces dernières années ne vous sauvera pas cette fois — il faudra, dans beaucoup de cas, mettre les mains dans la configuration.
Le plan de sortie d’eMudhra reste flou sur plusieurs points. L’entreprise continuera d’exploiter ses services de révocation et de statut jusqu’à l’expiration ou au remplacement de tous ses certificats SSL/TLS. Ses racines RSA G1 continuent de servir, mais Chrome n’a pas encore décidé s’il conserve les certificats restants d’eMudhra dans son magasin racine. L’annonce ne mentionne pas InCommon, ni si l’entreprise continuera d’émettre de nouveaux certificats sous G1 jusqu’à sa sortie.
Le précédent de 2025 qui aggrave le dossier
Cette affaire n’est pas le premier signal d’alarme. En 2025, eMudhra avait publié des CRL invalides pour six de ces mêmes intermédiaires. Son rapport d’incident de l’époque affirmait les avoir corrigées en « régénérant les CRL avec la clé privée appropriée de chaque autorité intermédiaire ».
Le 19 octobre 2026, eMudhra a précisé à Mozilla que ces listes avaient d’abord été signées avec les clés prévues, puis, face à des signatures invalides, « re-signées avec des clés défaillantes » — précisément les clés faibles retrouvées ce mois-ci. Le 14 octobre, l’entreprise avait publié une CRL pour emSign Root TLS CA - G1 dont la signature ne se vérifie pas avec la clé de cette autorité ; un participant au fil de discussion a estimé le 22 octobre qu’elle semblait signée avec la clé d’un certificat OCSP — « un cas de mauvaise clé de signature, plutôt qu’une preuve d’une autre clé faible ».
Chrome a relevé ces incohérences dans douze questions posées le 21 octobre, notamment : pourquoi le rapport de 2025 ne mentionnait pas l’existence de deux paires de clés pour chacune de ces autorités. « Cela soulève de sérieuses inquiétudes quant à la transparence d’eMudhra et à sa gestion d’incident », écrit Chrome. Au 22 octobre à 13 h 31 UTC, eMudhra n’avait répondu publiquement à aucune de ces questions.
La génération de clés, couronne d’une autorité de certification
Il faut distinguer deux scénarios qu’on confond trop souvent. Une autorité compromise par une intrusion conserve en principe des clés fortes : l’attaquant a volé un secret solide, et la remédiation consiste à révoquer puis à ré-émettre. Une autorité qui génère des clés faibles est un cas bien pire : le défaut est dans le processus même de création du matériel cryptographique, et rien ne garantit que les huit clés retrouvées soient les seules concernées.
C’est ce qui rend la question posée par Chrome — « détenez-vous plus d’une paire de clés pour cette autorité, ou pour l’une de vos racines ? » — si dangereuse. Si une génération défaillante a produit huit clés inférieures à 256, elle a pu en produire d’autres, sur d’autres hiérarchies, y compris G1, que Chrome n’a pas encore décidé de conserver. L’absence de réponse publique d’eMudhra n’est pas un détail de communication : c’est précisément l’information qu’un RSSI doit exiger avant de ré-émettre des certificats sous une racine du même éditeur.
La leçon dépasse eMudhra. Le TLS public repose sur un petit nombre d’autorités dont la qualité de génération d’aléa n’est auditable que de l’extérieur, à travers les journaux CT et les contrôles des navigateurs. Quand cette qualité défaille, la sanction est binaire — retrait du magasin racine — et collective : 30 800 certificats légitimes tombent avec la racine fautive. C’est exactement ce mécanisme de sanction distribuée que nous décrivions dans notre analyse des racines publiques de Cloudflare, mais il s’applique ici à un éditeur qui, lui, n’avait pas prévu la sortie.
Verdict
Si vous émettez ou détenez des certificats chaînés sous emSign ECC Root CA - G3, vous avez jusqu’au 27 octobre. Vérifiez votre chaîne immédiatement — openssl s_client -connect votre-domaine:443 -showcerts — et basculez vers une autre hiérarchie, de préférence Let’s Encrypt si votre parc le permet, comme le recommande déjà l’Université du Michigan. Si vous êtes une institution InCommon, le chemin le plus sûr est la hiérarchie RSA G1 à court terme et une sortie d’eMudhra à moyen terme : Chrome n’a pas promis de conserver G1, et la confiance ne se reconquiert pas en un trimestre. Si vous n’êtes pas concerné, retenez quand même la leçon structurelle : la chaîne de confiance TLS repose entièrement sur la qualité de génération de clés de quelques autorités, et un navigateur peut faire tomber une hiérarchie entière en une nuit. C’est le sujet de fond de notre analyse des racines publiques de Cloudflare : le pouvoir de révocation est désormais distribué, mais la responsabilité d’une clé faible reste, elle, entièrement centralisée.