Quand une autorité de certification fait défaut : ce qu’il faut mettre à jour et ce qu’il faut reconstruire

Un navigateur corrigé ne veut pas dire un système corrigé

Lesquels de vos programmes font encore confiance à une autorité de certification dont les clés se sont révélées faibles ?

Avant que votre navigateur n’envoie quoi que ce soit de privé à un site web, ce site doit présenter un certificat, une attestation signée indiquant que le serveur appartient bien à ce site. La signature provient d’une autorité de certification, ou CA (certificate authority), une entreprise à laquelle les navigateurs et les systèmes d’exploitation ont accepté de faire confiance. En octobre 2026, un chercheur a signalé que les clés privées de huit certificats de signature d’une CA, eMudhra, pouvaient être récupérées.

Chrome et Firefox ont bloqué ces clés le jour même, et Apple et Microsoft ont suivi dans les jours suivants. Les programmes Go, les serveurs Node.js, les environnements Python et les images de conteneur ne reçoivent pas cette protection automatiquement. Chacun a besoin de sa propre mise à jour, et certains doivent être reconstruits.

Ce qui s’est passé

Le signalement est parvenu à Apple, Google, Microsoft, Mozilla et eMudhra le 17 octobre. Les certificats concernés étaient des CA intermédiaires. Une CA intermédiaire se place entre une racine de confiance et les certificats qu’utilisent les sites web. La racine signe l’intermédiaire, et l’intermédiaire signe le certificat du site. Six des huit servaient aux certificats de sites web, ceux qu’utilise TLS (le protocole derrière le cadenas du navigateur), et deux à la signature de code.

Une clé privée devrait être un très grand nombre aléatoire. Celles-ci étaient toutes inférieures à 256, si bien qu’un attaquant pouvait simplement essayer toutes les possibilités. BleepingComputer, qui a vérifié une clé publiée en la comparant à un certificat révoqué, rapporte que l’une d’elles valait tout juste 4. eMudhra affirme qu’une erreur de script lors d’une cérémonie de génération de clés a produit un second jeu de clés, plus faibles, et que celles-ci ont été choisies par erreur pour la signature. Elles dataient d’avril 2025. L’entreprise dit n’avoir constaté ni usage abusif ni intrusion, et avoir révoqué les CA concernées en moins de 14 heures.

Chrome a bloqué les six intermédiaires TLS dans les deux heures suivant le signalement, par une mise à jour qui ne demande aucun redémarrage. Google a aussi retiré du Chrome Root Store la racine qui les avait signés, emSign ECC Root CA – G3. Ce retrait était prévu pour le matin du 27 octobre : vérifiez donc que votre Chrome l’a bien reçu. Firefox a bloqué les certificats le 17 octobre, et Mozilla a décidé le 20 octobre de ne plus faire confiance à cette même racine. Apple a bloqué les certificats le 19 octobre et la racine le 23 octobre.

Le 26 octobre, Microsoft a publié des mises à jour Windows hors bande qui retirent sept certificats liés à eMudhra de la liste de confiance de Windows. Elles visent les systèmes qui ne peuvent pas récupérer seuls les mises à jour de confiance. Microsoft indique examiner encore les autres racines d’eMudhra.

Google ajoute qu’aucun certificat de site web émis par les six intermédiaires n’apparaissait dans les journaux Certificate Transparency, les registres publics des certificats émis, avant le blocage. Chrome, ainsi que les applications Android qui imposent ces journaux, aurait rejeté un certificat falsifié, ce qui limite le risque de leur côté. On ignore si quelqu’un a exploité cette faiblesse contre d’autres types de logiciels. eMudhra a annoncé qu’elle quitterait le marché mondial des certificats TLS.

Ce qu’un attaquant pourrait en faire

Quiconque détient la clé privée d’une CA peut signer un certificat pour n’importe quel site web, et tout programme qui fait confiance à cette CA l’acceptera. Pour s’en servir, l’attaquant doit encore se placer entre vous et le serveur, par exemple sur un réseau hostile. Cloudflare ne signale aucune exploitation sur ses services, et StepSecurity n’a trouvé aucun signalement d’usage abusif dans les pipelines de build.

Pourquoi un seul correctif n’atteint pas tous les programmes

Un magasin de confiance (trust store) est la liste des CA auxquelles un programme accepte de faire confiance. Pensez à la liste des invités à l’accueil d’un immeuble. Votre système d’exploitation tient une liste, votre navigateur peut en tenir une autre, et chaque accueil ne consulte que la sienne. Beaucoup de programmes apportent leur propre copie de la liste, pour se comporter de la même façon sur toutes les machines.

