La clé était 4 : qui décide des sites web auxquels vos logiciels font confiance

Il s’agit d’un article traduit par une machine. La version originale est disponible en anglais.

Dernière mise à jour : 25 octobre 2026 · 21 min de lecture

Nous avons un problème ici

Le samedi 17 octobre 2026, à 18 h 05 UTC, le programme de certificats racines de Chrome (Chrome Root Program) a reçu le signalement d’un chercheur en sécurité connu publiquement sous le seul nom de Wayne. Celui-ci affirmait détenir les clés privées de huit autorités de certification exploitées par eMudhra, une société cotée en Bourse basée à Bangalore, en Inde. Pour le prouver, il avait utilisé chacune des huit clés pour signer le même court message : « Nous avons un problème ici – Wayne. »

Il n’avait rien eu à forcer. Une fois l’affaire connue, le chercheur en sécurité Scott Helme a décrit à quoi ressemblaient ces clés. L’une d’elles était tout simplement le nombre 4. Deux autres valaient 56 et 115. Helme a expliqué les avoir toutes retrouvées sur son ordinateur portable à partir de leurs certificats publics, en moins d’une seconde. Une vérification indépendante menée par des journalistes a confirmé que la clé privée de l’AC « EM OV TLS CA – G3C » d’eMudhra était 4.

Les huit étaient des autorités de certification intermédiaires, l’échelon opérationnel d’une société de certificats, celui qui signe des justificatifs pour le compte d’autrui. Six d’entre elles étaient habilitées à émettre des certificats pour des sites web, et ces six-là bénéficiaient de la confiance des programmes de certificats racines de Chrome, de Mozilla, de Microsoft et d’Apple. Les deux autres servaient à la signature de code, ces certificats avec lesquels les éditeurs de logiciels signent leurs programmes, et Microsoft leur faisait confiance. Leurs clés avaient été mal générées, si bien que quiconque savait où chercher pouvait les calculer à partir des certificats eux-mêmes, publics par nature. C’était possible depuis la création des certificats, en avril 2025.

À 19 h 45 UTC, une heure et quarante minutes après réception du signalement, Chrome avait confirmé les constatations et déployé un blocage auprès de ses utilisateurs. Personne n’a eu à installer de mise à jour ni à redémarrer le navigateur.

La rapidité comptait, à cause de ce qu’une telle clé permet de faire. Quiconque détenait l’une des six clés destinées aux sites web et pouvait intercepter la connexion d’une personne était en mesure de lui présenter un faux certificat pour une banque, une messagerie ou n’importe quel autre site, quelle que soit la société de certificats choisie par le vrai site, et tout logiciel qui faisait confiance à la chaîne d’eMudhra l’aurait accepté. Deux protections principales s’y opposaient : un système de journalisation public appelé Certificate Transparency, que certains logiciels exigent et que beaucoup d’autres ignorent, et les blocages, quels qu’ils soient, que chaque logiciel recevait à temps.

Qu’un faux certificat ait pu fonctionner ou non dépendait de décisions d’ordinaire invisibles : qui se porte garant d’un site web, qui décide qu’il faut croire ce garant, et à quelle vitesse cette confiance peut être retirée quand le garant se révèle défaillant.

Ce que garantit un certificat

Un certificat de site web est un petit document signé qui associe un nom, par exemple l’adresse web d’une banque, à une clé publique. Les clés publiques vont par paires avec des clés privées. La clé privée reste secrète et produit des signatures numériques ; la clé publique permet à chacun de vérifier qu’une signature provient bien de sa partenaire. Lorsque votre navigateur se connecte à un site, celui-ci prouve qu’il détient la clé privée correspondant à la clé publique inscrite dans son certificat. Le certificat lui-même affirme que cette clé publique appartient à ce nom, et une autorité de certification, ou AC, se porte garante de cette affirmation en la signant.

Avant de signer un certificat de site web, l’AC doit vérifier que le demandeur contrôle le domaine. L’une des méthodes approuvées consiste à lui fournir une valeur aléatoire, puis à la chercher dans les enregistrements DNS du domaine, l’annuaire public d’Internet, où seul quelqu’un qui contrôle le domaine a pu la placer. L’AC peut aussi confirmer que le demandeur détient réellement la clé privée qu’il veut faire certifier, au moyen d’un test technique appelé preuve de possession, même si la norme sous-jacente l’autorise aussi à s’en remettre à la parole du demandeur.

Aucun navigateur ne pourrait contrôler lui-même toutes les AC du monde ; la confiance est donc déléguée le long d’une chaîne. Au sommet se trouvent les certificats racines, conservés dans une liste appelée magasin de confiance, livrée avec votre système d’exploitation ou votre navigateur. Les racines habilitent des AC intermédiaires, et ce sont les intermédiaires qui émettent les certificats qu’utilisent les sites web. Quand votre logiciel voit le certificat d’un site, il remonte les signatures, du site à une intermédiaire puis à une racine, et n’accepte le site que si la chaîne aboutit à une racine de son magasin, que chaque signature est valide, que le certificat n’a pas expiré et couvre le nom visité, et qu’aucune autre règle du logiciel ne s’y oppose.

