Après ses clés trop faibles, eMudhra renonce aux certificats HTTPS

L’autorité de certification indienne eMudhra a annoncé jeudi 22 octobre qu’elle quittait le marché mondial des certificats SSL/TLS, ceux qui garantissent aux internautes qu’un site en HTTPS est bien celui qu’il prétend être. La décision intervient cinq jours après le signalement d’une faute grave : les clés de huit de ses certificats intermédiaires, ceux qui signent par délégation les certificats des sites, avaient été mal générées, au point que n’importe qui pouvait les recalculer à partir des certificats publics, et donc fabriquer un certificat valide pour n’importe quel site. Il ne s’agit pas d’un vol ni d’un piratage, mais d’une erreur de fabrication. Firefox et Chrome rejettent ces certificats depuis la nuit du 17 au 18 octobre, les appareils Apple et Android et les systèmes de Microsoft depuis le 19 ou le 20 ; des logiciels qui embarquent leur propre liste de confiance ont dû être corrigés un par un.

Une erreur de cérémonie, des clés recalculables en un instant

Une clé privée de certificat est un très grand nombre tiré au hasard, que personne ne doit pouvoir deviner. Celles d’eMudhra ne l’étaient pas. Google parle de clés « générées avec un hasard insuffisant » dans son billet du 20 octobre ; la page de divulgation consacrée à l’affaire écrit qu’elles ont été « générées de manière incorrecte par l’autorité », si bien que « n’importe qui peut les retrouver à partir des certificats ». L’équipe indienne de réponse aux incidents informatiques, le CERT-In, donne le détail dans son avis du 21 octobre : ces clés, qui auraient dû être des nombres de 384 bits (de l’ordre de 10 puissance 115 possibilités), avaient des valeurs « inférieures à 256 » et pouvaient être retrouvées « presque instantanément » à partir de la clé publique, celle qui figure dans le certificat.

eMudhra a donné sa version le 19 octobre dans le dossier ouvert sur le Bugzilla de Mozilla, l’outil où les autorités rendent compte de leurs incidents. Lors d’une cérémonie de génération de clés le 30 avril 2025, une « dérogation approuvée » à la procédure habituelle, destinée à tester l’export des clés, a fait créer par erreur une seconde paire de clés « plus faibles » ; celles-ci ont été utilisées « par erreur » pour la demande de certificat, « parce que les étiquettes des clés étaient similaires ». Les certificats ainsi produits ont été signés par la racine d’eMudhra, le certificat principal que reconnaissent les navigateurs, puis contre-signés par une autre autorité, Sectigo. Une contre-signature permet à un intermédiaire d’être reconnu par des appareils qui ne connaissent que la racine de l’autre autorité.

Un correspondant qui signe « Wayne » a prouvé la faille en signant un court message, « We have a problem here - Wayne », avec chacune des huit clés, avant de l’envoyer aux équipes qui gèrent les listes de confiance des navigateurs, selon la page de divulgation. Cette page est publiée par Dennis Jackson, qui s’exprime au nom de Mozilla sur la liste de discussion dev-security-policy, le forum public où se discutent les règles imposées aux autorités de certification. Elle ne dit pas qui est « Wayne ».

Pourquoi une seule clé suffit pour tout le web

Quand un navigateur affiche une page en HTTPS, il vérifie que le site présente un certificat, une sorte de carte d’identité numérique, signé par une autorité de certification à laquelle il fait confiance. La liste des autorités qu’un logiciel accepte s’appelle son magasin de certificats racines (Mozilla, Google, Apple et Microsoft tiennent chacun le leur). eMudhra y figure sous le nom de ses racines emSign (fiche Bugzilla de Mozilla).

L’autorité ne signe presque jamais avec sa clé principale, la racine, gardée hors ligne. Elle délègue à des certificats intermédiaires, qui signent à leur tour les certificats des sites. Or un intermédiaire peut techniquement signer un certificat pour n’importe quel nom de domaine. Celui qui possède sa clé privée, le secret qui sert à signer, peut donc se délivrer un certificat « valide » pour une banque ou une messagerie qu’il ne contrôle pas. Avec une position sur le réseau (un Wi-Fi piégé, par exemple), il peut alors se faire passer pour ce site et lire ce que l’utilisateur croit envoyer en sécurité. Un attaquant muni de l’une de ces clés « pourrait se faire passer pour n’importe quel site web ou service », résume la page de divulgation.

Ce qu’affirme eMudhra, ce que montre le dossier

