Certificats révoqués : vérifiez chaque correctif en aval

La révocation déclare un certificat invalide. La remédiation en aval permet d’établir si les clients que vous utilisez le rejettent réellement. Navigateur, outils en ligne de commande et tâches de compilation peuvent s’appuyer sur des magasins de confiance et des mécanismes de révocation différents. Un correctif efficace dans le navigateur ne suffit donc pas à clore toutes les tâches.

L’incident des certificats eMudhra illustre cette distinction. Selon Apple, ses bibliothèques réseau bloquent les certificats concernés, alors que certains outils en ligne de commande peuvent encore les accepter par l’intermédiaire d’un fichier de certificats distinct. La question est concrète : quel mécanisme chaque outil déployé utilise-t-il, et quelles preuves exigerez-vous avant de clore sa tâche de remédiation ? Consignes d’Apple sur l’incident.

Que montre l’incident eMudhra ?

Cet incident montre pourquoi vous devez suivre un correctif jusqu’aux logiciels qui l’utilisent réellement. Une mesure prise en amont peut protéger un client tout en laissant un autre dépendre d’une mise à jour différente.

D’après Apple, huit clés de certificats intermédiaires ont été compromises : six pour TLS, qui protège les connexions réseau, et deux pour la signature de code. Chaque autorité intermédiaire TLS disposait d’un certificat eMudhra et d’un certificat portant une signature croisée de Sectigo, soit douze certificats TLS concernés. Douze certificats ne signifient pas douze clés compromises indépendamment. Consignes d’Apple sur l’incident.

Apple indique que le blocage a commencé le 19 octobre 2026. Safari, Mail et les autres applications utilisant ses bibliothèques réseau bénéficient automatiquement de cette protection. Les consignes distinguent les outils qui utilisent /etc/ssl/cert.pem, dont certaines configurations de Git et de curl. Ces outils peuvent continuer à accepter les certificats concernés. Lors de notre consultation du 29 octobre, Apple annonçait une future mise à jour logicielle et proposait des modifications facultatives aux administrateurs, assorties de limites importantes. Consultez la version actuelle de l’avis avant d’agir. Consignes d’Apple sur l’incident.

Cette distinction est plus précise que l’affirmation selon laquelle tous les Mac ou toutes les applications Apple seraient vulnérables. Elle est aussi plus utile : elle désigne une chaîne de dépendances à examiner.

Dans sa mise à jour du 28 octobre, le chercheur rapporte que macOS 27.2 a rétabli un fichier de certificats modifié manuellement. Les consignes d’Apple confirment le risque général qu’une mise à jour logicielle remplace ce fichier. Attribuez l’observation propre à cette version au chercheur et utilisez les instructions d’Apple pour les mesures d’atténuation recommandées par Apple.

Rien de tout cela ne prouve que votre trafic a été intercepté. Le projet consacré à l’incident indique que l’on ignore si une exploitation a eu lieu en dehors des clients qui imposent Certificate Transparency. L’acceptation de ces certificats justifie une remédiation ; elle ne permet pas d’affirmer qu’une intrusion a eu lieu.

Pourquoi un certificat révoqué peut-il rester accepté ?

Un client a besoin d’une politique de confiance et d’un moyen d’appliquer l’invalidation correspondante. Deux applications installées sur la même machine ne consultent pas nécessairement les mêmes sources pour prendre ces décisions.

Un certificat racine constitue une ancre de confiance. Un certificat intermédiaire relie les certificats émis sous son autorité à cette ancre. Un magasin de confiance regroupe les certificats ou les décisions de confiance qu’un client consulte pour valider une connexion.

La liste des racines ne décrit pas à elle seule tout le comportement du client. Dans les échanges du programme de certificats racines de Mozilla, Dennis Jackson précise que Firefox a reçu un blocage OneCRL le 17 octobre à 22:59 UTC. Mozilla a ensuite retiré une racine de NSS le 20 octobre pour protéger les logiciels en aval dépourvus de OneCRL. Le Chrome Root Program décrit un autre blocage, diffusé le 17 octobre par CRLSet à partir de l’empreinte de la clé publique. Il couvre les certificats TLS originaux et ceux portant une signature croisée. Déclarations des responsables des programmes de certificats racines.