Les programmes de certificats racines, gérés par des éditeurs de systèmes d’exploitation et de navigateurs comme Apple, Google, Microsoft et Mozilla, examinent les autorités de certification et décident quelles racines entrent dans le magasin. C’est pourquoi la clé privée d’une intermédiaire a tant de valeur. Sauf si elle a été restreinte à certains noms, ce qui n’était pas le cas de celles d’eMudhra, une intermédiaire peut signer un certificat pour n’importe quel domaine, et ce certificat se valide en remontant jusqu’à une racine de confiance. La clé de la racine peut rester enfermée en lieu sûr ; c’est celle de l’intermédiaire qui signe au quotidien, et si elle fuit, la caution de la racine fuit avec elle.

Rien de tout cela ne dit si un site web est honnête, même si le cadenas du navigateur est largement compris ainsi. Quand Google a étudié la question en 2021, seuls 11 % des participants comprenaient correctement ce que signifiait le cadenas, et presque tous les sites d’hameçonnage utilisaient HTTPS et l’affichaient donc eux aussi. En 2023, Google a annoncé que Chrome remplacerait le cadenas par une autre icône. Un certificat de base dit seulement que la connexion aboutit chez quiconque détient la clé correspondant à ce nom. Certains certificats nomment aussi l’organisation qui se trouve derrière le site ; aucun ne se porte garant de ses intentions.

Il existe une couche supplémentaire. Certificate Transparency, conçu par des ingénieurs de Google en 2013, inscrit les certificats dans des journaux publics où chacun peut vérifier ce que chaque AC a émis. Ses concepteurs voulaient qu’à terme les clients refusent tout certificat non journalisé, de sorte qu’un certificat tenu hors des journaux, qu’il ait été émis par une AC ou par un voleur muni de la clé d’une AC, soit rejeté. Chrome le fait par défaut pour chaque connexion qui s’appuie sur son magasin de certificats racines.

L’avertissement resté sans réponse

Les règles de fabrication des clés d’AC sont strictes. Pour les racines et certaines clés intermédiaires, les Baseline Requirements du secteur, le règlement que les programmes de certificats racines des navigateurs et les AC tiennent à jour ensemble, imposent à l’AC de suivre un script écrit de génération de clés et de faire assister à la cérémonie un auditeur qualifié, ou bien de la filmer intégralement. Toute clé d’AC doit être générée par plusieurs personnes réunies, dont aucune ne détient à elle seule l’ensemble des connaissances nécessaires pour le faire.

Le 30 avril 2025, eMudhra a créé un lot de 24 intermédiaires. Elles se répartissaient en trois séries, étiquetées A, B et C, avec deux types de clés, RSA et le type à courbe elliptique appelé P-384, et quatre usages. Les huit clés défaillantes étaient toutes les clés P-384 des séries B et C. Toutes les huit étaient des nombres entiers inférieurs à 256. Écrite en entier, chacune n’était qu’une longue suite de zéros avec quelque chose dans le dernier octet.

Pourquoi cette clé était devinable

Une clé privée sur la courbe P-384 n'est qu'un nombre, tiré au hasard entre 1 et une limite fixe elle-même longue de 384 bits. La clé publique se calcule à partir de la clé privée par une opération facile à effectuer dans un sens et, pour un nombre véritablement aléatoire, impossible à inverser en pratique. Elle est imprimée dans le certificat. Le nombre 4 est une clé privée parfaitement valide ; c'est aussi l'un des premiers nombres que n'importe qui essaierait. Mozilla a souligné que des clés aussi petites se retrouvent quasi instantanément : on calcule les clés publiques de 1, 2, 3 et ainsi de suite jusqu'à 256, et on compare chacune à celle du certificat. Quand deux coïncident, la clé privée est le nombre dont on est parti. Une clé véritablement aléatoire n'offre pas de liste aussi courte. Comme l'a dit Scott Helme, l'intervalle contient environ 10 puissance 115 possibilités, « donc personne ne va jamais chercher là-dedans ». Dennis Jackson, de Mozilla, a aussi confié la tâche à des agents d'IA exécutés en local. Ils ont retrouvé la clé dès leur première tentative, à partir d'une simple requête.

Comment une cérémonie des clés a-t-elle pu produire des nombres aussi petits ? Selon l’explication préliminaire d’eMudhra, publiée le 19 octobre, le script utilisé ce jour-là comportait une faille. La société affirme qu’elle avait approuvé une modification ponctuelle de la procédure habituelle pour tester l’exportation des clés, qu’une erreur de programmation a conduit le matériel à créer une seconde paire de clés, plus faible, à côté des bonnes, et que ces clés faibles ont ensuite été utilisées par erreur pour demander les certificats parce que leurs libellés se ressemblaient. Elle indique que les clés ont été générées dans des modules matériels de sécurité fabriqués par Utimaco, ces appareils résistants à l’effraction censés produire et protéger les clés d’AC.

