[{"data":1,"prerenderedAt":189},["ShallowReactive",2],{"seo-verification":3,"blog-emudhra-ca-intermediaires-compromises-magasin-confiance-verifier-fr":6},{"google":4,"bing":5},"EycwPY2XMyTkVzas3n1ygeNJFGAH513qrMjfDljzsMQ","",{"key":7,"data":8},"blog-emudhra-ca-intermediaires-compromises-magasin-confiance-verifier-fr",{"id":9,"slug":10,"slugs":11,"title":15,"excerpt":16,"readTime":17,"views":18,"isPinned":19,"publishedAt":20,"updatedAt":21,"category":22,"categories":28,"featuredImage":30,"bgImage":31,"posterImage":32,"relatedSolution":30,"intro":33,"sections":34,"ctaTitle":135,"ctaBody":136,"ctaButton":137,"ctaUrl":138,"relatedPosts":139},551,"emudhra-ca-intermediaires-compromises-magasin-confiance-verifier",{"fr":10,"en":12,"ar":13,"es":14},"emudhra-check-the-trust-store-on-your-servers","emudhra-تحقق-من-مخزن-الثقة-في-خوادمك","emudhra-verificar-el-almacen-de-confianza-de-sus-servidores","eMudhra : vérifier le magasin de confiance de vos serveurs","Huit CA intermédiaires eMudhra compromises : auditez ca-certificates, curl, Python, Node, Java et conteneurs par commandes, et voyez ce qui attend un correctif.",9,0,false,"2026-10-31T00:00:00+00:00","2026-10-31T19:07:30+00:00",{"id":23,"name":24,"slug":25,"color":26,"icon":27},8,"Sécurité & Monitoring","securite-monitoring","bg-rose-500\u002F10 text-rose-400","security",[29],{"id":23,"name":24,"slug":25,"color":26,"icon":27},null,"\u002Fblog\u002Fcovers\u002Fbg.svg","\u002Fblog\u002Fcovers\u002Femudhra-ca-intermediaires-compromises-magasin-confiance-verifier-poster.svg","En octobre 2026, huit autorités intermédiaires eMudhra ont été bloquées par les navigateurs, mais un serveur n'est pas un navigateur : curl, git, Python, Node, Java et vos conteneurs portent chacun leur propre liste d'autorités de confiance. Que vous gériez un parc de machines clients ou vos propres serveurs, la question n'est plus « le navigateur protège-t-il l'utilisateur ? », mais « quelle machine fait encore confiance à ces certificats, et à quel endroit exact ? ». Ce guide donne l'audit complet, commande par commande, et dit honnêtement ce qui attendait encore un correctif amont à la date de sa rédaction.",[35,39,42,52,55,83,119,122,125,129,132],{"type":36,"title":37,"body":38},"h2","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.\n\nLe 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.",{"type":36,"title":40,"body":41},"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.\n\nSeconde 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.",{"type":43,"title":44,"items":45},"ul","Où vit un magasin de confiance sur une machine",[46,47,48,49,50,51],"**Le paquet système** — `ca-certificates` sur 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 `\u002Fetc\u002Fssl\u002Fcerts`.","**Le bundle de curl** — selon la compilation, curl lit le magasin système ou un fichier à part. `curl-config --ca` indique lequel.","**Python et certifi** — le module `certifi` embarque 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_CERTS` en ajoute, il n'en retire aucune.","**Java** — le fichier `cacerts` du 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 `\u002Fetc\u002Fssl\u002Fcerts`, figé à la date de sa construction. Le correctif de l'hôte ne la traverse pas.",{"type":36,"title":53,"body":54},"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.",{"type":56,"title":57,"steps":58},"steps","La procédure, serveur par serveur",[59,62,65,68,71,74,77,80],{"title":60,"body":61},"Relever la version du paquet","`dpkg -l ca-certificates` sur Debian et Ubuntu, `rpm -q ca-certificates` sur RHEL et dérivées, `apk info -v ca-certificates` sur 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.",{"title":63,"body":64},"Mettre à jour le magasin","Sur Debian et Ubuntu : `apt update` puis `apt install --only-upgrade ca-certificates`, puis `update-ca-certificates`. Sur RHEL et dérivées : `dnf upgrade ca-certificates` puis `update-ca-trust`. Sur Alpine : `apk upgrade ca-certificates`.",{"title":66,"body":67},"Vérifier que les certificats retirés ont disparu","`ls \u002Fusr\u002Fshare\u002Fca-certificates\u002Fmozilla | grep -i -E 'emSign_ECC_Root_CA_-_G3|Comodo_AAA'`\n`ls \u002Fetc\u002Fssl\u002Fcerts | grep -i -E 'emSign_ECC_Root_CA_-_G3|Comodo_AAA'`\nLe 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.",{"title":69,"body":70},"Tester une chaîne depuis le serveur","`openssl s_client -connect www.votre-domaine.com:443 -showcerts` affiche chaque certificat envoyé et se termine par la ligne `Verify return code`. Le code 0 signifie que la chaîne est acceptée par le magasin local. Complétez avec `curl -v https:\u002F\u002Fwww.votre-domaine.com` et lisez la ligne `SSL certificate verify ok`.",{"title":72,"body":73},"Inventorier les bundles hors du magasin système","`curl-config --ca` donne le chemin du bundle de curl.\n`python3 -c \"import certifi; print(certifi.where())\"` donne celui de Python.\n`echo $NODE_EXTRA_CA_CERTS` montre les ajouts éventuels de Node.\n`readlink -f $(which java)` remonte au JDK, dont `lib\u002Fsecurity\u002Fcacerts` est le magasin.",{"title":75,"body":76},"Mettre à jour certifi","`pip show certifi` donne la version installée, `python3 -m pip install --upgrade certifi` la 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.",{"title":78,"body":79},"Contrôler le magasin Java","`keytool -list -keystore $JAVA_HOME\u002Flib\u002Fsecurity\u002Fcacerts -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 ».",{"title":81,"body":82},"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.",{"type":84,"title":85,"headers":86,"rows":90},"comparison","Où chercher, composant par composant",[87,88,89],"Composant","Où vit la liste de confiance","Commande de contrôle",[91,95,99,103,107,111,115],[92,93,94],"Système Debian, Ubuntu","Paquet ca-certificates, répertoire \u002Fetc\u002Fssl\u002Fcerts","`dpkg -l ca-certificates`",[96,97,98],"Système RHEL et dérivées","Paquet ca-certificates, magasin géré par update-ca-trust","`rpm -q ca-certificates`",[100,101,102],"curl","Magasin système ou bundle de compilation","`curl-config --ca`",[104,105,106],"Python, pip","Module certifi, indépendant du système","`python3 -c \"import certifi; print(certifi.where())\"`",[108,109,110],"Node.js","Liste intégrée au binaire, plus NODE_EXTRA_CA_CERTS","`echo $NODE_EXTRA_CA_CERTS`",[112,113,114],"Java","Fichier cacerts du JDK","`keytool -list -keystore $JAVA_HOME\u002Flib\u002Fsecurity\u002Fcacerts -storepass changeit`",[116,117,118],"Conteneur Docker","\u002Fetc\u002Fssl\u002Fcerts propre à chaque image","`docker run --rm IMAGE ls \u002Fetc\u002Fssl\u002Fcerts`",{"type":36,"title":120,"body":121},"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 \u002Fetc\u002Fssl\u002Fcerts`, ou `docker run --rm IMAGE dpkg -l ca-certificates` si l'image est basée sur Debian ou Ubuntu.\n\nLe 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.",{"type":36,"title":123,"body":124},"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.\n\nLe 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.",{"type":126,"title":127,"body":128},"tip","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 \u002Fdev\u002Fnull -w '%{http_code}\\n' https:\u002F\u002Fwww.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.",{"type":36,"title":130,"body":131},"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.\n\n`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.\n\n`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.\n\n`Verify return code: 20 (unable to get local issuer certificate)` dans `openssl s_client` : l'autorité n'est plus dans `\u002Fetc\u002Fssl\u002Fcerts`. Si le site est légitime, c'est un signal à traiter côté serveur distant, pas à contourner en désactivant la vérification.",{"type":36,"title":133,"body":134},"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.\n\nPour 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.","Les serveurs d'un client, réunis au même endroit","Avec ServOrbit.com, les hébergements, les VPS et les domaines d'un client se retrouvent au même endroit, ce qui simplifie le suivi de ce que vous gérez.","Voir l'approche sécurité","\u002Fpourquoi\u002Fsecurite",[140,156,173],{"id":141,"slug":142,"slugs":143,"title":147,"excerpt":148,"readTime":149,"views":18,"isPinned":19,"publishedAt":150,"updatedAt":151,"category":152,"categories":153,"featuredImage":30,"bgImage":31,"posterImage":155,"relatedSolution":30},521,"checklist-audit-securite-mensuel-vps-clients-agence",{"fr":142,"en":144,"ar":145,"es":146},"monthly-security-audit-checklist-client-vps-agency","قائمة-تدقيق-أمان-vps-شهرية-للعملاء-للوكالات","auditoria-seguridad-mensual-vps-clientes-agencia-checklist","Audit sécurité mensuel d'un VPS client : checklist en 45 min","Sept contrôles à dérouler chaque mois sur un VPS client : mises à jour, noyau, comptes SSH, ports, certificats, sauvegardes, journaux. Rapport daté inclus.",10,"2026-10-28T00:00:00+00:00","2026-10-29T03:10:22+00:00",{"id":23,"name":24,"slug":25,"color":26,"icon":27},[154],{"id":23,"name":24,"slug":25,"color":26,"icon":27},"\u002Fblog\u002Fcovers\u002Fchecklist-audit-securite-mensuel-vps-clients-agence-poster.svg",{"id":157,"slug":158,"slugs":159,"title":163,"excerpt":164,"readTime":165,"views":166,"isPinned":19,"publishedAt":167,"updatedAt":168,"category":169,"categories":170,"featuredImage":30,"bgImage":31,"posterImage":172,"relatedSolution":30},317,"linux-hardening-vps-checklist",{"fr":158,"en":160,"ar":161,"es":162},"linux-vps-hardening-checklist-for-agencies","قائمة-تصليب-خادم-لينكس-للوكالات-بعد-التسليم","hardening-linux-vps-checklist-para-agencias-tras-la-entrega","Durcissement Linux VPS : checklist agence après livraison","Checklist de durcissement Linux pour agences : auditd, sudo, SSH par clé, UFW, fail2ban et désactivation root — traçabilité et runbook par client.",11,2,"2026-08-30T00:00:00+00:00","2026-09-07T11:26:10+00:00",{"id":23,"name":24,"slug":25,"color":26,"icon":27},[171],{"id":23,"name":24,"slug":25,"color":26,"icon":27},"\u002Fblog\u002Fcovers\u002Flinux-hardening-vps-checklist-poster.svg",{"id":174,"slug":175,"slugs":176,"title":180,"excerpt":181,"readTime":182,"views":166,"isPinned":19,"publishedAt":183,"updatedAt":184,"category":185,"categories":186,"featuredImage":30,"bgImage":31,"posterImage":188,"relatedSolution":30},492,"nginx-cve-2026-15176-mettre-a-jour",{"fr":175,"en":177,"ar":178,"es":179},"nginx-cve-2026-15176-audit-and-patch-to-1-30-6","ثغرة-nginx-cve-2026-15176-الفحص-والتحديث-إلى-1-30-6","nginx-cve-2026-15176-auditar-y-actualizar-a-1-30-6","nginx CVE-2026-15176 : auditer et patcher vers 1.30.6","nginx 1.30.6 et 1.31.7 corrigent cinq failles, dont CVE-2026-15176. Versions touchées, commandes d'audit de la conf, mise à jour par système et parades.",12,"2026-10-22T00:00:00+00:00","2026-10-23T13:27:02+00:00",{"id":23,"name":24,"slug":25,"color":26,"icon":27},[187],{"id":23,"name":24,"slug":25,"color":26,"icon":27},"\u002Fblog\u002Fcovers\u002Fnginx-cve-2026-15176-mettre-a-jour-poster.svg",1793480207043]