Dans son communiqué du 22 octobre, eMudhra présente son départ comme un choix d’entreprise : ces certificats représentaient « environ 1 % » de son chiffre d’affaires mondial, et son conseil d’administration juge le retrait approprié face à des exigences de conformité croissantes et à un rendement moindre que le reste de ses activités. Son président, V. Srinivasan, affirme que l’entreprise a traité l’incident « avec diligence », en révoquant les autorités concernées « dans les 14 heures suivant la découverte ». Le communiqué assure qu’aucun certificat de site n’a été émis par ces autorités, que son infrastructure « n’a pas été compromise » et qu’aucune donnée n’a fuité. eMudhra promet de contacter ses clients pour remplacer gratuitement leurs certificats « auprès de partenaires » ; ses certificats de signature électronique et ses autres services de signature continuent. Dans sa déclaration d’incident, eMudhra affirme que le retrait de confiance ne touche qu’un écosystème de clients, aux États-Unis, et reconnaît que le défaut est passé inaperçu « environ 18 mois », malgré deux cycles d’audit indépendants.

Le dossier Bugzilla permet de dater ces étapes : eMudhra a accusé réception du signalement le 17 octobre à 23 h 28 (heure de Paris) et révoqué les huit intermédiaires le 18, entre 11 h 24 et 11 h 38. L’absence de piratage est cohérente avec la cause décrite, une faute de fabrication et non une intrusion. Mais les questions continuent. Le Chrome Root Program, l’équipe qui gère le magasin de racines de Chrome, demande à eMudhra (commentaire 30) pourquoi le rapport d’un incident antérieur, des listes de révocation (les listes de certificats annulés que publie l’autorité) dont la signature ne se vérifiait pas, avait omis que deux paires de clés existaient pour chacune de ces autorités. Un autre participant, Q Misell, lui demande depuis l’annonce le nom du partenaire qui reprendra ses clients et le calendrier des remplacements. Les navigateurs n’avaient pas attendu cette révocation, qui ne suffit de toute façon pas : beaucoup de logiciels ne consultent pas les listes de révocation, et Chrome comme Firefox avaient bloqué les intermédiaires dès le 17 au soir.

Du signalement aux blocages

Les heures sont données en heure de Paris (UTC + 2). Firefox et Chrome disposent chacun d’une liste de blocage envoyée en continu aux navigateurs installés, OneCRL chez Mozilla, CRLSet chez Google ; NSS est la bibliothèque qui contient la liste de racines de Mozilla, reprise par de nombreux autres logiciels.

Firefox et Chrome n’ont donc pas attendu une nouvelle version. OneCRL apporte cette protection « sans que les utilisateurs aient à mettre à jour ou à redémarrer Firefox », écrit Mozilla dans son billet du 20 octobre, et la diffusion était achevée « moins de 3 heures » après le signalement. Mozilla a ajouté le 21 octobre Firefox 158.0.2 pour Android, pour certains appareils qui n’appliquaient pas immédiatement les changements de OneCRL au démarrage.

Chrome a bloqué six intermédiaires et non huit : les deux autres ne servent qu’à signer du code, et sa logique de vérification ne permet pas de les utiliser pour un site web, explique le Chrome Root Program sur dev-security-policy. Le blocage vise l’empreinte de la clé publique elle-même : il protège donc aussi, précise Chrome, contre les versions contre-signées par Sectigo, qui partagent les mêmes clés. La racine Sectigo à l’origine des contre-signatures avait déjà été retirée du magasin de Chrome en avril 2025. Google annonce que la racine d’eMudhra concernée, emSign ECC Root CA - G3, sortira de ce magasin le 27 octobre au matin, heure de la côte Pacifique, et demande aux sites qui en dépendent d’obtenir « immédiatement » un certificat d’une autre autorité.

Pour Android, Google indique que les appareils ont reçu un blocage équivalent par les services Google Play le lundi 19 octobre vers 22 h UTC (minuit à Paris), que la plupart l’avaient déjà reçu le 20, et qu’un redémarrage force la mise à jour. Pour Apple et Microsoft, la seule source primaire reste la page de divulgation ; aucun des deux n’a publié de note que nous ayons pu lire.

Des certificats pour google.com déjà publics

Le Chrome Root Program avance un argument précis : Chrome et d’autres navigateurs n’acceptent par défaut un certificat de site que s’il a été inscrit dans les journaux de transparence des certificats, des registres publics où les émissions sont consignées (c’est grâce à eux que Google avait repéré d’autres victimes du détournement de trois registres de noms de domaine). Or aucun certificat de site rattaché à ces six intermédiaires n’y figurait avant le blocage du 17 octobre ; aucun faux certificat issu d’eux « n’a donc pu être accepté par défaut » par ces navigateurs.