eMudhra qualifie elle-même ce récit de préliminaire, et il laisse entière l’énigme centrale. Un intervenant sur le ticket public de Mozilla a relevé que, soit les clés avaient été fabriquées hors du matériel sécurisé puis chargées dedans, en violation des règles, soit le matériel pouvait d’une manière ou d’une autre être configuré pour produire lui-même des clés défectueuses. Un autre participant, sur la liste de diffusion publique de Mozilla, a avancé sans confirmation qu’un logiciel avait pris pour la clé elle-même un petit fichier pointant vers la véritable clé à l’intérieur du matériel. Mozilla, en s’y employant bien davantage, n’a pas pu retrouver les clés P-384 de la série A issues du même lot. Elle a adressé des questions à eMudhra le 20 octobre, avec un délai de 24 heures ; au 23 octobre, elle n’avait reçu aucune réponse, et la façon dont les clés faibles avaient vu le jour n’avait pas été expliquée.

Ce qui est documenté, c’est que le problème s’était manifesté plus d’un an auparavant. En juin 2025, un service public de surveillance montrait qu’eMudhra diffusait six listes de révocation de certificats aux signatures invalides pour ces mêmes intermédiaires. Une liste de révocation, ou CRL, est un registre signé des certificats qu’une AC a annulés, et sa signature doit se vérifier avec la clé publique figurant dans le certificat de l’AC. Le rapport d’eMudhra de l’époque indiquait que Sectigo, une autre société de certificats, l’avait d’abord alertée par courriel le 3 juin 2025, et que le message avait été mis en quarantaine par des filtres internes sans être lu. Les listes fautives ont été remplacées le 6 juin.

En octobre 2026, eMudhra a expliqué en quoi avait consisté ce correctif. Les listes avaient d’abord été signées avec les clés d’origine, véritablement aléatoires ; comme les certificats contenaient les moitiés publiques des clés faibles, ces signatures échouaient, et la société avait de nouveau signé les listes avec les clés défectueuses. En juin 2025, eMudhra disposait donc d’éléments montrant que ses certificats ne correspondaient pas aux clés qu’elle croyait utiliser, et elle a corrigé les listes.

Le programme de certificats racines de Chrome a demandé pourquoi eMudhra s’était contentée de signer à nouveau les listes au lieu d’interrompre ses opérations, de chercher pourquoi deux paires de clés existaient pour ces AC et de révoquer les certificats. eMudhra affirme que ses racines et ses AC émettrices ont passé des audits indépendants deux années de suite. Le 14 octobre 2026, trois jours avant le signalement de Wayne, elle a publié pour une autre racine, emSign Root TLS CA – G1, une liste de révocation dont la signature n’était pas valide non plus.

Deux sortes d’interrupteurs

La première riposte de Chrome a été rapide parce qu’elle visait des clés. Chrome tient une liste de blocage appelée CRLSet, que Google envoie aux navigateurs en arrière-plan. La mise à jour déployée à 19 h 45 UTC bloquait les empreintes des clés publiques des six intermédiaires. Parce que le blocage désignait des clés, il couvrait tous les certificats qui les utilisaient, y compris ceux qu’un faussaire pourrait créer plus tard. Mozilla a bloqué les certificats dans Firefox au moyen de sa propre liste, OneCRL, et a terminé à 22 h 59 UTC. OneCRL fonctionne sans que les utilisateurs aient à mettre à jour Firefox, ni même à le redémarrer.

Une liste envoyée en arrière-plan ne protège que les logiciels qui la reçoivent. Le 20 octobre, Mozilla a publié une mise à jour de Firefox pour les utilisateurs dont la configuration avait empêché la liste de blocage d’arriver, puis un correctif pour certains profils de Firefox pour Android qui ne l’appliquaient pas. Google a commencé à envoyer un blocage équivalent aux appareils Android par l’intermédiaire des services Google Play vers 22 h UTC le lundi 19 octobre, et a indiqué le lendemain que la plupart l’avaient reçu. Microsoft et Apple ont suivi en quelques jours, même si les comptes rendus publiés divergent sur la date exacte de l’intervention d’Apple.

Les autorités de certification ont bougé elles aussi. eMudhra a marqué les huit certificats comme révoqués avant 9 h 38 UTC le 18 octobre, avec pour motif la compromission de l’AC. Sectigo, qui avait apposé une signature croisée sur les intermédiaires, a achevé de révoquer ses certificats croisés le 19 octobre. Chrome a aussi obtenu que les journaux Certificate Transparency rejettent tout certificat dont la chaîne remontait aux AC compromises, de sorte qu’un faux certificat ne puisse plus recueillir les inscriptions au journal qu’exigent les logiciels qui vérifient la CT.