Ces mécanismes de protection s’adressent à des logiciels différents. Un outil dont la liste de certificats provient de l’écosystème d’un navigateur ne reçoit pas nécessairement les mises à jour de sa liste de blocage.

Ce tableau aide à organiser la réponse ; il ne remplace pas les instructions de l’éditeur. Le retrait d’une racine peut affecter des chaînes légitimes sans rapport avec les intermédiaires compromis, une conséquence qu’Apple signale explicitement. Suivez la méthode documentée pour le client dont vous êtes responsable. Consignes d’Apple sur l’incident.

Notre guide de reprise après un détournement de domaine explique pourquoi rétablir le DNS et demander la révocation des certificats répondent à des questions différentes. Ici, le travail commence par le client installé : déterminez ce qu’il exécute, à quoi il accorde sa confiance et comment vous savez que le correctif lui est parvenu.

Quels clients en aval devez-vous vérifier ?

Inventoriez les clients réellement utilisés par l’équipe, puis regroupez-les selon leurs exécutables et leurs dépendances de confiance. Une liste de ressources mentionnant seulement « portables macOS » ou « agents CI » est trop générale pour déterminer la remédiation applicable.

Partez d’un flux de travail réel. Suivez, par exemple, la récupération d’un dépôt depuis le terminal d’un développeur, puis depuis la tâche qui prépare une version du logiciel. Identifiez le programme exécuté dans chaque environnement et la configuration de ses dépendances pertinentes. N’ajoutez d’autres catégories de clients que si elles existent dans votre parc.

Distinguez navigateur, outils système et outils installés séparément

Documentez d’abord le navigateur ou l’application, puis examinez les outils en ligne de commande séparément. Pour chacun de ces outils, conservez le chemin de l’exécutable, sa version, la bibliothèque ou le composant TLS pertinent, la configuration de confiance active et l’environnement d’exécution. Lorsqu’un élément reste à établir, indiquez « inconnu » et désignez la personne chargée de l’examiner.

Ne supposez pas que le nom d’un paquet suffit à décrire toute la chaîne de dépendances. La modification de Homebrew supprimant la dépendance de Git au cURL système de macOS a été fusionnée le 28 octobre. Elle montre concrètement qu’une remédiation peut passer par la dépendance cURL de Git, au-delà de la simple présence d’un ensemble de certificats d’autorités mis à jour.

La fusion d’une modification de paquet ne vous indique pas pour autant quel binaire le terminal d’un développeur lance. Une machine peut comporter plusieurs installations. Identifiez l’exécutable réellement utilisé dans le flux de travail concerné et établissez sa configuration avant de considérer la mise à jour du paquet comme une preuve de clôture.

Examinez les environnements d’exécution et les magasins intégrés

Si l’application établit des connexions TLS sortantes au moyen de l’environnement d’exécution d’un langage, incluez celui-ci dans l’examen. Si elle intègre son propre magasin de certificats, documentez l’artefact applicatif et le magasin réellement chargé. Il s’agit de catégories à examiner, et non d’une affirmation selon laquelle tous les environnements d’exécution ou toutes les applications à magasin intégré seraient touchés par cet incident.

L’inventaire doit répondre à une question pratique : un autre ingénieur peut-il identifier le même logiciel à partir de vos notes ? « Python mis à jour » ou « paquet de certificats corrigé » laisse trop d’éléments implicites. Une version de l’environnement d’exécution, un identifiant d’environnement et une référence de configuration permettent à la personne suivante de reproduire l’examen.

Documentez les réglages qui remplacent les valeurs par défaut. Si le processus désigne explicitement un fichier de certificats, documentez cette configuration sans exposer de secrets. Le réglage système par défaut constitue une preuve faible lorsque l’application impose son propre choix.

Traitez la CI comme un environnement déployé