Imaginons que votre ordinateur portable soit entièrement à jour. Vous lancez un script Node.js intégré à une image de conteneur en septembre. Ce script transporte son propre magasin de confiance : il fait donc toujours confiance à la CA, et le correctif de l’ordinateur portable ne le touche jamais.

L’avis d’Apple montre la même séparation. Le blocage s’applique automatiquement dans Safari, Mail et les applications qui utilisent les frameworks de sécurité d’Apple. Les outils en ligne de commande qui lisent un fichier de certificats sur disque, comme curl, git, python3, ruby, perl et openssl, peuvent continuer d’accepter les certificats jusqu’à une future mise à jour de macOS. Les applications qui ont leur propre liste ne sont pas couvertes, et Apple conseille de s’adresser au développeur.

Mettre à jour et reconstruire sont deux tâches différentes. Certains programmes lisent leur magasin de confiance au démarrage : un fichier plus récent ou un redémarrage suffit alors. Dans d’autres, le correctif fait partie du programme lui-même. Un programme Go contient la bibliothèque standard de Go dans le fichier final, si bien que corriger la chaîne d’outils ne change rien pour un programme compilé le mois dernier. Il doit être recompilé.

Ce dont chaque outil a besoin

Ces correctifs sont apparus à partir du 19 octobre. Consultez la page de chaque projet avant d’agir, car les versions continuent d’évoluer.

Outil	Version à avoir	Pourquoi ce n’est peut-être pas encore corrigé
Go	1.27.3 ou 1.26.10 (19 octobre)	L’avis de Go mentionne seulement des « correctifs de sécurité pour crypto/x509 ». D’autres sources relient ces versions à cet incident, vérifiez donc dans les notes de version de Go. Les programmes déjà compilés gardent l’ancien code : reconstruisez-les avec la chaîne d’outils corrigée.
Node.js	22.23.4, 24.22.1 ou 26.12.1 (21 octobre)	Node.js mentionne « ca-cert (eMudhra Intermediate CA Compromise) » dans ces versions et livre son propre magasin de confiance. Une mise à jour du système ne le modifie pas, et les images contenant une version plus ancienne de Node.js doivent être reconstruites.
Python	3.15.2, 3.14.10, 3.13.18, 3.12.16 ou 3.11.18, ou plus récent, avec pip 26.2.2, certifi 2026.10.19 et uv 0.13.5 ou ultérieur	pip transporte sa propre copie de certifi, donc chaque environnement virtuel doit être mis à jour séparément. Les versions 3.11 et 3.12 ne sont publiées que sous forme de code source. Python 3.10 et les versions antérieures sont en fin de vie et n’ont reçu aucun correctif.
Rust	rustls-webpki 0.103.16 et webpki-roots 1.0.10	Ce sont des bibliothèques. Tout ce qui est construit dessus doit être reconstruit et redéployé.
Deno	2.9.8	Deno livre son propre magasin de confiance.
curl	Un fichier de CA (bundle) daté du 2026-10-20 ou plus récent	Le correctif se trouve dans le fichier de CA que lit curl : vérifiez donc lequel utilise le vôtre.
Distributions Linux	Un paquet ca-certificates plus récent	Les versions diffèrent selon la distribution. Lisez l’avis de la vôtre.
Windows	La mise à jour hors bande de Microsoft du 26 octobre	Selon les informations publiées, elle vise les machines hors ligne, celles qui ne peuvent pas joindre le service de mise à jour de confiance de Microsoft et celles dont les mises à jour automatiques sont désactivées. La couverture de Windows Server n’est pas confirmée.
Cloudflare Tunnel	cloudflared 2026.10.2	Les utilisateurs de conteneurs doivent redéployer l’image corrigée.
Docker Desktop, curl sous macOS	Docker Desktop 4.96.3 ou ultérieur. Aucune version corrigée de curl sous macOS confirmée	Les notes de version de Docker indiquent le correctif dans les versions 4.96.1, 4.96.2 et 4.96.3 (21 et 22 octobre) et précisent qu’il est déployé composant par composant : continuez donc à mettre à jour. Apple n’a nommé aucune version corrigée de curl sous macOS, ne supposez donc pas qu’il est couvert.