L’outil le plus lourd consiste à retirer la racine qui avait habilité les intermédiaires. Le 20 octobre, constatant que plusieurs personnes avaient entre-temps retrouvé les clés de manière indépendante, Mozilla a décidé le retrait d’urgence d’emSign ECC Root CA – G3, la racine d’eMudhra située au-dessus des intermédiaires défaillantes, de son magasin de confiance. Firefox n’en avait pas besoin ; OneCRL couvrait déjà Firefox. Ce retrait visait tous les autres, ceux qui utilisent la liste de racines de Mozilla, ou une liste qui en dérive, sans OneCRL. Mozilla a prévenu que ce changement rendrait certains serveurs inaccessibles à ces utilisateurs tant que ces serveurs ne seraient pas passés à de nouvelles chaînes de certificats.

Chrome a retiré la même racine de son magasin. Google prévoyait que le changement atteindrait tous les appareils qui s’appuient sur le Chrome Root Store le mardi 27 octobre 2026 au matin, heure du Pacifique, et plus tôt sur les versions de test Canary et Beta. Google a dit sans détour que certains certificats légitimes rattachés à cette racine cesseraient en conséquence de fonctionner dans Chrome.

Les deux interrupteurs diffèrent par ce qu’ils attrapent et par ceux qu’ils pénalisent. Le retrait d’une racine coupe tous les chemins qui passent par elle, y compris ceux des sites honnêtes, mais manque les chemins qui passent par d’autres racines, et les intermédiaires d’eMudhra en avaient un autre. Sectigo les avait certifiées de façon croisée, rattachant les mêmes clés à une racine appelée AAA Certificate Services, émise sous le nom de Comodo. Chrome avait abandonné cette racine en avril 2025, mais certains systèmes lui faisaient encore confiance : Ubuntu a retiré emSign ECC Root CA – G3 de toutes ses versions prises en charge et, des anciennes versions qui la contenaient encore, la racine Comodo aussi. Un blocage fondé sur l’intermédiaire elle-même ferme toutes les routes à la fois. C’est l’approche qu’a retenue le langage de programmation Go : depuis les versions publiées le 19 octobre, le vérificateur de certificats de Go écarte toute chaîne contenant l’une des intermédiaires compromises, quelle que soit la racine à laquelle elle aboutit.

La mise à jour de tous les autres

Le 18 octobre, Mozilla a écrit sur son ticket public qu’elle s’inquiétait pour l’écosystème au sens large, parce que de nombreux terminaux n’ont aucun moyen efficace de recevoir les informations de révocation. Les navigateurs avaient leurs listes d’arrière-plan. Une grande partie des autres logiciels qui établissent des connexions sécurisées n’ont rien de comparable.

Le site de suivi de l’incident, une page publique mise en place par Dennis Jackson, de Mozilla, détaillait qui était exposé. Les applications et bibliothèques qui embarquent leur propre jeu de racines de confiance avaient besoin de mises à jour logicielles. De même pour les applications construites sur Electron, le framework qui fait tourner des programmes de bureau comme Slack et Discord, et qui ne récupèrent le correctif d’Electron qu’une fois recompilées sur une version corrigée.

Certaines failles se trouvaient dans les fichiers de confiance des systèmes d’exploitation eux-mêmes. Au 22 octobre, le site de l’incident indiquait que macOS bloquait les intermédiaires compromises, mais que ses outils en ligne de commande intégrés, dont curl, git et python3, vérifiaient les certificats à partir d’un fichier distinct sans consulter la révocation, et que ce fichier n’avait pas été mis à jour. Sous Ubuntu, le magasin de confiance de Java exigeait une intervention manuelle après la mise à jour du système, à cause d’un problème de synchronisation que Canonical n’avait pas résolu au 22 octobre, et les navigateurs installés sous forme de paquets snap n’utilisaient pas du tout le magasin du système.

D’autres failles se trouvaient dans les bibliothèques qui transportent leurs propres listes. Go a livré son correctif dans les versions de sécurité 1.27.3 et 1.26.10, sous la référence CVE-2026-111943. Le paquet certifi de Python, très utilisé, a retiré les quatre racines emSign le 18 octobre, puis a rétabli les trois qui n’étaient pas concernées dans une version étiquetée 2026.10.19 ; une version automatisée du 23 octobre en a de nouveau supprimé deux sur trois. Et certains produits ne pouvaient être corrigés que par leurs fabricants : l’équipe de sécurité Talos de Cisco a désigné les réseaux privés virtuels comme susceptibles de nécessiter des mises à jour.

Sous tout cela, il y avait Certificate Transparency. La plupart des navigateurs l’imposent, mais de nombreux clients qui ne sont pas des navigateurs, dont curl, ne le font pas. Un faux certificat fabriqué avec l’une des clés d’eMudhra et jamais journalisé serait rejeté par Chrome, mais pourrait être accepté par ces clients, pour peu qu’ils fassent encore confiance à la chaîne d’eMudhra et que rien d’autre ne l’arrête, par exemple une application qui n’accepte que les certificats connus de ses propres serveurs.

