Ce qui s'est passé, avec les dates
Le 17 octobre 2026, un chercheur signale aux programmes racine que huit autorités intermédiaires eMudhra ont été créées avec des clés mal générées. Firefox et Chrome bloquent ces certificats le jour même. Le 20 octobre 2026, Microsoft commence à les bloquer et le bundle de curl passe à sa version du 20 octobre. Le 22 octobre 2026, Apple suit pour les applications qui passent par ses frameworks réseau.
Le 20 octobre 2026, Debian publie aussi l'avis DSA-6572-1 : le paquet ca-certificates en version 20250419+deb13u1, pour Debian stable (trixie), retire les certificats nommés « emSign ECC Root CA - G3 » et « Comodo AAA Services root ». Deux précisions comptent pour la suite. L'avis parle d'intermédiaires eMudhra compromis, mais les deux certificats qu'il nomme portent des noms de racines. Et il ne liste de version corrigée que pour trixie : pour les autres distributions, il faut lire l'avis de la distribution concernée, pas supposer.
Pourquoi « les navigateurs ont bloqué » ne clôt pas le dossier
C'est l'objection la plus courante, et elle est à moitié juste. Les navigateurs qui imposent la transparence des certificats (Certificate Transparency) ne pouvaient pas être attaqués par ces intermédiaires, selon la page de référence du chercheur. Mais un serveur qui appelle une API, un script de déploiement qui clone un dépôt, une tâche planifiée qui télécharge une archive ou un conteneur qui installe une dépendance ne sont pas des navigateurs. Ces clients vérifient la chaîne contre un fichier, et ne contrôlent généralement ni la transparence ni la révocation. Le 28 octobre 2026, la page de référence du chercheur indiquait par exemple que les outils en ligne de commande d'Apple (git, curl, python3) faisaient encore confiance à ces certificats.
Seconde objection : qui est responsable ? L'agence tient la relation avec le client. L'infrastructure, elle, se contrôle serveur par serveur, et personne d'autre ne le fera à votre place.
Où vit un magasin de confiance sur une machine
- Le paquet système —
ca-certificatessur Debian, Ubuntu et Alpine, le même nom sur RHEL et dérivées. C'est la référence de tout ce qui lit/etc/ssl/certs. - Le bundle de curl — selon la compilation, curl lit le magasin système ou un fichier à part.
curl-config --caindique lequel. - Python et certifi — le module
certifiembarque son propre bundle, et pip s'en sert. Une mise à jour du système ne le touche pas. - Node.js — le binaire embarque une liste d'autorités.
NODE_EXTRA_CA_CERTSen ajoute, il n'en retire aucune. - Java — le fichier
cacertsdu JDK est un magasin indépendant du reste. Le correctif OpenJDK était encore en attente sur la page de référence, et rien ne garantit que votre distribution y répercute la mise à jour du paquet système. - Chaque image de conteneur — elle a son propre
/etc/ssl/certs, figé à la date de sa construction. Le correctif de l'hôte ne la traverse pas.
Prérequis chiffrés de l'audit
Prévoyez un accès root ou sudo sur chaque machine, environ 15 minutes pour la première passe d'un serveur, puis 5 minutes en routine une fois les commandes mémorisées. Il y a cinq emplacements à inspecter par machine (paquet système, curl, certifi, Node, Java) et un de plus par image de conteneur. Gardez sous la main au moins deux hôtes de test dont vous connaissez la chaîne, par exemple www.votre-domaine.com et une API que vos applications appellent. Pour les services Java, prévoyez enfin une fenêtre de redémarrage : un magasin remplacé n'est relu qu'au démarrage de la JVM.
La procédure, serveur par serveur
Relever la version du paquet
dpkg -l ca-certificatessur Debian et Ubuntu,rpm -q ca-certificatessur RHEL et dérivées,apk info -v ca-certificatessur Alpine. Sur Debian stable (trixie), la version corrigée de l'avis DSA-6572-1 est 20250419+deb13u1 : si la vôtre est plus ancienne, passez à l'étape suivante.Mettre à jour le magasin
Sur Debian et Ubuntu :
apt updatepuisapt install --only-upgrade ca-certificates, puisupdate-ca-certificates. Sur RHEL et dérivées :dnf upgrade ca-certificatespuisupdate-ca-trust. Sur Alpine :apk upgrade ca-certificates.Vérifier que les certificats retirés ont disparu
ls /usr/share/ca-certificates/mozilla | grep -i -E 'emSign_ECC_Root_CA_-_G3|Comodo_AAA'ls /etc/ssl/certs | grep -i -E 'emSign_ECC_Root_CA_-_G3|Comodo_AAA'
Le motif cible uniquement les deux certificats nommés par l'avis Debian, car d'autres racines emSign ou Comodo valides restent légitimement présentes. Après la mise à jour, aucune ligne ne doit sortir. Une ligne signale un magasin resté à l'ancienne version, ou un répertoire alimenté à la main. Vérifiez les noms de fichier réels sur une machine à jour.Tester une chaîne depuis le serveur
openssl s_client -connect www.votre-domaine.com:443 -showcertsaffiche chaque certificat envoyé et se termine par la ligneVerify return code. Le code 0 signifie que la chaîne est acceptée par le magasin local. Complétez aveccurl -v https://www.votre-domaine.comet lisez la ligneSSL certificate verify ok.Inventorier les bundles hors du magasin système
curl-config --cadonne le chemin du bundle de curl.python3 -c "import certifi; print(certifi.where())"donne celui de Python.echo $NODE_EXTRA_CA_CERTSmontre les ajouts éventuels de Node.readlink -f $(which java)remonte au JDK, dontlib/security/cacertsest le magasin.Mettre à jour certifi
pip show certifidonne la version installée,python3 -m pip install --upgrade certifila met à jour. La page de référence du chercheur liste certifi 2026.10.19 parmi les versions corrigées. Refaites l'opération dans chaque environnement virtuel, car chacun a sa copie.Contrôler le magasin Java
keytool -list -keystore $JAVA_HOME/lib/security/cacerts -storepass changeit | grep -i -E 'emsign ecc|aaa'cherche les entrées concernées ; les alias varient selon le JDK, comparez donc avec la liste de la page de référence. Le correctif OpenJDK était encore en attente à la date de cette page : si une entrée concernée est présente, notez la machine comme « en attente amont » plutôt que « corrigée ».Consigner le résultat dans votre audit mensuel
Une ligne par serveur : date, version de ca-certificates, chemins des bundles, résultat du test de chaîne. Cette trace est ce que vous montrez au client quand il demande ce qui a été vérifié, et elle s'insère dans la checklist d'audit mensuel de vos VPS clients.
Où chercher, composant par composant
Faites défiler le tableau
| Composant | Où vit la liste de confiance | Commande de contrôle |
|---|---|---|
| Système Debian, Ubuntu | Paquet ca-certificates, répertoire /etc/ssl/certs | `dpkg -l ca-certificates` |
| Système RHEL et dérivées | Paquet ca-certificates, magasin géré par update-ca-trust | `rpm -q ca-certificates` |
| curl | Magasin système ou bundle de compilation | `curl-config --ca` |
| Python, pip | Module certifi, indépendant du système | `python3 -c "import certifi; print(certifi.where())"` |
| Node.js | Liste intégrée au binaire, plus NODE_EXTRA_CA_CERTS | `echo $NODE_EXTRA_CA_CERTS` |
| Java | Fichier cacerts du JDK | `keytool -list -keystore $JAVA_HOME/lib/security/cacerts -storepass changeit` |
| Conteneur Docker | /etc/ssl/certs propre à chaque image | `docker run --rm IMAGE ls /etc/ssl/certs` |
Les conteneurs : le correctif de l'hôte ne passe pas
Un conteneur n'hérite pas du magasin de son hôte. Il embarque celui de son image de base, figé le jour de la construction. Mettre à jour ca-certificates sur le serveur ne change donc rien pour vos conteneurs. Pour inspecter une image, lancez docker run --rm IMAGE ls /etc/ssl/certs, ou docker run --rm IMAGE dpkg -l ca-certificates si l'image est basée sur Debian ou Ubuntu.
Le remède est la reconstruction : docker build --pull --no-cache -t mon-application:2026-10 . tire la dernière image de base et refait la couche des certificats. Sans --pull, Docker réutilise la base en cache, et vous reconstruisez le même défaut. Redéployez ensuite, puis relancez le contrôle sur le conteneur en marche. Pensez aux images tierces (base de données, proxy, outil de supervision) que vous ne construisez pas : leur éditeur doit publier une nouvelle version, et il faut le vérifier.
Si un certificat client chaîne sur ces autorités
Il y a deux cas, et il faut les séparer. Le premier : un certificat émis pour votre client, ou pour vous, a été signé par l'un des intermédiaires concernés. Lisez l'émetteur avec openssl x509 -in certificat.pem -noout -subject -issuer -dates, puis la chaîne servie avec openssl s_client -connect www.votre-domaine.com:443 -showcerts. La page de référence publie la liste des intermédiaires touchés (fichier impacted-intermediates.json) : comparez-la à ce que vous lisez. Si l'émetteur y figure, demandez à l'autorité émettrice une réémission sous une autre chaîne, sans attendre l'expiration.
Le second cas : un partenaire se connecte chez vous par certificat client (mTLS) et votre serveur l'accepte parce que son magasin contient une autorité concernée. Après mise à jour, ce partenaire peut être refusé, ce qui est le comportement voulu mais doit être annoncé. Prévenez-le avant, listez les certificats clients actifs, et gardez une trace de la date de remplacement.
Testez avant et après, sur des hôtes réels
Retirer une racine peut casser des chaînes légitimes qui s'y rattachent. Avant la mise à jour, lancez curl -sS -o /dev/null -w '%{http_code}\n' https://www.votre-domaine.com sur trois ou quatre hôtes que vos applications appellent vraiment, puis relancez la même commande après. Un changement de code ou une erreur de vérification se règle tout de suite, sur un serveur, plutôt qu'en production un lundi matin.
Dépannage : les erreurs que vous allez voir
Après la mise à jour, quatre messages reviennent. curl: (60) SSL certificate problem: unable to get local issuer certificate : le serveur distant envoie une chaîne incomplète, ou sa chaîne passait par un certificat désormais retiré. Testez avec openssl s_client -showcerts, puis demandez au propriétaire du service de corriger sa chaîne.
ssl.SSLCertVerificationError: CERTIFICATE_VERIFY_FAILED côté Python : l'interpréteur utilise le magasin de certifi ou celui du système, selon l'application. Relevez le chemin avec certifi.where() et mettez à jour le bon composant.
PKIX path building failed: unable to find valid certification path to requested target côté Java : le fichier cacerts ne contient pas l'autorité attendue ou a été remplacé. Vérifiez avec keytool, puis redémarrez la JVM.
Verify return code: 20 (unable to get local issuer certificate) dans openssl s_client : l'autorité n'est plus dans /etc/ssl/certs. Si le site est légitime, c'est un signal à traiter côté serveur distant, pas à contourner en désactivant la vérification.
Ce qui reste en attente, et qui porte quoi
À la date de la page de référence, mise à jour le 28 octobre 2026, le noyau NSS était corrigé en version 3.131.1 et le bundle de curl l'était depuis le 20 octobre 2026, mais le correctif OpenJDK restait en attente, et les outils en ligne de commande d'Apple continuaient de faire confiance aux certificats. Relisez cette page avant de dire à un client que tout est corrigé : l'état change, et votre rapport doit indiquer la date de la vérification.
Pour une agence, le partage est simple. Vous gardez la relation avec le client et le rapport qui lui prouve ce qui a été contrôlé. Le contrôle lui-même se fait machine par machine. Si vous gérez vos propres serveurs, le rapport est le même, sans le client : une ligne par machine, avec la date.
