La faille certificats eMudhra concerne huit clés privées d’autorités de certification intermédiaires rendues récupérables par un défaut de génération en 2025. Chrome et Firefox ont bloqué les six clés TLS en octobre 2026, mais les applications, conteneurs, SDK et équipements utilisant leur propre magasin de confiance doivent être testés séparément. Une chaîne encore acceptée peut permettre la validation d’un faux certificat.
Que s’est-il passé avec les certificats eMudhra ?
La faille certificats eMudhra provient de huit clés d’autorités intermédiaires créées le 30 avril 2025 avec une entropie insuffisante, c’est-à -dire trop peu d’aléatoire. Le 17 octobre 2026, un chercheur a démontré le contrôle des huit clés privées. Mozilla en a récupéré une indépendamment, confirmant une exploitation techniquement triviale.
Une autorité de certification intermédiaire est une entité numérique autorisée par une autorité racine à signer d’autres certificats. Six clés compromises servaient au protocole TLS, qui chiffre notamment les connexions HTTPS, et deux à la signature de code.
Selon CERT-In, les valeurs privées P-384 concernées étaient des entiers inférieurs à 256. Elles pouvaient donc être retrouvées presque instantanément à partir des clés publiques, alors qu’une clé elliptique correctement produite doit être impraticable à deviner.
eMudhra a expliqué le 21 octobre 2026 qu’une étape de script « wrap/unwrap » avait créé un second jeu de clés faibles, puis que des libellés similaires avaient conduit à employer ces clés dans les demandes de signature. Le 26 octobre 2026, l’enquête de cause racine restait signalée comme en cours. Il s’agit donc de l’explication publiée par l’entreprise, pas encore d’un rapport final indépendant.
Quel risque la faille certificats eMudhra crée-t-elle ?
La possession d’une clé TLS intermédiaire compromise permettait de signer de faux certificats pour n’importe quel domaine, à condition que le client conserve la chaîne eMudhra comme fiable et n’impose pas Certificate Transparency. Un attaquant devait aussi intercepter ou détourner la connexion pour présenter le certificat falsifié à sa cible.
Certificate Transparency est un système de journaux publics qui rend contrôlable l’émission des certificats du Web. Google a indiqué le 20 octobre 2026 n’avoir trouvé, avant son blocage, aucun certificat TLS lié aux six intermédiaires compromis dans ces journaux. Ce constat écarte leur usage contre les clients qui imposaient ce contrôle, mais pas contre les clients sans contrôle CT.
eMudhra a déclaré le 21 octobre 2026 que sept intermédiaires n’avaient jamais été déployés et que le huitième n’avait émis aucun certificat final. L’entreprise disait également n’avoir trouvé aucune preuve d’une récupération malveillante des clés avant leur divulgation. Absence de preuve ne signifie pas preuve d’absence, mais affirmer qu’une attaque a eu lieu serait inexact.
Le piège pour un décideur consiste à confondre certificat compromis et site piraté. La faille certificats eMudhra touche le mécanisme de confiance : elle peut faciliter l’usurpation d’un service auprès de certains clients, sans démontrer une intrusion dans le serveur, la base de données ou le compte d’hébergement.
Chrome et Firefox protègent-ils déjà votre entreprise ?
Chrome a bloqué les six clés TLS par CRLSet le 17 octobre 2026 à 19 h 45 UTC, puis Firefox a achevé sa diffusion OneCRL à 22 h 59 UTC. Ces mécanismes de révocation ont été appliqués sans redémarrage ni mise à jour complète du navigateur dans les configurations standard, selon Mozilla.
Mozilla a ensuite publié Firefox 158.0.1, Firefox ESR 115.43.1, Firefox ESR 153.5.1 et NSS 3.131.1 le 20 octobre 2026. NSS, la bibliothèque de sécurité de Mozilla, a retiré la racine emSign ECC Root CA - G3 pour les logiciels qui utilisent le magasin Mozilla sans recevoir OneCRL. Firefox pour Android 158.0.2 a suivi le 21 octobre 2026.
Google a programmé le 27 octobre 2026 le retrait de cette même racine sur les appareils stables utilisant Chrome Root Store, notamment pour étendre la protection aux clients qui ne reçoivent pas CRLSet. La différence entre versions de Chrome et Firefox rappelle qu’une fonctionnalité ou une protection diffusée par navigateur ne s’applique jamais uniformément à tout un parc.
Voici la différence opérationnelle entre les principaux environnements concernés en 2026.
| Environnement | Mesure publiée en 2026 | Vérification à mener |
|---|---|---|
| Chrome standard | Blocage CRLSet le 17 octobre | Contrôler la réception des politiques et le Chrome Root Store |
| Firefox standard | Blocage OneCRL le 17 octobre, versions corrigées le 20 octobre | Contrôler la version et l’application de OneCRL |
| Application avec NSS | Retrait de la racine dans NSS 3.131.1 le 20 octobre | Identifier et mettre à jour la version NSS embarquée |
| Conteneur, SDK ou application Electron | Aucune protection universelle | Tester le moteur TLS et le fichier d’autorités réellement chargés |
| Équipement embarqué | Dépend du fabricant et du micrologiciel | Tester l’équipement, puis demander un correctif au fournisseur |
Comment vérifier si un site ou une application reste exposé ?
La vérification de la faille certificats eMudhra doit inventorier les chaînes serveur et client contenant EM DV/OV/EV TLS CA - G3B, EM DV/OV/EV TLS CA - G3C, leurs équivalents cosignés par Sectigo ou emSign ECC Root CA - G3. Chaque test doit employer le moteur TLS et le magasin d’autorités de l’application réelle.
Ouvrir le site dans son navigateur personnel ne suffit pas. Une API peut fonctionner dans Chrome tout en restant vulnérable depuis un ancien conteneur Linux, une application Electron, un terminal de paiement ou un SDK mobile qui embarque sa propre liste d’autorités. C’est le même type d’écart d’environnement que lors de la correction d’une faille sur NAS et Docker.
Un inventaire exploitable suit cinq étapes :
- recenser les domaines, API, applications mobiles, conteneurs, automates, VPN et équipements qui ouvrent des connexions TLS ;
- extraire la chaîne présentée par chaque serveur et rechercher les noms eMudhra concernés, y compris les copies cosignées par Sectigo ;
- identifier, côté client, la bibliothèque TLS et le magasin d’autorités réellement utilisés ;
- tester les connexions avec la configuration exacte de production, puis consigner les connexions acceptées et refusées ;
- préparer le remplacement des certificats légitimes qui dépendent de la racine retirée, avant de supprimer celle-ci du parc.
Le vérificateur indépendant publié le 22 octobre 2026 propose notamment la commande curl https://dv-g3b-emudhra.we-have-a-problem.com/. Une connexion réussie indique que le client testé accorde encore sa confiance à la chaîne présentée. Des points de terminaison sans Certificate Transparency et des chaînes PEM téléchargeables permettent aussi des validations hors ligne avec OpenSSL.
Sur les projets que nous menons, nous voyons souvent l’audit s’arrêter au certificat présenté par le serveur public. Le bon réflexe consiste à tester aussi les consommateurs de l’API : tâches planifiées, applications mobiles, images Docker et logiciels métier. La gestion des secrets doit être examinée séparément, comme l’illustre la sécurisation des clés API après un incident.
Faut-il supprimer immédiatement la racine eMudhra ?
Supprimer emSign ECC Root CA - G3 bloque les chaînes dépendant de cette racine, mais peut aussi interrompre des connexions légitimes. Google a confirmé ce risque le 22 octobre 2026. Les opérateurs concernés doivent d’abord obtenir et déployer un certificat rattaché à une autre hiérarchie de confiance, puis retirer l’ancienne chaîne.
Mozilla estimait dans Bugzilla, le 21 octobre 2026, qu’environ 30 800 précertificats non expirés étaient rattachés à la racine G3 retirée, principalement via deux autorités subordonnées Internet2/InCommon. Ces certificats légitimes ne provenaient pas des huit intermédiaires faibles. Ils illustrent le coût collatéral possible d’une défiance appliquée à la racine entière.
eMudhra a révoqué les huit intermédiaires le 18 octobre 2026 avec le motif caCompromise. Les copies cosignées par Sectigo utilisaient les mêmes clés publiques compromises ; changer seulement le chemin de certification ne corrige donc pas le problème.
Le 22 octobre 2026, le conseil d’administration d’eMudhra a décidé de quitter le marché mondial des certificats SSL/TLS. L’entreprise a annoncé des certificats de remplacement pendant la transition et le maintien des services d’état jusqu’à l’expiration ou au remplacement des certificats émis. Honnêtement, conserver durablement une dépendance à cette hiérarchie ne se justifie pas lorsqu’une réémission vers une autorité encore approuvée est possible.
Quel plan d’action appliquer sans provoquer de coupure ?
Le traitement de la faille certificats eMudhra doit séparer l’urgence client de la migration serveur. Il faut d’abord bloquer les autorités compromises dans chaque environnement vulnérable, puis réémettre les certificats légitimes avant de retirer la racine G3. Un déploiement progressif avec surveillance évite qu’une correction de sécurité coupe une API métier.
Côté agence, le réflexe est de constituer une matrice « service, client, moteur TLS, magasin de confiance, propriétaire ». Ce document simple révèle les dépendances oubliées et permet d’attribuer chaque correction. Sans propriétaire identifié, les vieux conteneurs et équipements embarqués restent fréquemment hors du plan.
Prévoyez un retour arrière pour chaque changement, mais pas un retour durable vers la confiance compromise. Sur un serveur, déployez d’abord la nouvelle chaîne et vérifiez-la depuis tous les clients représentatifs. Sur un parc client, mettez à jour le magasin d’autorités ou la bibliothèque, contrôlez les journaux d’erreurs TLS, puis retirez les exceptions temporaires.
Cadrer la vérification des chaînes, des bibliothèques TLS et des certificats de remplacement évite la plupart des interruptions inattendues. Un regard extérieur peut surtout aider lorsqu’une application dépend de plusieurs prestataires, images de conteneurs ou équipements dont personne ne maîtrise seul toute la chaîne.
FAQ sur l’incident eMudhra
Un cadenas HTTPS prouve-t-il que mon certificat est sûr ?
Le cadenas HTTPS indique qu’un navigateur a accepté la connexion et son certificat. Le cadenas ne prouve pas qu’un autre client, utilisant un magasin d’autorités différent, bloque correctement les clés eMudhra compromises.
Quels noms de certificats eMudhra faut-il rechercher ?
Les contrôles doivent rechercher EM DV/OV/EV TLS CA - G3B, EM DV/OV/EV TLS CA - G3C, leurs versions cosignées par Sectigo et la racine emSign ECC Root CA - G3.
La mise à jour du navigateur protège-t-elle une application Electron ?
Une mise à jour de Chrome ou Firefox ne garantit pas la protection d’une application Electron. L’application Electron peut embarquer son propre runtime, sa bibliothèque TLS ou un magasin d’autorités distinct qu’il faut tester et mettre à jour.
Existe-t-il une preuve d’exploitation malveillante des clés ?
Aucune exploitation malveillante n’était confirmée dans les informations publiées au 27 octobre 2026. eMudhra disait n’avoir trouvé aucune preuve antérieure à la divulgation, tandis que la récupération indépendante des clés démontrait que l’attaque était techniquement facile.