Il y a de solides raisons de penser que le système a fonctionné. Aucun certificat de site web rattaché aux six intermédiaires n’avait été inscrit dans les journaux Certificate Transparency avant le blocage de Chrome du 17 octobre ; entre la création des clés en avril 2025 et ce blocage, aucun faux certificat issu de ces clés n’aurait donc pu servir contre des clients qui imposent la CT. Talos a déclaré n’avoir observé aucune utilisation malveillante dans la nature au 21 octobre, 14 h UTC. eMudhra affirme qu’une seule des intermédiaires concernées a jamais été mise en production, et qu’aucune n’a jamais délivré de certificat à un site web ou à un éditeur de logiciels.

Pour les logiciels qui ont imposé la CT tout du long, l’argument est juste, et la protection est venue d’une règle permanente, non de l’urgence du week-end. Sa portée est plus étroite que ne le laisse entendre la formule « le système a fonctionné ». Firefox pour Android n’a commencé à imposer Certificate Transparency qu’avec la version 145, proposée aux utilisateurs à partir du 11 novembre 2025. Les applications Android ne peuvent utiliser les vérifications CT intégrées qu’à partir d’Android 16, et n’en bénéficient par défaut que si elles sont compilées pour Android 17.

L’urgence a aussi compté pour la suite. Le premier avis de Mozilla aux mainteneurs des magasins de confiance dérivés s’était délibérément gardé de dire que n’importe qui pouvait retrouver les clés. Le 20 octobre, cela n’avait plus guère d’importance : plusieurs personnes les avaient retrouvées de manière indépendante, et Helme avait publié les huit valeurs. Une fois les clés de fait publiques, les blocages et les rejets dans les journaux CT étaient tout ce qui s’interposait entre elles et une nouvelle contrefaçon. Au 24 octobre, rien de ce qui avait été publié ne montrait si des attaquants avaient utilisé les clés défectueuses contre des clients sans CT entre avril 2025 et octobre 2026.

Qui tient l’interrupteur

Le choix des racines auxquelles navigateurs et systèmes d’exploitation font confiance revient aux programmes de certificats racines, et leurs règles laissent une grande latitude à leurs propriétaires. La politique de Chrome précise que Google inclut ou retire des certificats « à sa seule discrétion », et que chaque certificat inclus doit apporter aux utilisateurs une valeur supérieure au risque de le conserver. Celle de Mozilla indique qu’elle peut désactiver ou retirer un certificat à sa seule discrétion, à tout moment et pour n’importe quelle raison. Mozilla précise aussi qu’elle ne facture aucun frais d’inclusion.

Ce pouvoir discrétionnaire a été exercé de diverses manières. En 2014, après que le National Informatics Centre indien eut émis des certificats non autorisés pour plusieurs domaines de Google, Chrome n’a pas écarté la racine India CCA située au-dessus. Il a limité cette racine à une liste de domaines indiens. Trois ans plus tôt, la réponse à une autorité néerlandaise avait été totale : le 3 septembre 2011, Google a décidé de rejeter toutes les autorités de certification exploitées par DigiNotar, et dix-sept jours plus tard un tribunal néerlandais déclarait la société en faillite.

DigiNotar, 2011

La compromission de DigiNotar a été révélée par un utilisateur ordinaire. Le 28 août 2011, un client de ParsOnline, un fournisseur d'accès à Internet iranien, a signalé sur un forum d'assistance de Google un avertissement de certificat que Chrome lui avait affiché. Le certificat prétendait être celui de Google, et il provenait de DigiNotar, dont les systèmes avaient été piratés. Les enquêteurs de la société de sécurité Fox-IT, mandatés par le gouvernement néerlandais, ont établi par la suite qu'un certificat frauduleux couvrant des adresses google.com avait servi à une vaste attaque visant environ 300 000 utilisateurs, presque tous en Iran, dont le trafic vers Google a probablement été intercepté ou redirigé. Ils ont tiré cette estimation de 298 140 adresses internet distinctes qui avaient vérifié le statut du faux certificat, et l'ont qualifiée d'approximation très grossière. Le 3 septembre, le gouvernement néerlandais a publiquement retiré sa confiance à DigiNotar. Fin octobre 2026, aucune attaque utilisant les clés d'eMudhra n'avait été signalée. DigiNotar a montré ce que devient le pouvoir de signature d'une AC entre les mains de quelqu'un prêt à s'en servir.

L’inclusion dans le magasin de certificats racines de Chrome, a écrit Google, exige du propriétaire d’une AC qu’il démontre en permanence la compétence technique et la rigueur opérationnelle nécessaires pour protéger les utilisateurs de Chrome, et Google a indiqué qu’il « examinait de près » si les autres certificats d’AC d’eMudhra devaient être conservés. Le 23 octobre, eMudhra a écrit sur le ticket public que l’intense examen sur les réseaux sociaux et les analyses des investisseurs et des clients avaient rendu toute analyse sérieuse de l’événement « à peu près impossible ». Chrome a répondu le jour même que ce n’était pas une excuse, et qu’eMudhra avait toujours des obligations envers les « milliards » de personnes qui dépendent du système et que son erreur avait exposées.