Pour l’infrastructure de compilation, identifiez l’agent ou l’image qui a exécuté la tâche concernée. Conservez une empreinte immuable de l’image lorsqu’elle est disponible, ainsi que la version du client et la configuration de confiance dans cet environnement. Tester un portable ne revient pas à tester la tâche qui récupère les sources ou les dépendances avant une publication.

Déterminez qui peut remplacer cet artefact et comment les tâches actives reçoivent son remplacement. Reconstruire une image dans un registre n’est qu’une étape. Le dossier de vérification doit identifier l’artefact qu’une tâche ultérieure a réellement exécuté.

Un inventaire utile peut rester succinct :

Utilisez les fonctions qui existent dans l’équipe. Un fondateur peut être responsable de plusieurs lignes ; chacune exige tout de même une décision explicite et un résultat.

Quelles preuves permettent de clore une tâche de remédiation ?

Clôturez un périmètre client défini lorsque vous pouvez relier l’avis, la modification déployée et un résultat de vérification probant. Laissez clairement ouverts les périmètres que vous n’avez pas vérifiés.

La méthode qui suit est une proposition opérationnelle, et non une exigence d’Apple ou de Mozilla. Elle vise à rendre le motif de clôture assez précis pour qu’une autre personne puisse l’examiner.

1. Nommez le périmètre concerné. Précisez les flux de travail, machines ou tâches de compilation couverts. Indiquez les exclusions et les logiciels dont le cas reste à résoudre.
2. Ajoutez un lien vers l’avis applicable. Expliquez pourquoi son mécanisme concerne ce client. Ne remplacez pas les instructions actuelles de l’éditeur par un commentaire de discussion.
3. Identifiez l’artefact déployé. Conservez la version de l’exécutable, la référence de configuration ou l’empreinte de l’image examinée.
4. Décrivez la remédiation. Indiquez ce qui a changé, qui l’a déployé et s’il s’agit d’une mesure de contournement ou du correctif durable documenté.
5. Documentez la vérification. Incluez la méthode, l’environnement, la date et l’heure, le comportement attendu et le résultat observé.
6. Définissez un événement déclenchant une nouvelle vérification. Désignez l’opération de maintenance ou la mise à jour de l’éditeur qui doit entraîner un nouvel examen.

Distinguez le rejet d’un certificat de l’échec d’une requête

L’échec d’une connexion ne prouve pas automatiquement que le client a rejeté la chaîne compromise. Un échec DNS, un serveur indisponible ou un mandataire réseau peuvent également empêcher une requête d’aboutir.

Utilisez une méthode de vérification approuvée, adaptée au client et à l’environnement. Conservez suffisamment de résultats pour établir l’issue de la validation des certificats, plutôt que la seule mention « échec de la requête ». Retirez les en-têtes sensibles, les jetons et les adresses internes des preuves largement partagées.

N’affaiblissez pas la validation des certificats pour pouvoir exécuter un test. Si le résultat est ambigu, indiquez qu’il ne permet pas de conclure et recherchez la cause. La mention claire « pas encore vérifié » est plus utile qu’une tâche marquée comme réussie alors que son test n’a jamais sollicité le mécanisme visé.

Rédigez un dossier de clôture qu’un tiers peut remettre en question

Prenez cet exemple hypothétique, qui ne décrit pas une mesure issue de l’incident eMudhra :

Périmètre : l’étape de récupération du dépôt dans une chaîne de publication. Responsable : le responsable de l’infrastructure de compilation. Avis : les consignes de l’éditeur concerné. Artefact : l’empreinte exacte de l’image de l’agent utilisée par la tâche de vérification. Modification : mise à jour de la dépendance du client et de sa configuration de confiance active. Vérification : un test approuvé exécuté au moyen de ce client déployé a produit le rejet attendu lors de la validation du certificat ; méthode, horodatage et résultats expurgés joints. Nouvelle vérification : à la prochaine reconstruction de l’image de l’agent. Exclusion : les postes des développeurs font toujours l’objet d’une tâche distincte.

