Certains liens de cette page sont des liens d'affiliation : si vous vous inscrivez via ces liens, ce site touche une commission, sans surcoût pour vous. Les prix et les recommandations ne changent pas.

Le 17 octobre 2026, un chercheur a signalé aux programmes racine que les clés privées de huit autorités de certification intermédiaires d’eMudhra étaient compromises, et il l’a prouvé de la manière la plus dure : il a signé un court message avec chacune des huit clés et joint les signatures. N’importe qui peut les vérifier avec OpenSSL. Les clés étaient récupérables depuis avril 2025.

Les navigateurs ont été corrigés en quelques jours. Firefox et Chrome ont bloqué les intermédiaires le 17, les plateformes Microsoft le 20, les produits Apple le 22. Ce avec quoi vous naviguez est, à présent, en règle.

Les machines que vous administrez, c’est une autre affaire. Voici la checklist pour celles-là, plus les éléments de l’histoire qui décident de ce qu’il faut vérifier. Tout ce qui concerne l’incident vient de la page de l’incident, que nous avons relue le jour de la publication. Nous avons lancé les quatre points de test de l’étape 1 sur une de nos machines Ubuntu 26.04, et les quatre ont échoué avec une erreur de certificat, ce qui est le résultat voulu. Nous n’avons pas audité chaque environnement d’exécution dessus, et les étapes ci-dessous ne sont pas le compte rendu de ce travail.

Ce qui s’est réellement cassé

Les huit intermédiaires remontent à des racines auxquelles font confiance les programmes racine de Mozilla, Microsoft, Apple et Chrome. Quiconque détient l’une des clés privées peut fabriquer un certificat pour n’importe quel domaine, et un client qui fait encore confiance à l’intermédiaire l’acceptera.

La cause mérite d’être retenue. La CA a mal généré ces clés, si bien qu’on peut les retrouver à partir des certificats eux-mêmes. C’était vrai dès la création des certificats, en avril 2025. Les journaux Certificate Transparency ne contiennent aucune entrée pour ces intermédiaires sur cette période, donc les clients qui imposent CT, c’est-à-dire les grands navigateurs, ne pouvaient pas être attaqués par ce biais. Pour les clients qui ne vérifient pas CT, c’est une autre histoire, et la page de l’incident dit clairement que personne ne sait si des attaquants ont exploité la faille contre eux.

La CA a révoqué les intermédiaires, et les programmes racine ont diffusé cette révocation par leurs propres canaux : OneCRL et CRLite chez Mozilla, CRLSets chez Chrome. C’est ainsi qu’un navigateur reste protégé sans nouvelle version. Un très grand nombre de clients ne consultent aucun de ces canaux.

Deux couches de confiance, et une seule a été touchée

La plupart des guides d’auto-hébergement mélangent les deux, d’où l’intérêt de les séparer.

Vos certificats vont bien. Si Caddy, Traefik, acme.sh ou certbot obtient vos certificats auprès de Let’s Encrypt, rien n’a changé pour eux. Les intermédiaires d’eMudhra ne figurent pas dans cette chaîne, et ni le protocole ACME ni vos clés de compte n’étaient en cause. Le renouvellement continue de fonctionner.

Ce que vos outils jugent digne de confiance, c’est la partie exposée. Chaque requête HTTPS sortante de votre serveur (git pull, curl vers une API, une installation de paquet, un pull de conteneur, un webhook) ne vaut que ce que vaut le magasin de certificats de la machine. S’il contient encore les mauvais intermédiaires, quelqu’un sur le chemin réseau peut se faire passer pour GitHub, votre miroir de paquets ou n’importe quelle API, et le client l’acceptera sans broncher.

C’est tout le risque, et l’essentiel se trouve dans des logiciels qui ne sont pas des navigateurs.

Pourquoi « mettre à jour l’OS » ne suffit pas

Deux choses distinguent les navigateurs de tout le reste ici.