Le conseil d’administration d’eMudhra avait déjà décidé, le 22 octobre, de se retirer du marché mondial des certificats SSL/TLS. La société affirme que cette activité ne représente qu’une très petite part de ses opérations.

Ces mêmes entreprises écrivent aussi des règles communes avec les AC au sein d’un organisme appelé le CA/Browser Forum. Lors d’un scrutin clos le 11 avril 2025, dix-neuf jours avant qu’eMudhra ne génère les clés défectueuses, Apple, Google, Microsoft et Mozilla ont tous voté pour raccourcir la durée de vie des certificats de sites web, et 25 émetteurs de certificats, dont eMudhra, ont eux aussi voté pour. L’argument du texte soumis au vote était que la révocation ne protège pas correctement les gens à l’échelle d’Internet, alors que l’expiration le fait. « Les durées de validité des certificats, et leur application par les parties utilisatrices, sont incroyablement fiables », affirmait-il. Selon les règles en vigueur en octobre 2026, les certificats de sites web émis à partir du 15 mars 2026 peuvent durer au plus 200 jours ; à partir du 15 mars 2027, 100 jours ; et à partir du 15 mars 2029, 47 jours.

Ces plafonds s’appliquent aux certificats qu’utilisent les sites web, selon leur date d’émission. Le texte de la règle ne plafonne pas les certificats d’AC au cœur de cet incident, si bien que des durées de vie plus courtes n’auraient pas fait expirer les intermédiaires d’eMudhra. La révocation n’a pas disparu pour autant. Let’s Encrypt, l’autorité de certification gratuite, a fermé en août 2025 son service OCSP, qui permettait aux navigateurs de l’interroger sur un certificat à la fois, parce que chaque requête révélait à l’AC quel site était visité depuis quelle adresse internet. Les blocages d’urgence du 17 octobre étaient, de fait, des listes de révocation que les éditeurs de navigateurs avaient eux-mêmes établies et diffusées.

Ce dispositif concentre énormément de pouvoir entre quelques mains privées, pour la plupart américaines. Ce que montre l’affaire eMudhra, c’est la manière dont ce pouvoir s’exerce : dans un ticket ouvert où chacun peut lire les questions, les délais et les réponses, avec des motifs publiés par les entreprises mêmes qui procèdent au retrait.

Les certificats qui doivent déménager

Retirer une racine est rapide à annoncer et lent à absorber. Au 21 octobre, Chrome recensait environ 30 800 précertificats non expirés rattachés à emSign ECC Root CA – G3. Un précertificat est la copie d’un certificat soumise aux journaux de transparence avant son émission ; ce chiffre compte donc des certificats journalisés, non des sites web qui les utilisent encore. Parmi eux, 30 791, soit 99,9 %, provenaient de deux intermédiaires appartenant à InCommon, un service de certificats géré par Internet2, une organisation américaine de réseaux. Ces deux-là ne faisaient pas partie des huit intermédiaires défaillantes ; elles dépendaient simplement de la racine en cours de retrait. eMudhra estimait à environ 30 000 le nombre de certificats à migrer, presque tous émis via ACME, le protocole qui permet aux serveurs de demander et de renouveler automatiquement leurs certificats. eMudhra a cessé d’émettre sous la racine G3 le 20 octobre.

L’automatisation ne règle pas le problème à elle seule. Les clients ACME standard ne remplacent un certificat qu’à sa date de renouvellement, sauf s’ils prennent en charge une extension plus récente qui permet à l’AC de demander un renouvellement anticipé, ou si quelqu’un intervient à la main. Chrome a fait remarquer le 21 octobre que passer de la hiérarchie à courbe elliptique d’eMudhra à sa hiérarchie RSA pouvait aussi obliger à modifier les réglages du client.

Les certificats d’InCommon proviennent de CertiNext, un fournisseur dont la maison mère est eMudhra. Le 22 octobre, InCommon a fait savoir à ses abonnés que beaucoup d’entre eux avaient passé la semaine à réagir à des erreurs de certificat et à s’organiser autour de changements qui leur échappaient, après une migration réussie mais éprouvante au printemps et à l’été. Son conseil, ce matin-là, était de réémettre les certificats concernés en RSA jusqu’au rétablissement de l’émission à courbe elliptique.

eMudhra avait déclaré le 20 octobre que la seule solution de rechange pour ses clients G3 était des intermédiaires rattachées à sa racine RSA, emSign Root CA – G1. Mozilla a indiqué le jour même qu’elle ne retirait pas pour l’instant sa confiance à G1. G1 figurait parmi les certificats restants d’eMudhra que Chrome avait dit, le 20 octobre, examiner de près ; au 24 octobre, Chrome n’avait annoncé aucune décision. Le 21 octobre, Chrome a demandé à eMudhra de confirmer si les clients étaient transférés vers G1, vers la hiérarchie d’une autre société, ou vers les deux.

