eMudhra : huit autorités de certification signaient avec une clé de 256 valeurs possibles

Le samedi 17 octobre 2026 à 18 h 05 UTC, un chercheur indépendant qui signe Wayne a écrit à Apple, Google, Microsoft, Mozilla et à l’autorité de certification indienne eMudhra. Son message contenait, comme preuve, un texte signé avec la clé privée de chacune de huit autorités de certification intermédiaires d’eMudhra. Une autorité de certification est l’organisme dont la signature fait accepter par un navigateur le certificat HTTPS d’un site. Détenir la clé privée d’une autorité reconnue permet donc de fabriquer un certificat valide pour n’importe quel domaine, puis d’intercepter des connexions chiffrées sans déclencher d’alerte. Chrome a bloqué les six autorités servant au web moins de deux heures plus tard, et Firefox à 22 h 59 UTC.

Lors de la cérémonie de création de ces clés, en avril 2025, une erreur de script les a réduites à un nombre inférieur à 256, alors qu’une clé de ce type se choisit parmi environ 2³⁸⁴ valeurs : il suffisait de les essayer toutes pour les retrouver, sans avoir à s’introduire chez eMudhra. Ce défaut avait produit dès mai 2025 un symptôme public, qu’eMudhra a fait disparaître sans en chercher la cause. Les navigateurs ont protégé leurs utilisateurs en quelques heures ; beaucoup de logiciels qui embarquent leur propre liste d’autorités, en revanche, ne consultent pas la révocation et acceptent ces chaînes tant qu’ils ne sont pas mis à jour.

Nous avons repris les sources primaires (rapports d’incident de 2025 et 2026 dans le Bugzilla de Mozilla, liste dev-security-policy, annonces de Mozilla et de Go, certificats servis par le site de suivi de l’incident) pour établir les faits, la cause déclarée par eMudhra et les vérifications à mener.

Huit autorités intermédiaires, deux chaînes de confiance

Un navigateur fait confiance à une liste restreinte de certificats racines, conservés hors ligne par les autorités. Ces racines signent des autorités intermédiaires, opérées en ligne, qui signent à leur tour les certificats des sites. Le 30 avril 2025, eMudhra a créé d’un coup 24 intermédiaires, répartis en trois séries (A, B, C) et deux types de clés (RSA et courbe elliptique P-384). Les huit clés défectueuses sont toutes les clés P-384 des séries B et C : six autorités TLS, au nom d’eMudhra BV aux Pays-Bas (G3B) et d’eMudhra Inc aux États-Unis (G3C), et deux autorités de signature de code. Selon eMudhra, ces séries devaient être exportées vers ses centres de données européen et américain pour répondre aux exigences de souveraineté des données de certains clients ; une seule a été mise en service, sans émettre aucun certificat final.

Ces intermédiaires disposent de deux chemins vers une racine reconnue. Le premier passe par emSign Root TLS CA - G3, une racine de 2024 elle-même certifiée par emSign ECC Root CA - G3, présente dans les magasins de Mozilla, Chrome, Apple et Microsoft. Le second date du 14 mai 2025 : Sectigo a alors certifié les huit intermédiaires depuis AAA Certificate Services, une racine Comodo de 2004. Cette certification croisée permet aux appareils anciens qui ignorent les racines d’eMudhra d’accepter ses certificats. AAA Certificate Services a été retirée de Chrome et de Firefox, mais Apple et Microsoft la reconnaissent toujours, comme de nombreux magasins système (les contournements publiés pour Debian, Ubuntu ou macOS la désactivent explicitement).

Une clé privée réduite à son dernier octet

Sur la courbe P-384, c’est la taille de l’intervalle dans lequel la clé privée est tirée qui empêche de la déduire de la clé publique. Les huit clés en cause étant toutes inférieures à 256, il suffit de calculer les 256 premières clés possibles et de comparer leurs clés publiques à celles des certificats. Dennis Jackson, l’ingénieur de Mozilla qui a ouvert le rapport d’incident, les a retrouvées moins de deux heures après avoir reçu le signalement, sans connaître la méthode du chercheur, et des agents d’IA exécutés en local y sont parvenus du premier coup avec une consigne d’une ligne. Le site de suivi de l’incident en fait la démonstration : ses hôtes de test servent des certificats émis le 20 octobre 2026 par ces autorités, donc signés avec les clés recalculées.

Selon les explications préliminaires publiées par eMudhra le 19 octobre, l’erreur vient du script de la cérémonie. Les clés ont été générées dans des HSM Utimaco certifiés FIPS 140-2 niveau 3, ces boîtiers matériels conçus pour qu’une clé privée y soit créée sans jamais en sortir en clair. Comme ces autorités devaient être exportées, une dérogation approuvée a ajouté au script un test d’export et de réimport des clés (wrap/unwrap). Un défaut de ce code a créé dans le HSM une seconde paire de clés, faible, dont les libellés ressemblaient à ceux des bonnes clés. C’est elle qui a servi à produire les demandes de certificat, signées par la racine d’eMudhra puis transmises à Sectigo.