D’abord la révocation. Les navigateurs font révoquer ces intermédiaires via OneCRL, CRLite et CRLSets. curl, git, les binaires Go et la plupart des environnements d’exécution n’utilisent rien de tout cela, et pour eux le seul remède est un magasin de confiance qui ne contient plus les intermédiaires.

Ensuite Certificate Transparency. Les navigateurs refusent les certificats qui n’ont jamais été journalisés. La plupart des clients hors navigateur s’en moquent. La page de l’incident exploite deux hôtes de test supplémentaires pour cela : leurs certificats n’ont jamais été journalisés dans CT, donc un client qui s’y connecte fait confiance aux mauvais intermédiaires et n’impose pas non plus CT. C’est cette combinaison qu’un attaquant peut exploiter sans que personne ne s’en aperçoive.

Le travail n’est donc pas une mise à jour, mais une par programme qui embarque son propre magasin de confiance ou en hérite.

L’audit en 30 minutes

À lancer sur chaque serveur, runner CI et poste de dev que vous touchez. Chaque étape tient en une ou deux commandes.

1. Mettre à jour le bundle de CA du système

Debian et Ubuntu :

sudo apt update && sudo apt upgrade -y ca-certificates

RHEL, Fedora, Alma, Rocky :

sudo dnf upgrade -y ca-certificates

Alpine :

sudo apk upgrade ca-certificates

Les versions corrigées des paquets sont listées sur la page de l’incident. Pour Debian 12, c’est 20250419~deb12u2, pour Ubuntu 24.04 20260816ubuntu0.24.04.1, pour Alpine 20261020-r0. Comparez avec dpkg -l ca-certificates ou apk info ca-certificates, puis faites le vrai test. Une erreur de certificat signifie que ce client ne fait pas confiance aux intermédiaires compromis. Une réponse réussie signifie que vous êtes encore exposé :

curl https://dv-g3b-emudhra.we-have-a-problem.com/
curl https://dv-g3b-aaa-emudhra.we-have-a-problem.com/
curl https://dv-g3b-noct-emudhra.we-have-a-problem.com/
curl https://dv-g3b-aaa-noct-emudhra.we-have-a-problem.com/

Si vous exécutez Java depuis les paquets Debian ou Ubuntu, il reste une chose : la mise à jour du système ne rafraîchit pas le keystore Java, à cause d’un vieux bug de ca-certificates-java. Le conseil de la page de l’incident est de le recréer en root :

rm -f /etc/ssl/certs/java/cacerts && update-ca-certificates --fresh

2. Corriger les bundles que la mise à jour système n’a jamais touchés

Plusieurs environnements d’exécution embarquent leur propre copie et ne voient pas votre mise à jour de ca-certificates.

Le module requests de Python lit le bundle certifi, pas le magasin du système. La version corrigée est certifi 2026.10.19, et pip lui-même est corrigé en 26.2.2 :

pip install --upgrade certifi pip

Node.js embarque son propre magasin de racines et ne lit pas celui du système par défaut. Les versions corrigées sont 26.12.1, 24.22.1 et 22.23.4 : un service Node de longue durée a besoin d’un Node plus récent, pas d’un ca-certificates plus récent. Go sous Linux lit le magasin du système, mais le projet a aussi publié des correctifs en 1.27.3 et 1.26.10, et les programmes Rust qui intègrent webpki-roots doivent être recompilés avec un crate corrigé.

Quand nous avons regardé, certbot et containerd figuraient encore comme en attente sur la page de l’incident. Revérifiez cette page avant de supposer que votre version est couverte.

Tout ce qui lit le magasin du système doit quand même être redémarré. Un service lancé avant la mise à jour garde l’ancien magasin en mémoire jusqu’à son redémarrage.

3. Retirer ou reconstruire vos images de conteneurs