Python est le plus délicat de tous. Python 3.15.1, 3.14.9 et 3.13.17 sont sortis le 21 octobre avec pip 26.2.2 intégré, et d’autres versions ont suivi. Un nouvel interpréteur ne modifie pas le pip d’un ancien environnement virtuel : mettez donc à jour pip et uv dans chacun des environnements existants. Les interpréteurs corrigés bloquent aussi les clés compromises dans le module ssl lorsque la vérification est activée. C’est une dernière ligne de défense : mettez quand même à jour le magasin de confiance.

Quel niveau de connaissance viser

Connaître : tout développeur et tout professionnel de l’informatique (IT) devrait savoir ce qu’est une CA et que certains programmes ont leur propre magasin de confiance. Cela suffit pour suivre le prochain incident touchant une CA.

Appliquer : les ingénieurs qui construisent ou exploitent des logiciels devraient savoir repérer les programmes et images qui embarquent leur propre magasin de confiance, mettre à jour ceux qui lisent un fichier, et reconstruire ceux dans lesquels le correctif est compilé.

Maîtriser : les responsables plateforme et sécurité tiennent l’inventaire de ce qui tourne où, reconstruisent les images à intervalles réguliers pour que les correctifs n’attendent pas une nouvelle version, et décident quels outils peuvent s’appuyer sur le magasin du système.

Ce que vous pouvez ignorer pour l’instant

Laissez de côté les avis concernant des outils que vous n’utilisez pas, ainsi que les décomptes de certificats. Le chiffre de Chrome et celui d’un index public des journaux diffèrent d’un facteur trois, et ils ne mesurent pas la même chose.

Une vérification en une heure

1. Vos propres certificats. Si l’un de vos sites utilise un certificat qui remonte à la racine emSign, remplacez-le par un certificat d’une autre CA. Google recommande de le faire dès maintenant. Cette commande affiche l’émetteur immédiat :

   openssl s_client -connect yoursite.example:443 -servername yoursite.example </dev/null 2>/dev/null | openssl x509 -noout -issuer

   Cherchez « emSign » ou « eMudhra », et en cas de doute, lisez la chaîne complète dans votre outil de gestion des certificats.
2. Go. Lancez ceci sur les machines de build :

   go version

   Pour un programme compilé, cette commande affiche la version de Go qui l’a compilé :

   go version -m ./yourprogram

   Reconstruisez tout ce qui est antérieur à 1.27.3 ou 1.26.10.
3. Node.js. Lancez ceci sur les serveurs et dans les images :

   node -v

   Mettez à jour et reconstruisez tout ce qui est antérieur aux versions du tableau.
4. Python. Dans chaque environnement qui compte, lancez :

   python -m pip --version
   python -m pip show certifi

   Cherchez aussi les paramètres qui pointent vers un ancien fichier de CA, comme PIP_CERT, REQUESTS_CA_BUNDLE et SSL_CERT_FILE. Un ancien fichier de CA reste utilisé après la mise à jour des paquets.
5. Conteneurs. Récupérez des images de base récentes et reconstruisez sans le cache des couches, par exemple avec --pull --no-cache, pour que les anciennes couches ne transmettent pas l’ancien magasin de confiance. Puis redéployez.
6. Terminaux Mac. curl, git et python3 sur un Mac n’ont peut-être pas encore le blocage d’Apple. Les étapes provisoires d’Apple pour les administrateurs consistent à retirer emSign ECC Root CA – G3, et éventuellement AAA Certificate Services, de /etc/ssl/cert.pem. Suivez exactement l’avis d’Apple, testez ensuite, et attendez-vous à répéter les étapes si une mise à jour de macOS remplace le fichier.
7. Erreurs de certificat. Si une erreur apparaît après une mise à jour, corrigez le certificat. Ne désactivez pas la vérification.

Que faire ensuite

Choisissez un service et suivez-le de bout en bout. Notez quel programme établit la connexion sécurisée, d’où vient son magasin de confiance, et qui le reconstruit. Si personne n’est responsable de la reconstruction, elle n’aura pas lieu.

Un correctif du système d’exploitation n’atteint pas les programmes qui embarquent leur propre magasin de confiance.

Ce que l’on sait et ce que l’on ignore

