Tous les articles

Une CA a perdu la confiance du web. Votre app Node le sait-elle ?

Sécurité · 4 min de lecture ·

La semaine du 18 octobre 2026, une autorité de certification a perdu la confiance du web. D'après le tracker d'incidents pwn.watch, un chercheur a signalé que les clés privées de huit CA intermédiaires eMudhra Global TLS étaient cryptographiquement faibles et pouvaient être retrouvées ; Mozilla, Chrome, Apple et Microsoft ont bloqué ces intermédiaires, et eMudhra les a révoqués le 19 octobre. Le 22 octobre, l'entreprise a annoncé quitter le marché mondial des certificats SSL/TLS. Si vous écrivez du PHP ou du Node.js, votre navigateur a été protégé par son éditeur. Vos services backend, eux, ne l'ont été que si quelqu'un les a mis à jour.

Ce qui s'est passé, selon l'entreprise et selon le tracker

Le communiqué d'eMudhra indique que les CA concernées ont été révoquées "within 14 hours of discovery" et que l'incident a été divulgué rapidement. Ce chiffre est celui de l'entreprise. Le communiqué ajoute qu'aucun certificat final n'a été émis par ces CA, que son infrastructure n'a pas été compromise, qu'aucune donnée n'a fuité, et que le SSL/TLS mondial représente environ 1 % de son chiffre d'affaires. Ses racines G1 RSA continuent de servir les clients pendant la transition, les clients touchés reçoivent gratuitement des certificats de remplacement via des partenaires, et les services de révocation et de statut restent en ligne jusqu'à ce que chaque certificat émis ait expiré ou ait été remplacé.

Le tracker pwn.watch précise que la racine ECC a été retirée par précaution, et que les runtimes qui embarquent leur propre magasin de confiance, il cite notamment Go, Node.js, Electron, certifi pour Python et curl, ont eu besoin d'une mise à jour d'urgence de leur bundle de CA. La publication de sécurité d'octobre 2026 du projet Node.js confirme sa part : elle mentionne une mise à jour ca-cert pour la "eMudhra Intermediate CA Compromise" sur les branches 26.x, 24.x et 22.x.

CA racine de confiance signe CA intermédiaire clé faible signe Certificat final api.example Retirée ou révoquée : tout ce qui suit échoue
Un client fait confiance à un certificat final grâce à la chaîne au-dessus. Retirez l'intermédiaire et la chaîne s'arrête à la cassure.

La liste de votre navigateur n'est pas celle de votre serveur

Cette partie relève de la culture générale sur les clients TLS, pas d'un détail de l'incident. Un client TLS décide à qui faire confiance à partir d'une liste de certificats racines, son magasin de confiance. Navigateurs et systèmes d'exploitation livrent et mettent à jour le leur. Beaucoup de runtimes et de bibliothèques transportent plutôt leur propre copie : Node.js intègre la liste de Mozilla dans chaque version, et le code Python qui utilise certifi fait confiance au fichier de certifi. D'autres runtimes lisent le magasin du système sauf configuration contraire, alors vérifiez la documentation du vôtre au lieu de supposer.

Voilà pourquoi un retrait de confiance n'atteint pas tout le monde à la même vitesse. Chrome sur votre portable s'est mis à jour tout seul. Un service Node qui appelle une API de paiement depuis une image Docker construite en août transporte encore la liste d'août, et il continuera de faire confiance à un intermédiaire révoqué tant que le runtime ou le bundle dans cette image ne change pas.

Navigateur se met à jour Magasin de l'OS via l'OS Bundle runtime Node, certifi Image Docker figée au build Votre service Node qui appelle une API pas utilisé par les serveurs pointillés : dépend du runtime et du build de l'image
Quatre listes, quatre calendriers de mise à jour. Une app backend fait confiance à celle avec laquelle elle a été construite.

Que faire cette semaine

Mettez à jour le runtime de chaque service, puis reconstruisez et redéployez les images : une nouvelle version de Node.js sur votre portable ne change rien dans une image qui tourne déjà. Là où il y a du Python, mettez aussi certifi à jour.

node --version
docker build --pull --no-cache -t my-api .
pip install --upgrade certifi

Si un appel se met à échouer avec une erreur de certificat après la mise à jour, c'est la protection qui fonctionne. Ne définissez pas NODE_TLS_REJECT_UNAUTHORIZED=0 et ne passez pas rejectUnauthorized: false pour la faire disparaître : cela coupe la vérification pour toutes les connexions du processus, pas seulement pour celle qui casse. Identifiez le certificat présenté par l'autre côté et faites-le remplacer ; eMudhra indique que les clients touchés reçoivent un remplacement sans frais.

Notez d'où chaque service tire sa liste de CA, et faites de "mettre à jour le runtime et reconstruire l'image" une tâche mensuelle, pas une réponse à incident.

Prochaine étape : ouvrez le Dockerfile de votre plus vieux service en production, regardez la date de son image de base, et reconstruisez-le aujourd'hui. Ajoutez ensuite une surveillance de l'expiration des certificats et de Certificate Transparency pour vos propres domaines, afin que le prochain changement dans leur émission vous parvienne avant vos utilisateurs.

Source : communiqué de presse d'eMudhra, 22 octobre 2026, et les publications de sécurité Node.js d'octobre 2026.

Ce que disent les lecteurs

  1. Pas encore de mot. Le premier est toujours le plus courageux.
Vous construisez quelque chose du genre ? Je peux vous aider. Écrivez-moi sur WhatsApp