Les clés de l'AC intermédiaire eMudhra compromises en raison d'une génération défectueuse

Le 17 octobre 2026, un chercheur en sécurité a révélé que les clés privées de huit certificats d'autorité de certification (AC) intermédiaires émis par eMudhra avaient été compromises. Cette faille affecte les chaînes de confiance ancrées dans des programmes gérés par Mozilla, Microsoft, Apple et Chrome, impactant un large éventail de logiciels et d'appareils en aval.

La compromission n'a pas été causée par une intrusion traditionnelle sur serveur ou une attaque de phishing. La cause profonde était plutôt une erreur critique dans la manière dont l'AC générait les clés cryptographiques. Les clés privées étaient mathématiquement récupérables à partir des certificats publics eux-mêmes, ce qui signifie que tout acteur ayant accès aux données publiques pouvait dériver les clés secrètes nécessaires pour signer des certificats frauduleux. Cette vulnérabilité existait depuis la création des certificats en avril 2025.

Ce qui s'est passé

Le problème est apparu au grand jour lorsqu'un journaliste nommé Wayne a démontré la compromission aux équipes des programmes racines (Root Program Teams). Pour prouver la possession des clés privées, Wayne a signé un message spécifique en utilisant la clé privée de chacune des huit AC intermédiaires affectées. Il a fourni les certificats, les clés publiques et les signatures dans un fichier nommé "Wayne proof.zip". Cette preuve cryptographique a permis aux vérificateurs de confirmer que les clés privées étaient bien accessibles à des parties non autorisées sans avoir besoin d'exploiter un système en direct.

Suite à la divulgation du 17 octobre, les grands éditeurs de navigateurs ont agi rapidement pour protéger les utilisateurs. Firefox et Chrome ont bloqué les certificats compromis dès le même jour. Apple a suivi le mouvement, bloquant les certificats sur ses appareils d'ici le 19 octobre. L'AC eMudhra a également révoqué les certificats intermédiaires compromis. Cependant, la révocation seule ne suffit pas pour tous les systèmes. De nombreux clients non-navigateurs ne consultent pas les listes de révocation de certificats (CRL) ou les réponses du protocole OCSP (Online Certificate Status Protocol) en temps réel. Ces clients nécessitent des mises à jour logicielles pour retirer complètement les racines ou intermédiaires compromis de leurs magasins de confiance locaux.

Détails clés

• Huit certificats d'AC intermédiaires eMudhra possèdent des clés privées compromises.
• Le défaut est apparu en avril 2025 lors d'une génération incorrecte des clés par l'AC.
• Les clés privées étaient récupérables à partir des certificats publics, et non volées via un piratage.
• Mozilla, Apple et Chrome ont bloqué les certificats entre le 17 et le 19 octobre 2026.
• Les clients hors de l'écosystème navigateur peuvent toujours faire confiance à ces intermédiaires tant qu'ils ne sont pas mis à jour.
• Aucun journal de transparence des certificats (Certificate Transparency) n'existe pour ces intermédiaires, limitant la visibilité historique.

Contexte

Pour comprendre la gravité de la situation, il est utile de savoir comment fonctionne la confiance numérique. Lorsque vous visitez un site web sécurisé, votre navigateur vérifie le certificat TLS du site. Ce certificat est signé par une AC intermédiaire, elle-même signée par une AC racine. Votre appareil fait confiance à l'AC racine et, par extension, à l'intermédiaire et au site web. Si un attaquant possède la clé privée d'une AC intermédiaire, il peut créer des certificats valides pour n'importe quel domaine, comme celui de votre banque ou de votre fournisseur de messagerie. Cela lui permet d'intercepter le trafic chiffré sans déclencher d'avertissements de sécurité.

La Transparence des Certificats (CT) est un système qui consigne tous les certificats émis dans des registres publics. Des navigateurs comme Chrome et Safari exigent des journaux CT pour accepter les certificats. Dans ce cas précis, il n'y avait aucune entrée dans les journaux CT pour ces intermédiaires spécifiques durant la période de vulnérabilité. Cela signifie que si les navigateurs étaient protégés contre la visualisation de certificats frauduleux émis après coup, la faiblesse sous-jacente des clés demeurait. Les systèmes qui n'imposent pas la CT, tels que de nombreux outils en ligne de commande, appareils embarqués et logiciels d'entreprise hérités, restent exposés aux risques s'ils n'ont pas reçu de mises à jour pour se méfier de ces intermédiaires spécifiques.

Pourquoi c'est important

Pour les équipes gérant des logiciels auto-hébergés ou des infrastructures internes, cet incident met en lumière un angle mort dans la surveillance de sécurité standard. La plupart des organisations comptent sur les mises à jour du système d'exploitation et du navigateur pour gérer les changements de magasin de confiance. Cependant, les applications personnalisées, les microservices et les dispositifs IoT maintiennent souvent leurs propres magasins de confiance ou utilisent des bibliothèques TLS légères qui ne se synchronisent pas automatiquement avec les listes de révocation au niveau du système d'exploitation. Si vos services internes communiquent avec des API externes ou si vous hébergez des services pour des clients utilisant divers types de clients, ces connexions peuvent toujours faire confiance aux intermédiaires compromis d'eMudhra.

Le fait que les clés soient récupérables à partir de données publiques est particulièrement alarmant. Cela suggère que l'échec de sécurité était procédural et mathématique, et non seulement opérationnel. Cela implique que des erreurs similaires pourraient exister dans d'autres AC ou dans des certificats passés. Pour les responsables IT, cela renforce la nécessité de vérifier non seulement que vos certificats sont valides, mais aussi que la chaîne de confiance elle-même est intacte et exempte d'autorités compromises connues. Se fier uniquement aux mises à jour automatiques des navigateurs laisse des lacunes dans l'infrastructure non orientée vers le web.

Ce que vous pouvez faire

• Mettez à jour immédiatement tous les navigateurs et systèmes d'exploitation vers les dernières versions pour garantir que les certificats révoqués sont bloqués.
• Testez les outils en ligne de commande comme curl contre les hôtes de vérification listés dans la divulgation pour contrôler les magasins de confiance locaux.
• Examinez toutes les applications personnalisées ou appareils embarqués qui utilisent des magasins de confiance statiques pour détecter les certificats intermédiaires obsolètes.
• Vérifiez que vos systèmes de surveillance alertent sur les changements de certificats, et pas seulement sur les dates d'expiration.
• Vérifiez si votre organisation utilise des certificats eMudhra en interne et remplacez-les s'ils s'enchaînent aux intermédiaires affectés.
• Surveillez les mises à jour officielles de Mozilla, Apple et Microsoft pour obtenir des directives supplémentaires sur les correctifs des magasins de confiance en aval.