eMudhra affirme que ses clés RSA et sa série A, générée sur des HSM Entrust pour l’Inde, ne sont pas touchées ; Mozilla n’a pas retrouvé les clés P-384 de cette série, mais n’avait pas encore examiné les clés RSA au 18 octobre. L’autorité reconnaît des erreurs humaines à plusieurs étapes et annonce la revérification de toutes ses cérémonies sous une semaine.

L’alerte de mai 2025, corrigée dans le mauvais sens

Le 5 juin 2025, Sectigo a signalé dans le Bugzilla de Mozilla (bug 1970728) que six listes de révocation d’eMudhra portaient des signatures ECDSA invalides : il s’agissait des six autorités TLS révoquées en octobre 2026. Une liste de révocation (CRL) est signée avec la clé privée de l’autorité, et une signature qui ne se vérifie pas avec la clé publique du certificat signifie que la clé utilisée n’est pas celle du certificat. eMudhra avait alors invoqué une erreur de configuration lors d’une signature manuelle du 29 mai, régénéré les listes avec la clé jugée appropriée, automatisé la procédure et ajouté un contrôle de signature après coup. L’incident a été clos en juillet 2025. Le premier signalement de Sectigo, envoyé le 3 juin, posait pourtant déjà la bonne question en demandant si ces listes avaient été signées avec la mauvaise clé privée ; bloqué par les filtres d’eMudhra, il est resté sans réponse et a donné lieu à un second incident.

En octobre 2026, eMudhra a décrit cet épisode autrement : les listes avaient d’abord été signées avec les clés d’origine, robustes ; comme ces signatures ne se vérifiaient pas, elles ont été refaites avec les clés faibles, les seules qui correspondaient aux certificats. Le symptôme visible du défaut a donc été traité comme une erreur de manipulation, et la correction a aligné la procédure sur les clés défectueuses ; le contrôle automatique ajouté ensuite vérifiait la cohérence avec des certificats eux-mêmes bâtis sur la mauvaise clé. Mozilla relève en outre, archive de crt.sh à l’appui, que les échecs de vérification apparaissaient dès le 23 mai, avant la date avancée par eMudhra.

Le dossier s’inscrit dans une série, puisque le Bugzilla de Mozilla recense 19 incidents de conformité ouverts au nom d’eMudhra entre janvier 2025 et le 16 octobre 2026, dont sept depuis le 18 septembre (tailles de clés non autorisées, extensions manquantes ou interdites, certificats dont la validité dépassait d’une seconde le maximum prévu, documents de politique non mis à jour).

Trois heures pour les navigateurs, des semaines pour le reste

Date (UTC)	Événement
30 avril 2025	Cérémonie de clés : 24 intermédiaires créés, dont les huit défectueux
14 mai 2025	Certification croisée par Sectigo depuis AAA Certificate Services
23 mai au 6 juin 2025	Listes de révocation à signature invalide, signalées par Sectigo puis re-signées avec les clés faibles
17 oct. 2026, 16 h 27	Wayne détecte la faiblesse en testant les clés publiées dans la CCADB, la base commune des programmes racines
17 oct., 18 h 05	Signalement aux quatre programmes racines et à eMudhra, avec une preuve signée par chaque clé
17 oct., 19 h 45	Chrome bloque les six autorités TLS par CRLSet, certificats croisés de Sectigo compris
17 oct., 22 h 59	Firefox les bloque par OneCRL
18 oct., 9 h 24 à 9 h 38	eMudhra révoque les huit intermédiaires
19 oct.	Apple bloque les intermédiaires ; Sectigo révoque ses huit certificats croisés ; Mozilla prévient les distributeurs de son magasin sans décrire la faille
20 oct.	Plusieurs personnes ont recalculé les clés, certaines publiquement : Mozilla retire la racine emSign ECC Root CA - G3 (NSS 3.131.1), Chrome annonce le même retrait, eMudhra cesse d’émettre sous cette racine

Les navigateurs poussent eux-mêmes leurs listes de révocation à leurs utilisateurs (CRLSet pour Chrome, OneCRL et CRLite pour Firefox), sans mise à jour du logiciel. Les deux autorités de signature de code ne relèvent que du programme de Microsoft, et aucune mesure de Microsoft n’apparaît dans les sources publiques consultées au 20 octobre. Go a publié en urgence les versions 1.27.3 et 1.26.10, qui écartent toute chaîne passant par ces intermédiaires (CVE-2026-111943).