La mise à jour d’InCommon du soir du 22 octobre a réglé le problème immédiat. Les certificats à courbe elliptique étaient de nouveau émis, désormais rattachés à la racine G1, et les clients existants pouvaient renouveler sans rien changer à leurs réglages. La même mise à jour indiquait qu’eMudhra cesserait d’émettre à partir de toute intermédiaire rattachée à ses racines publiques dans 30 jours, à une date que CertiNext confirmerait, et qu’InCommon travaillait à une solution de remplacement. Pour des abonnés qui avaient achevé une migration éprouvante au printemps et à l’été, le retrait d’une seule racine en avait déclenché une autre.

Articles connexes

• Jusqu’où une liste de sanctions américaine atteint une cour de La Haye
• Quel avenir pour le bitcoin ?
• Comment l’IA fonctionne vraiment : ce que savent les développeurs et que les gros titres ignorent

Pour aller plus loin

En tant que Partenaire Amazon, Eikleaf réalise un bénéfice sur les achats remplissant les conditions requises. Les liens vers les livres ci-dessous sont des liens affiliés : si vous achetez par leur intermédiaire, nous pouvons percevoir une petite commission, sans frais supplémentaires pour vous.

• Histoire des codes secrets : de l’Égypte des pharaons à l’ordinateur quantique — Simon Singh (1999). Une histoire accessible de la cryptographie qui explique le chiffrement à clé publique, les mathématiques derrière les certificats et les clés privées de l’article.
• Security Engineering: A Guide to Building Dependable Distributed Systems (3rd ed.) — Ross Anderson (2001). La référence sur la façon dont les systèmes de sécurité réels échouent, avec des chapitres sur l’infrastructure à clé publique, les autorités de certification et la confiance.
• Secrets et mensonges : sécurité numérique dans un monde de réseau — Bruce Schneier (2001). Un grand auteur spécialisé en sécurité explique, sans mathématiques, pourquoi les certificats numériques et les chaînes de confiance ne valent que ce que valent les organisations qui les portent.

Vidéos recommandées

Avertissement relatif à l’IA générative

Certains contenus de cette page ont été générés et/ou édités avec l’aide d’une IA générative.

Médias

HTTPS et cadenas dans la barre d'adresse d'un site web – Wikimedia Commons (Photo : Santeri Viinamäki, CC BY-SA 4.0)

Module matériel de sécurité nCipher nShield F3 – Wikimedia Commons (Photo : Alexander Klink, CC BY 3.0)

Siège de Google, le Googleplex – Wikimedia Commons (Photo : Asoundd, CC BY-SA 4.0)

Principales sources et références

Mozilla Bugzilla. « Bug 2083449: eMudhra: Private key compromise of Intermediate Certificates. » Opened 18 October 2026, comments to 23 October 2026. https://bugzilla.mozilla.org/show_bug.cgi?id=2083449

Chrome and Android Security Teams. « Protecting Chrome and Android Users from Compromised eMudhra Intermediate CA Certificates. » Google, The Keyword, 20 October 2026. https://blog.google/security/protecting-chrome-and-android-users-from-compromised-emudhra-intermediate-ca-certificates/

Mozilla dev-security-policy mailing list. « Compromised eMudhra Intermediate Certificates » thread, posts by Dennis Jackson (Mozilla) and the Chrome Root Program, 20 October 2026, and by Wayne and Corey Bonnell, 21 October 2026. https://groups.google.com/a/mozilla.org/g/dev-security-policy/c/0R3XLJL6FuE

Jackson, Dennis. « eMudhra Intermediate CA Compromise. » Incident tracking site, 20 October 2026, updated 22 October 2026. https://emudhra.we-have-a-problem.com/

InCommon (Internet2). « Moving Forward Together: InCommon Certificate Service Update. » Updates of 22 October 2026. https://incommon.org/about/news/incommon-certificate-service-update

InCommon (Internet2). « InCommon Certificate Service FAQ. » Last updated 22 October 2026, 18:30 ET. https://incommon.org/certificates

Stanescu, Luci. « eMudhra CA compromise fixes available. » Ubuntu blog, Canonical, 20 October 2026, updated 22 October 2026. https://ubuntu.com/blog/emudhra-ca-compromise-fixes-available

Canonical. « USN-8944-1: ca-certificates update » and « USN-8944-2: ca-certificates update. » Ubuntu security notices, 20 October 2026. https://ubuntu.com/security/notices/USN-8944-1 and https://ubuntu.com/security/notices/USN-8944-2

Go team. « [security] Go 1.27.3 and Go 1.26.10 are released. » golang-announce, posted 20 October 2026 (releases dated 19 October 2026). https://groups.google.com/g/golang-announce/c/66pojueaQek

Go project. « Release History. » Accessed 24 October 2026. https://go.dev/doc/devel/release