Affirmation	Nature	Source
Huit clés de CA intermédiaires d’eMudhra pouvaient être récupérées : six pour TLS, deux pour la signature de code	Signalement d’un chercheur, accepté par les navigateurs	Avis de Google, de Mozilla et d’Apple, et The Hacker News
Les huit clés étaient toutes inférieures à 256	Rapporté	The Hacker News
Une clé valait 4	Rapporté. BleepingComputer dit avoir vérifié une clé publiée en la comparant à un certificat révoqué	BleepingComputer
Microsoft a retiré de Windows sept certificats liés à eMudhra le 26 octobre	Rapporté. Billet de Microsoft lui-même non consulté	BleepingComputer
Une erreur de script lors d’une cérémonie de clés a produit les clés faibles	Déclaration d’eMudhra. Son message sur le bug Mozilla décrit une faille de code qui a créé des clés plus faibles, ensuite utilisées par erreur	Digit et bug Mozilla 2083449, commentaire 11
Aucun usage abusif, aucune intrusion, des clés jamais utilisées pour émettre des certificats à des sites web ou à des utilisateurs, révoquées en moins de 14 heures	Déclarations d’eMudhra, non vérifiées de façon indépendante	Digit, bug Mozilla 2083449, commentaire 10 et commentaire 43
Aucun certificat TLS concerné n’avait été journalisé avant le blocage de Chrome	Déclaration de Google	Google Security Blog
Si des attaquants ont exploité la faiblesse contre des logiciels autres que les navigateurs	Inconnu	StepSecurity
Environ 30 800 certificats non expirés sous la racine, dont 99,9 % via InCommon	Décompte de Chrome, tel que rapporté	The Hacker News
Plus de 100 000 certificats sous les intermédiaires	Index public des journaux. Il en affichait 107 181 le 29 octobre, entrées de sondage et de test comprises	ctlogs.dev
Versions corrigées de Node.js et de Python	Indiquées par les projets ou par un article sur l’outillage Python	Notes de version de Node.js et pydevtools
Les versions corrigées de Go sont liées à cet incident	L’avis de Go ne mentionne que des correctifs pour crypto/x509. Le lien vient d’autres sources	Historique des versions de Go
Correctifs pour Rust, Deno, curl et les distributions Linux	Une seule synthèse, non vérifiée projet par projet	smartscope.blog
Versions corrigées de Docker Desktop et de curl sous macOS	Docker Desktop : documenté par Docker dans les versions 4.96.1 à 4.96.3, déployé par lots. curl sous macOS : inconnu, aucune version corrigée nommée	Notes de version de Docker Desktop et Assistance Apple
Le retrait de la racine par Chrome a atteint tous les appareils le 27 octobre	Prévu, non confirmé	Google Security Blog

Pour aller plus loin

• Google: Protecting Chrome and Android users from compromised eMudhra intermediate CA certificates, pour le côté navigateur et les conseils aux exploitants de sites.
• Apple Support: About the compromised eMudhra intermediate CAs, y compris la limite concernant les outils en ligne de commande.
• Cloudflare: eMudhra certificate compromise, pour cloudflared et les certificats d’origine.
• The Hacker News: eMudhra to exit global SSL/TLS business, pour les dates, les déclarations d’eMudhra et le décompte de Chrome.
• BleepingComputer: Mozilla, Google and Apple block compromised eMudhra CA certificates, pour le blocage de Firefox et la valeur de clé 4, et BleepingComputer: Microsoft’s Windows updates.
• Digit: eMudhra apologises after weak keys expose 8 intermediate CAs, pour la version d’eMudhra sur l’origine du problème.
• Bug Mozilla 2083449, où eMudhra et les programmes racine des navigateurs discutent de l’incident.
• ctlogs.dev: eMudhra CA compromise, pour les décomptes de certificats tirés des journaux publics.
• Historique des versions de Go, pour 1.27.3 et 1.26.10.
• smartscope.blog : ce qu’il faut mettre à jour, une synthèse qui couvre Rust, Deno, curl et les distributions Linux.
• Notes de version de Docker Desktop, qui mentionnent le retrait de la confiance accordée à la CA intermédiaire d’eMudhra dans Docker Desktop 4.96.1 à 4.96.3.
• Node.js October 2026 security releases.
• Annonce de Python 3.15.1, 3.14.9 et 3.13.17 et pydevtools : mises à jour de Python.
• StepSecurity : effet sur pip et la CI/CD, pour les outils qui embarquent leur propre magasin de confiance.
• À lire aussi sur ce site : la vulnérabilité Brotli de Node.js (en anglais), des vulnérabilités critiques dans PHP (en anglais) et les changements de Node.js, Docker et Go qui cassent les pipelines (en anglais).

Les faits de cet article ont été vérifiés le 29 octobre 2026. Les numéros de version et les actions des navigateurs évoluent vite : consultez les sources ci-dessus avant d’agir.