Le reste de l’écosystème dépend de mises à jour, car les bibliothèques et environnements qui embarquent leur propre liste de racines (Python avec certifi, Node.js, Rust, Electron, le paquet ca-certificates des distributions Linux, les images de conteneurs, le curl système de macOS, qui lit un fichier /etc/ssl/cert.pem jamais mis à jour) ne consultent généralement pas la révocation : pour eux, une chaîne passant par ces autorités reste valide, révoquée ou non. C’est pourquoi Mozilla, une fois les clés recalculées publiquement, a retiré d’urgence la racine emSign ECC Root CA - G3 de son magasin, que reprennent la plupart des distributions. eMudhra doit faire migrer environ 30 000 certificats vers sa racine RSA G1 ; 97 % ont été émis par ACME, le protocole de renouvellement automatique, ce qui devrait accélérer la bascule.

Aucune exploitation n’est établie : selon Chrome, aucun certificat TLS rattaché à ces six autorités n’apparaissait avant le blocage dans les journaux Certificate Transparency, ces registres publics où chaque certificat doit être inscrit pour être accepté par Chrome, Safari ou Firefox. Un attaquant n’aurait toutefois aucune raison d’y inscrire un certificat forgé, et curl, Go ou Python n’exigent pas cette inscription : l’absence de trace rend improbable une attaque visant les navigateurs, mais ne dit rien des autres clients.

Contrôler les magasins de confiance que personne ne met à jour

Les utilisateurs de navigateurs à jour n’ont rien à faire ; l’incident concerne surtout les programmes qui établissent des connexions TLS hors navigateur et les organisations qui opèrent leur propre infrastructure de clés.

• Inventorier l’origine des racines de confiance de chaque environnement (système d’exploitation, bibliothèque du langage, image de conteneur de base, équipements réseau), puis appliquer les versions corrigées. Le site de suivi de l’incident liste ces versions par logiciel, propose des hôtes de test (une erreur de certificat signifie que le client est protégé) et une archive des chaînes à vérifier hors ligne avec openssl verify.
• Migrer sans attendre les certificats eMudhra rattachés à emSign ECC Root CA - G3, dont la reconnaissance va disparaître des magasins de Mozilla et de Chrome.
• Restreindre l’authentification par certificat client à sa propre autorité. Les six intermédiaires portent aussi l’usage « authentification du client », si bien qu’un service qui acceptait les certificats clients de toute autorité publique leur faisait également confiance.
• Contrôler indépendamment chaque clé produite par une cérémonie lorsque l’on opère une PKI, interne ou pour des clients. Les outils de détection de clés faibles, comme badkeys, travaillent à partir de la seule clé publique, et le défaut d’eMudhra se repérait de la même façon, en comparant chaque clé aux premières valeurs possibles. Le script de la cérémonie, et toute dérogation, relèvent du double contrôle au même titre que le matériel.
• Traiter tout désaccord entre une clé et son certificat comme un incident de sécurité : en juin 2025, chercher l’origine des signatures invalides aurait mené à la seconde paire de clés.

Le choix d’une autorité de certification relève enfin de la gestion des fournisseurs : l’historique des incidents de chaque autorité est public dans le Bugzilla de Mozilla, et un défaut chez elle se propage à tous ses clients, comme dans la cascade Shipup où la faille d’un prestataire est devenue celle des enseignes. Pour la mécanique des empreintes et des signatures évoquées ici, notre article sur les fonctions de hachage en présente les bases.

Sources et références 16 sources

Sources primaires

1. [1] Mozilla Bugzilla : bug 2083449, Private key compromise of eMudhra Intermediate Certificates (ouvert le 18 octobre 2026)
2. [2] Mozilla Bugzilla : bug 1970728, eMudhra: Invalid CRL signatures (juin 2025)
3. [3] Mozilla Bugzilla : bug 1970727, eMudhra: Failure to respond to a Problem Report within 24 hours (juin 2025)
4. [4] Mozilla Bugzilla : bug 2084101, retrait d'emSign ECC Root CA - G3 de NSS (20 octobre 2026)
5. [5] Liste dev-security-policy : Compromised eMudhra Intermediate Certificates (messages de Mozilla et du Chrome Root Program)
6. [6] Mozilla Security Blog : Protecting Firefox users following the compromise of eMudhra intermediate certificates (20 octobre 2026)
7. [7] golang-announce : Go 1.27.3 et 1.26.10, crypto/x509 (CVE-2026-111943)
8. [8] eMudhra Intermediate CA Compromise : site de suivi, preuves, hôtes de test et versions corrigées

Cadre et outils

1. [9] Mozilla Root Store Policy
2. [10] CA/Browser Forum : Baseline Requirements pour les certificats TLS
3. [11] CCADB : base commune des autorités de certification des programmes racines
4. [12] Certificate Transparency : fonctionnement des journaux publics de certificats
5. [13] badkeys : détection de clés cryptographiques faibles

Presse et analyses

1. [14] LWN.net : eMudhra intermediate CA compromise
2. [15] Cyber Kendra : Go Blocks Compromised eMudhra CA Keys in Emergency Update (octobre 2026)
3. [16] Ali Mosajjal : Eight eMudhra CAs Were Revoked for Compromise, and Nobody Has Said Why (20 octobre 2026)