Ce dossier ne déclare volontairement pas toute l’entreprise protégée. Il identifie un périmètre vérifié et en laisse un autre à traiter. Si l’équipe ne peut pas encore identifier l’image exécutée, le champ consacré à l’artefact reste inconnu et la tâche demeure ouverte.

Votre processus de divulgation coordonnée suit peut-être déjà plusieurs éditeurs. Appliquez la même rigueur à votre parc : la réponse d’un éditeur et les preuves de votre déploiement constituent des éléments distincts, même lorsqu’ils relèvent d’un seul incident.

Comment éviter qu’une mesure de contournement soit annulée ?

Associez les mesures temporaires aux opérations de maintenance susceptibles de les annuler. Une vérification réussie aujourd’hui ne démontre pas l’état d’un fichier après une mise à jour du système d’exploitation.

Apple avertit que les mises à jour de macOS peuvent remplacer /etc/ssl/cert.pem. Avoir modifié le fichier une fois ne constitue donc pas une procédure d’exploitation complète. Si vous appliquez les modifications facultatives documentées, indiquez le responsable, l’état attendu et la mise à jour qui impose une nouvelle vérification. Privilégiez le correctif durable de l’éditeur dès qu’il est disponible et applicable à votre environnement. Consignes d’Apple sur l’incident.

Pour chaque mesure de contournement, répondez à trois questions :

• Quelle opération courante pourrait supprimer ou contourner cette modification ?
• Qui vérifie le client concerné après cette opération ?
• Quel résultat entraînerait la réouverture de la tâche de remédiation ?

Les mêmes questions sont utiles lorsqu’une application ou l’image d’un agent est reconstruite. Réexaminez le logiciel réellement utilisé une fois son remplacement intégré au flux de travail. Une configuration d’image approuvée et une tâche qui exécute encore un artefact ancien correspondent à deux situations différentes.

Adaptez la vérification aux besoins. Consigner une empreinte d’image, une configuration client et un résultat de vérification ne nécessite pas un nouveau système de gestion de parc. Il faut en revanche désigner la personne responsable du prochain événement, surtout lorsque le correctif actuel est explicitement temporaire.

Un correctif sans historique clair de divulgation peut laisser les utilisateurs dans l’incertitude sur les changements apportés. Votre dossier de clôture interne doit lever la même incertitude : ce qui a été corrigé, où le correctif a été déployé, ce qui a été vérifié et ce qui reste à faire.

Comment Kit distingue la résolution de la vérification du correctif

Un outil de gestion des rapports peut conserver la trace des responsabilités pendant que vos outils opérationnels établissent le comportement des clients. Gardez ces rôles explicites lorsque vous consignez le résultat.

Le processus CSIRT de Kit permet d’attribuer un rapport à un responsable et distingue resolved de fix_verified. L’étape de vérification conserve l’identité de la personne connectée et un commentaire facultatif. Les changements d’état gardent la trace de cette personne et du commentaire, et un rapport résolu peut revenir à l’état in_progress si d’autres travaux sont nécessaires.

Ces états n’exécutent aucun test de certificat. Kit n’inventorie pas les magasins de confiance, ne détermine pas quels binaires le parc exécute, ne corrige pas les postes et ne détecte pas automatiquement le remplacement d’une mesure de contournement. Son libellé de vérification n’exige aucune preuve jointe. À l’équipe de définir le périmètre et de conserver les preuves opérationnelles qui étayent la décision consignée.

Utilisez le rapport pour rendre cette décision compréhensible : identifiez les clients vérifiés, renvoyez au dossier de vérification et nommez le responsable des travaux restants. Ne laissez pas un agent ou un environnement d’exécution non vérifié disparaître derrière une mention « corrigé » appliquée à l’ensemble de l’incident.

Pour ce type d’incident, clore le travail suppose de pouvoir relier une affirmation à l’action de l’éditeur, à un logiciel déployé et à un résultat observé. Commencez par un flux de travail important, documentez ses dépendances et ne clôturez que ce que vous avez vérifié. Si vous cherchez un espace partagé pour attribuer les rapports et consigner ce suivi, essayez Kit.