Une image fige son bundle de CA au moment du build. Si elle a été construite avant que la distribution livre la suppression, elle fait confiance aux intermédiaires, quel que soit le niveau de correctifs de l’hôte.

docker pull debian:bookworm   # ou votre image de base
docker compose build --pull   # si vous construisez la vôtre

Le piège : un vieux tag n’est jamais reconstruit. Si votre Dockerfile dit encore node:20, golang:1.23 ou alpine:3.19, ces lignes sont arrivées en fin de vie, et un nouveau pull rend le même bundle périmé. Passez à un tag supporté. Pour les images que vous ne construisez pas, vérifiez que l’éditeur a publié un nouveau tag après le 20 octobre. Cette étape, la plupart des gens la sautent, et c’est elle qui protège les conteneurs.

4. Mettre à jour les applications Electron partout où vous développez

Les applications Electron ne reçoivent le correctif que lorsqu’elles sont reconstruites sur une version d’Electron corrigée (44.9.1, 43.8.1 et 42.11.16 sont les lignes corrigées). Mettre à jour l’OS ou le navigateur ne leur sert à rien. Slack, Discord et tout ce qui tourne sur ce runtime, sur votre poste comme sur les runners CI, ont besoin de leur propre mise à jour.

Les outils de développement d’Apple étaient un cas particulier : le git, le curl et le python3 livrés avec macOS faisaient encore confiance aux certificats compromis au 28 octobre, et macOS 27.2 a annulé les correctifs que certains avaient appliqués à la main. Sur un Mac, testez les outils directement avec les commandes curl ci-dessus plutôt que de vous fier à la version de l’OS.

5. Regarder les runners que votre CI utilise vraiment

Un runner hébergé, un agent auto-hébergé ou un conteneur de build est ici une cible de chaîne d’approvisionnement. Si un attaquant peut se faire passer pour le registre de paquets, ce que ce runner construit est à sa merci. Vérifiez que l’image du runner est à jour et que l’image de base épinglée de l’étape 3 a été rafraîchie. GitLab Runner 19.5.1 est la version corrigée si c’est votre runner.

Ce que cela ne touche pas

Ce sujet faisait le buzz à cause de la validation multi-perspective de Let’s Encrypt, où le contrôle d’un domaine est vérifié depuis plusieurs points du réseau pour qu’un détournement BGP sur un chemin ne trompe pas la CA et ne la pousse pas à émettre pour un domaine qu’elle ne devrait pas. C’est une vraie défense, et elle se situe au niveau de l’émission : elle protège le moment où un certificat est demandé.

Le problème eMudhra se situe au niveau de la confiance. Les clés d’une CA ont été compromises, ce qui n’a rien à voir avec la manière dont les domaines ont été validés, donc la validation multi-perspective ne l’aurait pas détecté. Les deux se confondent facilement. « Let’s Encrypt valide depuis plusieurs endroits » n’est pas une raison de sauter l’audit ci-dessus.

Pour votre propre pile ACME, cela tient en trois points. Vos certificats ne sont pas touchés et les renouvellements continuent. Vos clients sont le risque, et seule une mise à jour du magasin de confiance le corrige. Et Caddy ou Traefik qui terminent le TLS avec votre propre certificat, c’est très bien, alors que git, curl, docker et les environnements d’exécution du même serveur constituent la surface d’attaque.

Où faire tourner l’audit

La pile que vous vérifiez est très probablement un petit VPS ou un hôte de conteneurs, et les étapes ci-dessus supposent un shell dessus. Si vous choisissez encore la machine, nous avons testé la gamme économique et l’avons décrite dans la comparaison de VPS. La configuration ACME qui sert ce site, Caddy et Docker derrière un seul nom d’hôte, est dans le guide Caddy en production. Le cas de la machine ancienne, où certbot ne s’installe pas et où vous reprenez le renouvellement avec acme.sh, est celui que la plupart des auto-hébergeurs héritent tôt ou tard.