Résumé

  • Le retrait d’une racine, une date de défiance ou une version de navigateur modifie la politique voulue ; cela ne prouve pas que chaque système, application, conteneur ou équipement l’applique.
  • Il faut conduire l’opération comme une migration des systèmes de validation, avec des tests de rejet pour chaque source de confiance et chaque cohorte de clients.

Dans un scénario de validation contrôlé et hypothétique, une cohorte récente de Chrome rejette une chaîne TLS, tandis qu’un poste Windows administré par l’entreprise et un service lancé dans une ancienne image de conteneur l’acceptent. Le certificat est identique dans les trois essais hypothétiques.

Ce n’est pas une anomalie marginale de syntaxe. C’est la carte de trois décisions de confiance différentes.

En 2024, Chrome a annoncé une défiance ciblée envers certaines racines d’Entrust. La règle dépendait de la date du premier Signed Certificate Timestamp : les certificats postérieurs à la date publiée ne seraient plus approuvés par défaut à partir de Chrome 131, tandis que les certificats antérieurs recevaient un traitement différent. Il ne s’agissait donc pas d’effacer un seul fichier que tous les clients auraient interprété au même instant, mais d’appliquer une règle d’acceptation avec une date, une version et la possibilité de racines locales explicitement approuvées.

L’architecture de Chrome rend le problème du parc visible. Sur Windows, macOS, ChromeOS, Linux et Android, Chrome a engagé une transition vers son propre magasin de racines et son vérificateur intégré. Sur iOS, les règles de la plateforme Apple s’imposent. Une politique d’entreprise a aussi permis temporairement de choisir entre le magasin Chrome et celui du système, et Chrome peut reprendre des racines locales explicitement approuvées par le système. Le nom du navigateur ne suffit donc pas à identifier la source de confiance.

Microsoft révèle une autre divergence. Sa documentation distingue Removal, EKU Removal, Disallow, Disable et NotBefore. Le retrait d’une racine de la liste de confiance rend ses chaînes non fiables par défaut, mais certains magasins autorisent encore une installation manuelle. Disallow est plus fort : la racine entre dans la liste des certificats interdits et une installation manuelle ne rétablit pas simplement la confiance. Disable et NotBefore ont encore d’autres effets temporels et fonctionnels.

Ces états passent par un mécanisme de mise à jour. Les clients Windows connectés peuvent recevoir automatiquement les listes de confiance et d’interdiction. Un parc isolé peut rediriger ces listes vers un serveur interne. Microsoft décrit comment vérifier séparément AuthRoot et Disallowed ainsi que leur dernière synchronisation. Une stratégie publiée sur un serveur ne prouve pas qu’un terminal l’a consommée.

Apple publie un magasin racine partagé et archive les versions précédentes. La version installée devient donc un élément de preuve. Elle rappelle aussi qu’un appareil ancien n’est pas défini par la liste actuelle d’une page web. Mozilla distingue de même la désactivation de droits de confiance et le retrait du certificat, peut planifier l’une ou l’autre mesure et permet aux distributeurs dérivés de maintenir une sélection différente.

Nommer l’action avant de la mesurer

« Retirer la racine » est trop vague pour piloter un incident. L’objectif peut être de refuser toutes les chaînes, seulement les certificats émis après une date, un usage particulier ou une racine dans un programme donné, tout en conservant une exception privée. Chaque action exige un résultat de test différent.

Le dénominateur n’est donc pas le nombre d’appareils enrôlés, mais les cohortes de systèmes de validation : navigateur et version, magasin du système, environnement applicatif, magasin de certificats du runtime, image de base, micrologiciel, client embarqué et dérogation administrée. Pour chacune, il faut conserver l’empreinte de la racine, la chaîne observée et le résultat attendu. Un vieux client qui continue à se connecter après une défiance de sécurité est en échec, même si la supervision de disponibilité reste verte.

Les documents publics établissent des politiques et des mécanismes de distribution. Ils ne révèlent ni l’inventaire d’un opérateur, ni ses dérogations, ni la cadence de ses micrologiciels. La conclusion opérationnelle est une inférence : le changement doit être rapproché des systèmes qui valident réellement le processus métier. Elle n’impute aucune panne à un client, un opérateur de racine ou une plateforme.

Sources