Résumé

  • Un SCT est la promesse signée d’un journal d’intégrer une entrée ; il ne remplace ni la validation normale du certificat ni la politique CT du navigateur.
  • Le bon critère de mise en production est l’acceptation observée par les clients visés, avec la politique et la liste de journaux effectives conservées comme preuve.

Le service de certificats a reçu trois SCT. Les signatures sont valides, le certificat a été déployé, la supervision interne est verte. Pourtant, une partie des navigateurs refuse la connexion. Le système n’a pas produit deux vérités incompatibles. Il a confondu deux décisions différentes.

Dans la RFC 9162, le SCT est une promesse précise : le journal a accepté la soumission et doit l’intégrer à son arbre de Merkle dans son délai maximal de fusion. L’inclusion et la cohérence peuvent ensuite être auditées. La RFC précise aussi que valider ce reçu ne remplace pas la validation habituelle du certificat serveur et de sa chaîne.

Chrome ajoute sa propre politique. Le navigateur tient compte du mode de présentation des SCT, du nombre de journaux distincts, de la diversité des opérateurs et de l’état de chaque journal lors de l’émission puis lors du contrôle. Pour les SCT incorporés dans un certificat d’au plus 180 jours, la politique actuelle demande au moins deux journaux distincts et deux opérateurs distincts, avec au moins un journal dans un état qui compte au moment du contrôle. Les SCT transmis par TLS suivent une autre combinaison.

Le tableau de bord qui affiche seulement « trois SCT reçus » perd donc l’information décisive. Trois reçus d’un même opérateur, d’un journal devenu non contributif ou d’un canal inadapté ne satisfont pas nécessairement la règle.

Une liste vivante, pas un catalogue éternel

Chrome publie chaque jour une nouvelle liste de journaux CT et y associe les opérateurs ainsi que des états de cycle de vie. La conformité dépend de ce que le client sait au moment où il vérifie le certificat. Il faut garder le numéro de version du client, l’horodatage de sa liste et l’état d’application de CT, pas seulement le nom commercial du navigateur.

La politique prévoit en outre un délai de fraîcheur de 70 jours. Si un client n’a pas obtenu une liste récente dans un format compris, Chrome cesse d’appliquer CT. Une connexion réussie sur un poste obsolète peut donc indiquer l’absence de contrôle, et non une meilleure conformité.

La liste de Chrome n’est pas une autorité universelle. Google la publie pour son écosystème et avertit les autres agents utilisateurs de ne pas la transformer en moteur d’application général. Apple applique une politique distincte : elle différencie les journaux actuellement approuvés de ceux qui l’ont été, fixe ses propres combinaisons de SCT et plafonne la contribution d’un même opérateur. La technologie est commune ; le verdict du client ne l’est pas entièrement.

Les fragments temporels ajoutent un calendrier caché

Les nouveaux journaux reconnus par Chrome doivent être découpés en fragments temporels. Chaque fragment accepte les certificats dont la date notAfter se trouve dans son intervalle. Le choix d’un journal dépend donc de la durée du certificat, pas uniquement de sa disponibilité ou de son opérateur.

Cette architecture rend la preuve contextualisée. Les identifiants de journaux, les dates des SCT, la durée du certificat et l’état de la liste doivent être rapprochés. Le guide de Chrome pour les exploitants rappelle même que les informations CT d’un certificat peuvent perdre leur validité avant l’expiration du certificat. Il peut alors falloir fournir de nouveaux SCT par TLS ou remplacer le certificat.

Les faits publics s’arrêtent ici : ils décrivent les normes et les politiques publiées. Ils ne révèlent pas le parc de navigateurs d’une entreprise, ses exceptions, ses points de terminaison, la fidélité de son simulateur ou ses incidents. L’idée d’un rapprochement systématique est une conclusion opérationnelle, non le récit d’une panne connue. Aucun échec actuel de Google, Apple, d’une autorité de certification ou d’un journal n’est allégué.

La preuve de mise en production devrait associer l’empreinte du certificat, le mode de livraison des SCT, leurs journaux et horodatages, les versions de politique et de liste, les navigateurs réellement testés, les résultats externes, les exceptions, le responsable et le temps disponible pour remplacer. Ce registre transforme un reçu de l’émetteur en décision vérifiable côté utilisateur.

Sources