Sources vérifiées le 22 octobre 2026, heure de Pékin. Audience : utilisateurs individuels, opérateurs de sites Web, développeurs et administrateurs système.
De graves faiblesses ont rendu récupérable un groupe de clés privées intermédiaires eMudhra/emSign CA. Cela affecte les clients qui utilisent le système de certificat public pour authentifier les sites Web, les API et les logiciels. La confiance du public s’étend aux principaux systèmes d’exploitation, mais l’ensemble des clés compromises et l’impact potentiel sur les clients ont des portées différentes. 15
Le texte principal utilise des crochets pour numéroter les sources correspondantes, et tous les liens de référence externes sont répertoriés en annexe. La version répertoriée est la version de référence confirmée comme contenant le correctif pour cet incident à la date de vérification. Lors du déploiement, la priorité est donnée à la version stable mise à jour dans la même branche supportée.
TL;DR
Huit clés privées intermédiaires CA sont confirmées compromises. Les rapports actuels n’établissent pas que les clés privées racine ou la cryptographie HTTPS en général aient été brisées. Les mises à jour couvrent une grande partie de l’écosystème de confiance du public ; le risque résiduel dépend de l’application réelle.15
- Utilisateurs individuels : met à jour les navigateurs, les systèmes d’exploitation et les composants de sécurité. Sur Android, mettez également à jour les services Google Play. Utilisez Firefox Android 158.0.2 ou une version ultérieure. 12
- Serveurs : met à jour les packages
ca-certificates/NSS de la distribution et vérifie les magasins de confiance intégrés aux applications. La mise à jour uniquement de l’hôte est insuffisante. 7810 - Environnements de développement : met à jour Node 24 vers 24.22.1 ou une version plus récente dans cette branche, le cas échéant. Dans les environnements Python, effectuez la mise à jour vers au moins pip 26.2.2, certifi 2026.10.19 et uv 0.13.4. Obtenez les binaires Go corrigés ou reconstruisez-les ; mettez à jour Java conformément aux conseils de son fournisseur. 12–15
- Activez les mises à jour : redémarrez les services concernés et reconstruisez et redéployez les conteneurs. Pour Cloudflare Tunnel, mettez à jour cloudflared vers 2026.10.2 ou version ultérieure. 7
- Certificats de site Web : remplace une chaîne affectée si elle contient un CA intermédiaire révoqué ou bloqué, ou s’appuie sur une racine non fiable. La réémission d’un certificat ne remplace pas la mise à jour des magasins de confiance client. 158
- Vérification : teste le chemin TLS réel de chaque application. Distinguez le rejet de certificat des délais d’attente et des échecs DNS. Gardez la vérification du certificat activée ; n’utilisez pas
-ket n’ignorez pas la vérification pour supprimer les erreurs. 7
1 Faits et causes de l’incident
faits confirmés
Mozilla et Google ont confirmé des défauts dans huit clés privées intermédiaires eMudhra CA. Le chercheur a fourni la preuve du contrôle de la clé privée ; Mozilla a récupéré les clés de manière indépendante et a reproduit le problème. Six autorités de certification intermédiaires servent TLS et deux servent la signature de code. 25
Le défaut réside dans les clés générées : ces AC intermédiaires utilisent la courbe P-384, mais leurs clés privées sont des entiers inférieurs à 256. On est loin de sélectionner de manière sécurisée des clés au hasard dans la large plage prévue. La récupération de ces clés faibles ne démontre pas que les clés P-384 correctement générées peuvent être cassées. 2
Le « certificat est craqué » doit ici être compris avec précision comme « la clé privée correspondante peut être récupérée ». Le certificat et la clé publique qu’il contient sont intrinsèquement publics ; ce qui doit vraiment rester secret, c’est la clé privée qui peut générer une signature valide.
Les problèmes liés au processus de génération de clés sont toujours à l’étude
Une première description de eMudhra fait remonter le problème à une cérémonie de génération de clé en avril 2025. L’explication implique une étape d’encapsulation et de décapsulation de clé : en plus de la clé forte d’origine, un autre ensemble de clés faibles apparaît, et les clés faibles sont ensuite utilisées pour la demande et l’émission du certificat. La société a toujours déclaré que la cause exacte n’avait pas été déterminée de manière concluante. 6
Par conséquent, ce qui peut être déterminé, c’est que ces clés sont très faibles et ont été compromises ; l’échec ne peut pas être décrit davantage comme une certaine source matérielle de nombres aléatoires de HSM s’est avérée défectueuse, ni comme une percée cryptographique générale de RSA, ECC ou TLS.
Que signifie la méfiance envers le certificat racine ?
Le navigateur ou le système d’exploitation peut bloquer directement le certificat ou la clé publique du CA intermédiaire concerné, ou il peut supprimer la confiance racine qui y mène. Cette dernière mesure rejettera également certains certificats légitimes sous la même racine.
Google a programmé la suppression de emSign ECC Root CA - G3 pour protéger les utilisateurs du magasin racine Chrome qui ne reçoivent pas de mises à jour de CRLSet. La suppression du magasin racine devrait être repoussée au cours de la période correspondante du 27 au 28 octobre, heure de Pékin ; l’heure d’origine de Google est le matin du 27 octobre, heure avancée du Pacifique des États-Unis. Ce plan est distinct du blocage d’urgence par clé publique qui a été déployé précédemment. 1
La méfiance envers une racine est une mesure de réponse ; cela ne prouve pas en soi que la clé privée racine a été compromise.
2 Pourquoi l’impact potentiel s’étend à l’écosystème de la confiance du public
Clés compromises et chemins de confiance affectés
| Objet de jugement | L’ampleur de cet incident |
|---|---|
| Clé problématique identifiée | 8 clés privées intermédiaires CA pour eMudhra |
| Plateformes pouvant nécessiter une action | Magasin racine public, navigateur, système d’exploitation, environnement d’exécution du langage, progiciel et écosystème de conteneurs |
| Identité peut-être usurpée TLS | Sites Web ou services visités par des clients qui acceptent toujours la fausse chaîne de certificats associée |
| Cela signifie-t-il que tous les appareils ont été compromis ? | Non ; les conditions de confiance, l’emplacement du réseau de l’attaquant et d’autres stratégies de vérification déterminent l’exploitabilité |
| Cela signifie-t-il que tous les certificats légaux sont invalides ? | Non ; l’invalidation associée dépend des racines ou des chaînes de certificats auxquelles le client n’a pas confiance. |
Red Hat limite explicitement l’exploitation aux conditions dans lesquelles le client accepte toujours la chaîne concernée, l’attaquant possède la clé privée compromise et est capable d’intercepter la connexion au réseau. La couverture des risques ne doit pas être confondue avec le nombre d’attaques survenues. 10
Les sites Web utilisant d’autres CA peuvent également être usurpés.
Supposons qu’un site Web utilise réellement le certificat Let’s Encrypt et que le client du visiteur fasse confiance à plusieurs CA publics en même temps. Un attaquant pourrait tenter d’utiliser l’intermédiaire compromis CA pour créer un autre certificat pour le même nom de domaine. Les clients n’exigent généralement pas à l’avance que le nom de domaine puisse utiliser uniquement Let’s Encrypt ; si la fausse chaîne est toujours acceptée, le CA utilisé réellement par le site Web ne suffit pas à exclure de telles attaques. 8
Ce mécanisme explique : Le remplacement d’un autre certificat CA qui était initialement normal ne rétablira pas automatiquement la confiance du client dans le CA compromis. Ce qu’il faut vraiment supprimer, c’est la possibilité pour les clients d’accepter de fausses identités.
Les trois effets doivent être traités séparément
Risque d’usurpation d’identité : Les clients qui n’ont pas bloqué la chaîne concernée peuvent accepter l’identité forgée par l’attaquant, provoquant l’envoi de requêtes sensibles à de faux services.
Risque légitime de disponibilité du service : la suppression de l’approbation racine peut provoquer des erreurs de certificat pour des sites Web par ailleurs légitimes, qui peuvent nécessiter une migration vers une autre chaîne acceptée.
Risque de couverture de déploiement : le système d’exploitation peut être corrigé tandis qu’un magasin de confiance intégré à une application, un environnement virtuel, une ancienne image de conteneur ou un programme compilé conserve l’ancien comportement de validation.
Ces trois périmètres ne sont pas identiques. La réponse de Cloudflare couvre la validation d’identité à distance, les magasins de confiance partagés, les images de base et les applications individuelles, illustrant pourquoi ces deux dernières tâches doivent être traitées séparément. 7
3 CA et fournisseurs de certificats concernés
Fournisseur et type d’impact
| fournisseur ou système | Rôle dans cet incident | Des limites à distinguer |
|---|---|---|
| eMudhra／emSign | La clé privée intermédiaire CA est directement compromise. | Vous ne pouvez pas écrire toutes les racines eMudhra et tous les certificats comme piratés |
| Chaîne de signatures croisées associée à Sectigo | Une certification croisée A a été émise pour le même lot de clés publiques concernées, formant ainsi un autre chemin de confiance. | La certification croisée ou la clé publique correspondante doit être bloquée ; Il n’a pas été prouvé que la clé privée racine Sectigo était compromise. |
| Niveaux de certificat pertinents pour Internet2/InCommon | Certains certificats légitimes nécessitent la suppression de la racine emSign ECC, ce qui implique une migration | C’est un impact collatéral de la méfiance des racines et ne peut pas être compté comme le milieu de ces 8 clés faibles CA. |
| Let’s Encrypt, DigiCert, Google Trust Services, GlobalSign, etc. | Non répertorié comme partie dont la clé privée a été compromise dans ce rapport | Les certificats légitimes ne sont pas uniformément invalidés ; les clients vulnérables peuvent toujours accepter de faux certificats usurpant l’identité des sites Web qu’ils desservent |
| CDN, plateforme cloud, revendeur de certificats | Éventuellement fournir les certificats pertinents ou utiliser un magasin de confiance public lors de la connexion à l’origine et à API | Pour vérifier la chaîne de certificats et le validateur, ne vous contentez pas de regarder le nom de la plateforme ou du produit. |
Mozilla L’avis de documente les clés compromises et Sectigo signatures croisées. Google La discussion publique sur l’incident porte sur la migration des Internet2 / InCommon hiérarchies. 2 5 Cloudflare Les correctifs d’adressent le service et la confiance des clients ; ils n’indiquent pas un compromis de Cloudflare le propre CA clés privées. 7
Chaîne de certificats TLS et signature croisée
La relation suivante décrit cette fois uniquement les chemins associés à TLS. Cela n’inclut pas les chemins de signature de code et cela ne signifie pas non plus que ces chemins sont toujours fiables sur toutes les plateformes. 17
emSign ECC Root CA - G3→emSign Root TLS CA - G3→ Clé publique TLS intermédiaire CA concernée → Certificat falsifié pour le domaine cibleAAA Certificate Services→ Clé publique TLS intermédiaire CA concernée → Certificat falsifié pour le domaine cible
emSign Root TLS CA - G3 est l’un des émetteurs directs des intermédiaires TLS concernés et peut lui-même constituer un point d’ancrage de confiance dans certains magasins. emSign ECC Root CA - G3 fournit une autre couche de signature croisée. Le AAA Certificate Services de Sectigo crée un chemin supplémentaire vers les mêmes clés publiques intermédiaires CA. 17
Il existe donc deux granularités différentes lors de la réparation :
- Bloquez le CA intermédiaire exact ou la clé publique :, cela peut préserver d’autres hiérarchies légitimes sous la même racine, où le validateur prend en charge ce mécanisme.
- Supprimez la confiance racine :, cela peut protéger les clients sans capacités de blocage intermédiaires CA, mais peut affecter la compatibilité. Tous les autres chemins acceptés par le client doivent également être couverts. 5
« Supprimer toutes les racines Sectigo/eMudhra » ne doit pas être considéré comme une étape générale aveugle, et la simple suppression d’un certificat portant un nom similaire ne doit pas non plus signifier que tous les chemins sont fermés.
4 Couverture du système d’exploitation et du navigateur
Plateforme principale
| Plateforme | Disposition connue | Portée à vérifier lors de l’utilisation |
|---|---|---|
| Windows et Windows Server | Distribution Microsoft bloquée via la mise à jour automatique de la liste de confiance des certificats | Si l’appareil a reçu la mise à jour ; le CA bundle autonome n’utilise pas nécessairement le chemin de vérification de Windows |
| Plate-forme macOS, iOS, iPadOS, etc. Apple | Le coordinateur de l’incident a confirmé que Apple a déployé le blocus correspondant. | Il n’est pas garanti que chaque ancienne version et application tierce bénéficie de la même couverture |
| Android | Google distribue des blocs équivalents via le service Google Play | ROM sans le service Google Play doit être vérifié conformément à l’annonce du fabricant ; utilisez le vérificateur intégré pour une vérification supplémentaire |
| Ubuntu | Des correctifs pour l’ensemble de certificats système ont été fournis, y compris plusieurs branches de versions actuelles et anciennes. | L’ancienne version de ESM prend en charge les conditions, le package de certificat interne du conteneur et la bibliothèque intégrée à l’application. |
| Debian et Devuan | Debian enregistré ca-certificates corrigé | Vous devez vérifier la branche réelle utilisée et le package installé, et vous ne pouvez pas copier le numéro de version d’une autre branche. |
| RHEL et dérivés | La liste officielle est RHEL 6, 7, 8, 9, 10 et couvre les produits et images associés qui peuvent être concernés. | À l’heure de cette vérification, l’annonce n’a pas encore répertorié une liste complète des correctifs et des errata ; “Mise à jour introuvable” ne peut pas être considéré comme non affecté |
| Fedora, Arch, Gentoo, Alpine, etc. | Le responsable de l’événement a compilé les dossiers de réparation correspondants | Confirmé indépendamment par la version, la branche de version et l’image |
| FreeBSD | Répertorie officiellement toutes les versions prises en charge et fournit des réparations du magasin de confiance du système | Après la mise à jour, redémarrez le processus démon concerné conformément à l’annonce ; vérifiez séparément le magasin de confiance des applications indépendant. |
Pour un résumé de Windows, Apple et des versions, voir 4 ; pour Android, voir 1 ; pour Ubuntu, Debian, RHEL et FreeBSD, les enregistrements de l’émetteur sont présentés respectivement dans 8 – 11.
Les systèmes qui ne sont plus pris en charge, les appareils hors ligne, les NAS, les routeurs et autres environnements intégrés doivent confirmer s’ils font toujours confiance à la chaîne concernée et s’ils disposent de canaux pour recevoir des révocations ou des mises à jour logicielles. Le nom de la plateforme lui-même ne remplace pas la vérification du comportement réel de vérification.
La protection du navigateur est différente de la protection du système d’exploitation
Chrome utilise CRLSet pour distribuer les blocs d’urgence ; Firefox utilise des mécanismes tels que OneCRL. Firefox a également été publié avec des informations de blocage pour fournir une protection supplémentaire aux configurations qui ne reçoivent pas correctement les paramètres distants. 13
Certaines configurations de Firefox Android n’avaient pas correctement appliqué la liste mise à jour au démarrage, ce que Mozilla a déclaré être corrigé par 158.0.2.. Par conséquent, le statut des premiers 158.0.1 ne peut pas être étendu pour inclure toutes les configurations Android Firefox protégées. 2
Des mesures ont été prises pour la vérification du système de Apple et Windows, mais cela ne signifie pas que tous les programmes en ligne de commande sur la même machine seront soumis à une vérification du système. Le responsable de l’événement a spécifiquement rappelé que certains outils intégrés de macOS utilisent des fichiers de certificat indépendants ; le backend TLS réel et la source CA doivent être enregistrés lors de la vérification. 4
Limites de protection pour la transparence des certificats
Google a confirmé qu’avant de mettre en œuvre le blocage, les six intermédiaires TLS CA n’avaient pas délivré le certificat TLS qui était entré dans le journal CT. Par conséquent, les clients Chrome qui appliquent CT bénéficient d’une protection supplémentaire. Ce fait n’exclut pas la possibilité que d’autres clients n’exécutant pas CT aient accepté des certificats non documentés. 15
« Il s’avère qu’il peut être lié à la racine de confiance », « des conditions d’exploitation potentielles existent » et « une attaque a eu lieu » sont trois jugements différents et ne doivent pas être remplacés les uns par les autres.
5 Environnement de développement et référence de réparation du runtime
Ce qui suit est une base de correctifs confirmés et ne constitue pas une obligation pour épingler ces versions à long terme. Les distributions peuvent corriger les anciens numéros de version en rétrogradant les correctifs, et leurs avis de sécurité doivent également être examinés.
| composants | Version confirmée ou méthode de mise à jour | Considérations sur le déploiement |
|---|---|---|
| Node.js 24 | 24.22.1 ou mettre à jour la version stable de la même branche | Contient les mises à jour du référentiel racine et le rejet des trousseaux publics bloqués ; vérifiez le chemin Node réellement utilisé par le service et redémarrez |
| Python certifi | 2026.10.19 ou version plus récente | Vérifiez chaque environnement d’exécution réel ; vous ne pouvez pas mettre à jour un seul package sous global Python |
| pip | 26.2.2 ou version plus récente | Mettez à jour séparément pip dans l’ancien environnement virtuel et vérifiez la version après la création du nouvel environnement. |
| uv | 0.13.4 ou version plus récente | Mettre à jour une copie de l’outil tel qu’il a été réellement installé |
| Go | 1.27.3 ou 1.26.10, la version mise à jour de la branche correspondante est également disponible | Reconstruisez et déployez les programmes concernés après la mise à jour de la chaîne d’outils, ou obtenez le binaire de réparation du fournisseur |
| Oracle JDK | Correctifs Critical pour les lignes de version prises en charge correspondantes | Différents éditeurs JDK suivent leurs propres annonces ; il n’existe pas de numéro de version unique qui s’applique à toutes les versions de Java |
| Cloudflare Tunnel | cloudflared 2026.10.2 ou version plus récente | Mettre à jour les services en cours d’exécution ; le déploiement du conteneur nécessite le remplacement de l’image et le redéploiement |
| Cloudflare One／WARP | La version client fixe correspondant à la plateforme ou la version stable mise à jour | Les mesures côté client et côté serveur sont confirmées séparément. Pour les versions spécifiques de la plateforme, voir l’annexe 7 |
Les instructions originales pour Node, Python, Go, Oracle et Cloudflare sont respectivement disponibles en 13, 12, 14, 15, 7.
Problème de base de données de certificats indépendants Python
Les responsables du Python ont souligné que l’ancien pip utiliserait une combinaison de confiance système et de certifi intégré. La simple modification du magasin de certificats système ou l’ajout d’un fichier CA à pip ne peut pas exclure de manière fiable son ancienne approbation intégrée. Par conséquent, PIP_CERT, REQUESTS_CA_BUNDLE ou --cert ne peuvent pas être utilisés comme remplacement de réparation universel pour l’ancien pip. 12
Vérifiez les environnements virtuels existants après la mise à jour. Vérifiez également la version pip réellement installée dans les environnements nouvellement créés afin que les anciens composants d’amorçage ne réintroduisent pas d’outils vulnérables. Pour la mise à niveau initiale, suivez les sources de téléchargement et les étapes de vérification SHA-256 dans l’avis de Python avant de mettre à jour d’autres packages. 12
Go et autres programmes compilés
Le correctif pour Go a modifié la logique de validation pour crypto/x509. 14 Du point de vue du mécanisme de déploiement, la mise à jour du compilateur sur la machine de développement ne réécrira pas le binaire déjà déployé. Pour obtenir le nouveau blocage de la couche de code, l’application doit être reconstruite et remplacée, ou une version mise à jour fournie par le fournisseur doit être utilisée. La question de savoir si un programme plus ancien peut également bénéficier des mises à jour de la racine du système dépend du chemin de vérification réel qu’il utilise.
Conteneurs et applications packagées
Le package de certificat système, les dépendances de l’application et le temps d’exécution dans le conteneur sont généralement déterminés par le contenu de l’image. La mise à jour de l’hôte n’est pas égale à la mise à jour du contenu de l’image ; l’image de base et les dépendances doivent être mises à jour, et l’instance en cours d’exécution doit être reconstruite, déployée et vérifiée. Les applications packagées et les programmes de bureau fournis avec leur propre environnement d’exécution doivent également être mis à jour en fonction des canaux de publication des fournisseurs. 710
6 Instructions de mise en œuvre de la réparation
Déterminez d’abord l’objet d’inspection
Il est recommandé d’enregistrer les informations suivantes pour les services qui doivent être protégés, puis de sélectionner le chemin de réparation correspondant. Il s’agit d’une liste de contrôle de déploiement qui ne nécessite pas que tous les composants soient présents sur chaque système.
| Projet | Ce qui doit être enregistré |
|---|---|
| Applications et utilisations | Navigateur, client de paiement API, service d’envoi d’e-mails, outil de téléchargement, proxy inverse, etc. |
| poste de travail | Hôte, conteneur, machine virtuelle, application de bureau ou appareil mobile |
| Vérifier la mise en œuvre | Validateur de système d’exploitation, bibliothèque OpenSSL, Node, Python, Java ou implémentation personnalisée d’application |
| source fiable | Package système CA, certifi, magasin de confiance JDK, CA bundle intégré ou configuration d’entreprise |
| Statut de réparation | Version installée, source du correctif, redémarrage ou redéploiement |
| Résultats d’acceptation | Si la chaîne concernée est rejetée, si la connexion commerciale normale réussit et l’heure du contrôle |
Le guide du développeur pour Cloudflare indique spécifiquement que SDK peut déléguer la vérification à d’autres composants ; seule la mise à jour du SDK de niveau supérieur ne modifie pas nécessairement la véritable politique de confiance. 7
Systèmes d’exploitation et navigateurs
Windows : active et vérifie les mises à jour automatiques de la liste de confiance des certificats. Distribuez les mises à jour via des politiques de gestion établies. Les appareils hors ligne ou les appareils dont les mises à jour automatiques sont désactivées nécessitent que le blocage soit appliqué via un processus de gestion approprié. Vérifiez séparément les programmes qui n’utilisent pas la validation du système Windows. 4
Apple Plate-forme : Mises à jour complètes du système, des composants de sécurité et des applications. Pour les outils de développement sur macOS, vérifiez également son backend TLS, ses fichiers de certificat et ses sources d’installation. On ne peut pas juger que la machine entière a été réparée simplement parce que Safari a rejeté la chaîne de test. 4
Android : met à jour les services Google Play sur les appareils qui en sont équipés. Google indique que le redémarrage d’un appareil peut déclencher une mise à jour immédiate. Pour les appareils ne disposant pas de ces services, suivez l’avis du fournisseur ou ROM ; La déclaration de couverture de Google ne s’applique pas automatiquement à tous les appareils Android. 1
Ubuntu/Debian: mettez à jour les packages de certificats à partir des référentiels pris en charge et consultez l’avis relatif à la distribution installée. Par exemple, un système basé sur APT peut utiliser :
sudo apt update
sudo apt install --only-upgrade ca-certificates
dpkg-query -W -f='${Package} ${Version}\n' ca-certificatesLes mises à jour pertinentes pour Ubuntu 22.04, 24.04, 26.04 et 26.10 constituent une prise en charge standard ; les versions antérieures doivent vérifier la prise en charge de ESM et l’état de l’entrepôt. Une fois la commande terminée, vous devez toujours comparer la version du groupe de correctifs dans le bulletin. 89
RHEL et produits associés : Vérifiez le package de certificats et les errata de sécurité par canal de produit. La vérification des versions peut être effectuée en utilisant :
rpm -q ca-certificatesUtilisez le mécanisme de mise à jour DNF/YUM pris en charge pour obtenir les correctifs du fournisseur ; si la chaîne n’a pas encore fourni de correctif, ne considérez pas “aucun paquet pouvant être mis à jour” comme sûr. Lorsqu’il est nécessaire de supprimer temporairement la confiance racine, adoptez les mesures clairement énumérées par le fabricant et évaluez la compatibilité des certificats commerciaux légitimes. 10
FreeBSD : met à jour la branche système concernée comme indiqué par l’avis officiel, puis redémarrez les démons à l’aide de la configuration de confiance OpenSSL concernée ou redémarrez le système. 11
Applications et images
Après avoir terminé les mises à jour correspondantes du runtime et des dépendances de certificat, vérifiez le chemin du fichier exécutable sur lequel le service est réellement exécuté pour éviter que le terminal ne passe à une nouvelle version et que le démon utilise toujours l’ancien répertoire d’installation. Pour les Python multi-environnements, les conteneurs de services et les applications fournis avec leur propre environnement d’exécution, ils doivent être vérifiés séparément.
Pour les composants qui doivent être reconstruits, enregistrez la version de build, la version de dépendance et l’ID de l’image de déploiement. L’objet d’acceptation est l’instance en cours d’exécution réelle et ne peut pas simplement vérifier la nouvelle balise dans la machine de construction ou le registre d’images. 71214
Migration de certificat de site Web
Si la chaîne d’un site Web contient un CA intermédiaire révoqué ou bloqué, ou s’appuie finalement sur une racine douteuse, procurez-vous une autre chaîne que les clients acceptent toujours. Installez la chaîne complète de certificats de serveur et vérifiez chaque entrée, y compris les équilibreurs de charge, les proxys inverses, les points de terminaison CDN et les origines directement accessibles. 15
La nécessité ou non d’une migration dépend de la chaîne réelle. Le filtrage uniquement par marque de vente de certificats peut manquer les relations de revente ou de signature croisée ; le simple fait d’attendre un renouvellement régulier à l’expiration ne termine pas nécessairement la migration avant la mise à jour du magasin racine.
Pour les autres certificats de site Web normaux émis par CA qui ne reposent pas sur la racine affectée, il n’est pas nécessaire de les signer à nouveau en raison de cet incident. Dans le même temps, le serveur du site Web lui-même doit toujours effectuer des contrôles de réparation côté client lors de l’appel à des services externes.
7 Vérifiez que le correctif prend réellement effet
La vérification de version et la vérification de comportement sont effectuées séparément
Les vérifications de version sont utilisées pour confirmer que les correctifs ou les composants corrigés ont été déployés ; des contrôles comportementaux sont utilisés pour confirmer que l’application utilise réellement le chemin de vérification attendu. Les deux vérifications résolvent des problèmes différents et aucune d’elles ne peut être remplacée par « Commande de mise à jour exécutée avec succès ».
Le responsable de l’événement fournit le matériel du site de test et de la chaîne de certificat, et l’entrée est concentrée dans l’annexe 4. Il doit être vérifié dans l’environnement d’exploitation réel de l’application cible, en conservant la configuration normale de vérification des certificats. 47
| Vérifier les résultats | Conclusions que l’on peut tirer |
|---|---|
| Rejeter explicitement car la chaîne concernée n’est pas fiable | Indique que le chemin de vérification testé a rejeté la chaîne |
| Acceptez normalement la chaîne concernée | Indique que ce chemin doit continuer à être réparé ou la configuration vérifiée. |
| Erreur DNS, délai d’expiration de la connexion, rejet du proxy ou service inaccessible | On ne peut donc pas en conclure que le risque lié au certificat a été éliminé. |
| Le navigateur rejette, mais l’appel de l’application n’est pas vérifié | Il ne peut confirmer que le navigateur, pas le programme en arrière-plan. |
| La chaîne A a été rejetée | Il faut encore se demander si le client accepte un autre chemin de signature croisée |
Le test doit également couvrir les connexions commerciales normales afin d’éviter de confondre tous les échecs de requête avec des réparations réussies après des échecs commerciaux résultant d’une suppression excessive de confiance.
Conditions de réalisation suggérées
- La source de mise à jour et la version des composants concernés sont documentées.
- L’instance en cours d’exécution correspondante a été redémarrée, reconstruite ou redéployée.
- L’application réelle rejette la chaîne concernée et la vérification TLS pour les activités normales continue de fonctionner.
- Il n’existe aucune configuration permettant de désactiver temporairement la vérification du certificat afin de restaurer la connexion.
- Si une migration de certificat de site Web est impliquée, toutes les entrées externes ont été commutées et vérifiées.
Les conditions de réalisation ci-dessus constituent des suggestions de réception en exploitation et en maintenance pour ce stockage ; cela n’équivaut pas à prouver que l’équipement ne présente aucun autre problème de sécurité.
8 Trafic historique HTTPS et limites de risque
Trois types de clés ont des utilisations différentes
| clé | Objectif principal |
|---|---|
| Clé privée CA | Signez la liaison d’identité et de clé publique dans le certificat |
| Clé privée du site Web | Prouver l’identité du serveur dans la poignée de main TLS authentifiée par certificat |
| clé de session | Protéger les données effectivement transmises sur une connexion |
L’obtention de la clé privée CA n’équivaut pas à l’obtention de la clé privée du site Web ou de toutes les clés de session. Une connexion normale A avec secret de transfert utilisant un échange de clé temporaire n’exposera pas automatiquement les sessions historiques simplement parce que la clé de signature à long terme est ultérieurement compromise. Pour les attributs de sécurité pertinents de TLS 1.3, voir RFC 8446. 16
Le principal risque survient cette fois lors de la phase d’authentification : si le client accepte le certificat du faux serveur, il peut établir une connexion encore cryptée avec l’attaquant. TLS 1.3 nécessite également une authentification fiable ; la simple mise à niveau de la version du protocole ne remplace pas le blocage de CA.
Des jugements qui peuvent et ne peuvent pas être portés à l’heure actuelle
Confirmé :, les clés privées intermédiaires spécifiques CA sont compromises ; les chemins de confiance du public concernés ont une large portée ; les principales plates-formes et plusieurs écosystèmes logiciels ont pris des mesures. 145
Non établi par cet incident : que tous les utilisateurs ont subi des attaques de l’homme du milieu, que d’autres clés privées CA sont compromises, que tout le trafic historique HTTPS est déchiffrable ou que la mise à jour d’un navigateur protège chaque application sur l’appareil.
Le jugement final concernant un service spécifique doit être basé sur sa chaîne de certificats, sa politique de vérification, les composants en cours d’exécution et l’état de la mise à jour, et pas seulement sur le fait que la barre d’adresse indique HTTPS.
Annexe A Nom CA intermédiaire concerné
Les noms suivants facilitent la vérification des actifs. Les noms ne remplacent pas les empreintes digitales du certificat ou les identifiants de clé publique. La correspondance automatisée doit utiliser les identifiants exacts publiés par les responsables de l’incident ou les fournisseurs, y compris les certificats à signature croisée. 5
| Milieu CA | Objectif | Organisations associées |
|---|---|---|
| EM EV TLS CA - G3B | TLS | eMudhra BV |
| EM OV TLS CA - G3B | TLS | eMudhra BV |
| EM DV TLS CA - G3B | TLS | eMudhra BV |
| EM EV TLS CA - G3C | TLS | eMudhra Inc |
| EM OV TLS CA - G3C | TLS | eMudhra Inc |
| EM DV TLS CA - G3C | TLS | eMudhra Inc |
| EM OV CS CA - G3B | signature de code | eMudhra BV |
| EM OV CS CA - G3C | signature de code | eMudhra Inc |
TLS n’est pas exactement le même mécanisme de validation et de révocation que la signature de code. Cet article se concentre sur HTTPS/TLS ; l’environnement de signature de code doit adopter Microsoft, JDK ou des fournisseurs de logiciels associés à cette fin de vérification, et les résultats des tests du navigateur ne doivent pas être considérés comme une acceptation de signature de code. 515
Annexe B Lien de référence
Les sources suivantes ont été vérifiées le 22 octobre 2026. L’annonce continue peut continuer à être mise à jour, et le statut et la version dans le texte doivent être compris en fonction de la date de ce document.
Faits sur les incidents et gestion de la plateforme
[1] Google Chrome et Android Annonce officielle Décrit les failles de clé privée, le blocage SPKI, la distribution du service Google Play, la protection CT et les plans de suppression du référentiel racine Chrome. Protecting Chrome and Android Users from Compromised eMudhra Intermediate CA Certificates
[2] Mozilla Bugzilla 2083449 Enregistrement d’événement Contient des rapports originaux, une vérification indépendante, une enquête sur le processus de génération, des correctifs ultérieurs pour Firefox Android et des discussions sur la migration des certificats légaux ; concentrez-vous sur les commentaires 5, 11, 29 et 30. eMudhra Private key compromise of Intermediate Certificates
[3] Mozilla Firefox Avis de sécurité Description de la distribution d’urgence du OneCRL et de l’élimination ultérieure des Firefox/NSS. Protecting Firefox users following the compromise of eMudhra intermediate certificates
[4] Coordinateur d’événements Dennis Jackson Résumé de maintenance et portail de détection Fournit des instructions supplémentaires sur l’état de réparation de la plate-forme et des logiciels, l’entrée aux tests, les matériaux de la chaîne de certificats publics et les environnements tels que Windows/macOS. Les résultats des tests représentent uniquement les chemins de vérification réels testés. eMudhra Intermediate CA Compromise
[5] Mozilla Avis aux responsables de la distribution et du truststore Décrit 6 TLS et 2 intermédiaires de signature de code CA, Sectigo, les limites de traitement de signature croisée, de révocation et de confiance racine, et répertorie le certificat exact et l’identification de la clé publique. oss-security eMudhra Intermediates Compromise
[6] eMudhra Déclaration officielle de l’événement Fournir l’explication préliminaire du fabricant sur le processus de génération de clé ; la cause exacte sera encore soumise à la conclusion de l’enquête terminée. eMudhra Statement on Recent Certificate Security Incident
[7] Cloudflare Instructions officielles d’incident et de réparation Couvre WARP, Cloudflare Tunnel, la vérification du site d’origine, les dépendances d’exécution, les mises à jour d’images et les méthodes de vérification. 8 eMudhra certificates are compromised Here is what you need to know
Systèmes d’exploitation et distributions
[8] Ubuntu Annonce officielle de réparation Répertorie les packages de correctifs ca-certificates, les canaux de support et les étapes de mise à jour ciblées pour chaque version. eMudhra CA compromise fixes available
[9] Debian Dossier officiel de problème et de réparation L’enregistrement des correctifs du responsable et le package de version correspondant doivent être considérés comme la norme, et les premières suggestions temporaires lors de la discussion du problème ne doivent pas être considérées comme la solution finale. Debian bug 1151413 eMudhra Intermediate CA key compromise
[10] Red Hat Bulletin de sécurité officiel RHSB 2026 012 Répertorie les RHEL 6 à 10, les impacts associés aux produits et aux conteneurs, ainsi que les entrées de version et d’élimination provisoire des correctifs. Certificate compromise eMudhra
[11] FreeBSD Bulletin de sécurité officiel Fournissez les branches du système concernées, les versions de réparation et les exigences de redémarrage du service. FreeBSD SA 26 73 caroot
Exécution et protocoles
[12] Python Description officielle de l’événement Fournit des lignes de base de réparation pour pip, certifi, uv, etc., explique le problème de l’ancien magasin de confiance indépendant pip et fournit la méthode de mise à niveau initiale avec la vérification SHA-256. Information for Python users regarding eMudhra emSign CA certificate security incident
[13] Node.js 24.22.1 Sortie officielle Contient les mises à jour du magasin racine NSS et rejette les modifications contenant des chaînes de certificats de clé publique bloquées. Node.js 24.22.1 security release
[14] Go Version de sécurité officielle Mise à jour du filtrage de la chaîne de certificats crypto/x509 pour Go 1.27.3/1.26.10. Go 1.27.3 and Go 1.26.10 are released
[15] Oracle JDK Instructions officielles d’élimination Expliquez le correctif critique JDK et les mesures de configuration associées lorsqu’il ne peut pas être mis à niveau immédiatement. Distrusting eMudhra Intermediate Certificates in Oracle JDK
[16] TLS 1.3 Norme de protocole RFC 8446 Voir l’annexe E.1 pour obtenir des instructions sur l’authentification de l’identité, l’échange de clés temporaires et la confidentialité de transmission. The Transport Layer Security Protocol Version 1.3
[17] Certificat racine lié à l’événement et données de relation d’émission Utilisé pour comprendre la relation directe entre émetteur et signature croisée ; le statut d’inclusion du magasin racine ne peut pas remplacer le dernier statut de révocation ou de blocage du client. Root certificate relationships JSON