certifi. « Remove emsign (#437), » « Restore unaffected emSign roots (#439) (#440) » and « 2026.10.23 (#445). » python-certifi repository, 18, 20 and 23 October 2026. https://github.com/certifi/python-certifi/commit/5cb238caeeb6c30ec1a7309ad3e16a5aa7b10ce8 and https://github.com/certifi/python-certifi/commit/662df63d7906df66f1f07c0751a3dfe9da14d914 and https://github.com/certifi/python-certifi/commit/b60466c9f2882d9cf088943c650b0faac06c080c

Cisco Talos. « Compromised eMudhra intermediate certificates. » Talos Intelligence blog, 21 October 2026. https://blog.talosintelligence.com/compromised-intermediate-certificates/

eMudhra Limited. « eMudhra Statement on distrust of select Global TLS Intermediate and one Root CA. » 21 October 2026. https://emudhra.com/en/press-release/emudhra-statement-distrust-global-tls-intermediate-root-ca

eMudhra Limited. « eMudhra to exit global SSL/TLS certificate business. » 22 October 2026. https://emudhra.com/en/press-release/emudhra-to-exit-global-ssl-tls-certificate-business

Abrams, Lawrence. « Mozilla, Google, Apple block compromised eMudhra CA certificates. » BleepingComputer, 20 October 2026. https://www.bleepingcomputer.com/news/security/mozilla-google-apple-block-compromised-emudhra-ca-certificates/

Helme, Scott. « Eight Bits of Trust; eMudhra’s CA keys cracked in milliseconds. » 20 October 2026. https://scotthelme.co.uk/eight-bits-of-trust-emudhras-ca-keys-cracked-in-milliseconds/

Sharwood, Simon. « Indian certification authority eMudhra’s private keys compromised – one of them was the number ‘4’. » The Register, 20 October 2026. https://www.theregister.com/a/5304312

Mozilla Bugzilla. « Bug 1970728: eMudhra: Invalid CRL signatures. » June 2025. https://bugzilla.mozilla.org/show_bug.cgi?id=1970728

Mozilla. « Firefox for Android 145.0 release notes. » 11 November 2025. https://www.firefox.com/en-US/firefox/android/145.0/releasenotes/

Cooper, D., et al. « RFC 5280: Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile. » IETF, May 2008. https://www.rfc-editor.org/rfc/rfc5280

Laurie, B., Langley, A., and Kasper, E. « RFC 6962: Certificate Transparency. » IETF, June 2013. https://www.rfc-editor.org/rfc/rfc6962

CA/Browser Forum. « Baseline Requirements for the Issuance and Management of Publicly-Trusted TLS Server Certificates, Version 2.3.1. » 4 October 2026, sections 3.2.2.4.7, 6.1.1.1 and 6.3.2. https://github.com/cabforum/servercert/blob/3574ae809e5f909b58ee4c26b7bac4a3b9e78421/docs/BR.md

CA/Browser Forum. « Ballot SC081v3: Introduce Schedule of Reducing Validity and Data Reuse Periods. » 11 April 2025. https://cabforum.org/2025/04/11/ballot-sc081v3-introduce-schedule-of-reducing-validity-and-data-reuse-periods/

Google. « Chrome Root Program Policy, Version 1.8. » Last updated 5 February 2026. https://googlechrome.github.io/chromerootprogram/crp/policy/

Mozilla. « Mozilla Root Store Policy, Version 3.1. » Effective 1 July 2026. https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/

Aas, Josh. « OCSP Service Has Reached End of Life. » Let’s Encrypt, 6 August 2025. https://letsencrypt.org/2025/08/06/ocsp-service-has-reached-end-of-life/

Adrian, David, Serena Chen, Joe DeBlasio, Emily Stark and Emanuel von Zezschwitz. « An update on the lock icon. » Chromium Blog, May 2023. https://blog.chromium.org/2023/05/an-update-on-lock-icon.html

von Zezschwitz, Emanuel, Emily Margarete Stark and Serena Chen. « ‘It builds trust with the customers’ – Exploring User Perceptions of the Padlock Icon in Browser UI. » SecWeb 2022, IEEE. https://research.google/pubs/it-builds-trust-with-the-customers-exploring-user-perceptions-of-the-padlock-icon-in-browser-ui/

Android Developers. « Network security configuration: Certificate transparency. » Accessed 24 October 2026. https://developer.android.com/privacy-and-security/security-config

Langley, Adam. « Maintaining digital certificate security. » Google Online Security Blog, July 2014. https://security.googleblog.com/2014/07/maintaining-digital-certificate-security.html

Adkins, Heather. « An update on attempted man-in-the-middle attacks. » Google Online Security Blog, 29 August 2011, updated 3 September 2011. https://security.googleblog.com/2011/08/update-on-attempted-man-in-middle.html

Fox-IT. « Black Tulip: Report of the investigation into the DigiNotar Certificate Authority breach. » 13 August 2012. https://zoek.officielebekendmakingen.nl/blg-191225.pdf