Cet argument porte sur la période d’avant le blocage. Depuis, les clés étant à la portée de tous, des certificats forgés avec elles sont apparus dans ces journaux. Selon ctlogs.dev, un site qui analyse ces journaux, 105 901 certificats portant le nom google.com, signés par l’un des intermédiaires d’eMudhra (EM EV TLS CA - G3B), y ont été inscrits le 21 octobre. eMudhra ne les a pas émis : ils ont été fabriqués avec la clé recalculée, par un auteur inconnu. Ceux que ctlogs.dev détaille ont tout d’une démonstration : ils portent la mention « PoC » (preuve de concept) et « eMudhra key lol », et n’étaient valables qu’un jour, jusqu’au 22 octobre. Mais n’importe qui peut en fabriquer d’autres : pour les logiciels qui ne vérifient pas ces registres, écrit ctlogs.dev, ces certificats « sont déjà publics », et intercepter leur trafic « ne demande rien de plus ». Navigateurs et systèmes à jour les rejettent, puisque les intermédiaires sont bloqués.

Aucune attaque n’a été signalée. Les divulgations publiques « n’établissent pas d’exploitation malveillante confirmée » au 21 octobre, écrit le CERT-In. La page de divulgation est plus prudente pour les logiciels qui ne vérifient pas les registres : « Nous ne savons pas si des attaquants ont exploité » la faille contre eux. Dennis Jackson a par ailleurs répondu le 20 octobre, sur dev-security-policy, qu’« à ce stade » Mozilla ne pensait pas que le problème concerne d’autres autorités.

Ceux qui n’ont pas de liste de blocage

Le risque se loge dans les logiciels qui vérifient les certificats sans OneCRL ni CRLSet, avec la liste de racines du système ou une copie livrée avec eux : serveurs et postes Linux, programmes écrits en Go, applications de bureau construites avec Electron, scripts Python, Node.js, PHP. Beaucoup reprennent la liste de Mozilla. C’est pour eux que Mozilla a retiré la racine entière dans NSS 3.131.1 : la mesure « n’est pas nécessaire pour Firefox », mais protège les utilisateurs de cette liste « qui ne bénéficient pas de la protection de OneCRL », écrit Dennis Jackson.

Le retrait a un prix, qu’il reconnaît : il « affectera la disponibilité de certains serveurs » pour ces utilisateurs, tant que les sites légitimes qui dépendent de cette racine n’auront pas changé de chaîne de certificats. Il recommande aux gestionnaires de listes de bloquer d’abord les seuls intermédiaires concernés quand leur logiciel le permet, et de ne retirer les racines qu’à défaut. En quelques jours, les principaux ont publié :

Sources : Node.js, go.dev, Composer, curl, Homebrew, Debian 12, Debian 13, Ubuntu, Alpine, page de divulgation pour Electron, certifi et Rust. La page de divulgation marque encore Composer lui-même « en attente », alors que sa bibliothèque ca-bundle est publiée. Debian retire les racines emSign ECC Root CA - G3 et Comodo AAA Services root ; Ubuntu met emSign ECC Root CA - G3 sur liste noire. Pour un système qui n’a pas encore reçu son paquet, la page de divulgation donne la marche à suivre pour retirer soi-même la confiance à ces racines.

Ce que chacun doit faire

Pour le grand public, la consigne de la page de divulgation tient en une ligne : mettre à jour navigateur et système d’exploitation « dès que possible ». Firefox et Chrome dans leur configuration d’origine sont protégés depuis la nuit du 17 au 18 octobre, les téléphones Android depuis la nuit du 19 au 20 (un redémarrage force la mise à jour), les appareils Apple depuis le 19 et les produits Microsoft depuis le 20, selon la même page. Aucune manipulation manuelle n’est demandée.

Les développeurs et administrateurs ont davantage à vérifier : la version de Go qui a servi à compiler leurs programmes, celle de Node.js et d’Electron, le paquet certifi de leurs environnements Python, la bibliothèque ca-bundle de leurs projets PHP, le paquet ca-certificates de leurs serveurs, et les copies de cacert.pem livrées avec des applications ou des appareils, que personne ne met à jour. Les sites dont le certificat remonte à la racine emSign ECC Root CA - G3 doivent en changer avant le 27 octobre, date à laquelle Chrome la retire. C’est dans ces logiciels oubliés que les huit clés d’eMudhra, désormais connues de tous, garderont le plus longtemps une valeur.

Les citations d’eMudhra, de Google, de Mozilla, du CERT-In, de ctlogs.dev et de la page de divulgation sont traduites de l’anglais par la rédaction.