Vérifier les certificats TLS avec Certificate Transparency : journaux, émetteurs, portée

La validité va au-delà d'une simple date d'expiration

Lorsqu'on vérifie la validité d'un certificat, on se concentre rapidement sur la date d'expiration et la signature. Pour déterminer si une délivrance a été correctement enregistrée et peut être vérifiée, trois axes s'ajoutent : le registre dans lequel la délivrance est consignée ; l'émetteur, c'est-à-dire l'autorité de certification qui a signé ; et la portée – noms de domaine couverts, durée de vie et usage prévu.

Pour les certificats TLS sur le Web, Certificate Transparency (CT) constitue ce registre. CT enregistre et surveille la délivrance des certificats TLS et permet à quiconque de vérifier ces délivrances. Cette inscription n'est pas un détail : Chrome n'accepte que les certificats enregistrés dans un journal CT.

Ces trois axes ont des portées différentes. L'entrée dans le registre atteste du dépôt, pas de l'exploitation en production. L'émetteur indique si l'entité attendue a bien procédé à la délivrance. La portée clarifie si les noms, la durée et l'usage correspondent à l'utilisation prévue. Les sections suivantes les abordent dans cet ordre.

Certificate Transparency : le registre public des certificats TLS

Le cœur du système repose sur des journaux Certificate Transparency accessibles au public, gérés par des organisations telles que Google, Cloudflare ou des autorités de certification commerciales. Lors de la création d'un certificat, un pré-certificat contenant toutes les données pertinentes est généralement inscrit dans l'un de ces journaux et rendu publiquement consultable. Ces journaux sont publics et constitués de hachages chaînés (arbres de Merkle), ce qui les protège contre toute manipulation. Comme les entrées sont visibles par des tiers indépendants, il est impossible de modifier une délivrance après coup sans que cela ne soit remarqué.

La preuve qu'un certificat a été soumis à un journal figure dans le certificat lui-même : le champ de signature permet de vérifier s'il a bien été soumis. Ce champ contient le Signed Certificate Timestamp (SCT), la confirmation du journal accusant réception. Un outil de vérification extrait le SCT et le compare au journal.

En pratique, cela signifie qu'un certificat sans SCT valide provenant d'un journal faisant autorité est inutilisable pour les navigateurs exigeant la conformité CT, même si la signature et la durée de vie sont correctes. Aujourd'hui, on peut considérer que pratiquement tous les certificats serveur délivrés dans le monde avec ancrage dans les navigateurs apparaissent dans ces journaux.

Quels journaux font foi – et quand un SCT ne prouve rien

Il n'existe pas un seul registre, mais un paysage de journaux concurrents et complémentaires. Let's Encrypt soumet tous les certificats délivrés aux journaux CT et exploite elle-même deux journaux publics nommés Oak et Sapling. Oak est intégré aux programmes CT d'Apple et de Google, et l'environnement ACME de production de Let's Encrypt y transmet les certificats. Ce qui compte, ce n'est pas n'importe quel journal, mais celui accepté par le navigateur concerné : dans un article de 2021, la DFN-PKI citait 30 journaux acceptés par Chrome.

Outre les journaux de production, il existe des journaux de test dont les SCT n'ont pas la même valeur. Let's Encrypt précise que les SCT issus de ces journaux de test ne doivent pas être inclus dans des certificats publiquement fiables. Sapling reçoit des certificats provenant à la fois de l'environnement ACME de production et de celui de staging, mais l'environnement de production n'utilise pas les SCT qui en résultent ; Sapling peut être utilisé par d'autres autorités de certification à des fins de test. Il en va de même pour les journaux basés sur Sunlight testés par Let's Encrypt. Twig reste un journal de test et accepte les mêmes autorités de certification que Sapling. Willow et Sycamore acceptent les mêmes autorités de certification qu'Oak et devraient devenir des journaux de production.

Il en découle pour la vérification : un SCT seul ne prouve pas qu'un certificat est publiquement fiable – il peut provenir d'un journal de test. Il faut vérifier si le journal figure sur la liste actuellement acceptée. Les cycles de vie des journaux évoluent ; Let's Encrypt renvoie à sa propre vue d'ensemble pour les informations concernant le cycle de vie de ses journaux. Ceux qui définissent des règles de vérification doivent mettre à jour périodiquement la liste acceptée plutôt que d'utiliser une liste copiée une fois pour toutes.

Journal de production ou de test : tous les SCT ne se valent pas

Interroger plutôt que lire soi-même

Pour des vérifications ponctuelles, un agrégateur suffit. crt.sh interroge continuellement tous les journaux CT pertinents et présente les données de manière facilement exploitable ; le service est exploité par Sectigo, un fournisseur d'autorités de certification. crt.sh propose une API simple pour obtenir les certificats délivrés pour un domaine et fournit les résultats au format JSON sur demande. D'autres offres interrogeant et traitant les journaux CT proviennent de Censys.io, Cloudflare, sslmate, Google et Facebook, certaines étant payantes.

Si l'on ne souhaite pas dépendre d'un service tiers, il est possible d'examiner directement les journaux. Le logiciel certspotter est disponible à cet effet pour une exploitation autonome.

L'exploitation autonome requiert toutefois une conception et des ressources. En raison du volume de certificats serveur délivrés dans le monde, les besoins, notamment en bande passante, peuvent être considérables. Certains journaux augmentent de plusieurs centaines de certificats par seconde, mais ne les distribuent pas toujours à ce rythme, rendant parfois impossible la surveillance continue des certificats présents dans le journal. Les agrégateurs ont aussi leurs limites : crt.sh signale des restrictions sur la taille des résultats. Pour une interrogation unique, un agrégateur suffit ; pour une exploitation continue sur de nombreux domaines, il faut une architecture propre et une capacité de transmission suffisante.

Garder un œil sur son propre domaine

Le registre peut être utilisé par votre propre organisation. Il sert de base de données supplémentaire pour la gestion interne des certificats et permet de détecter rapidement les certificats délivrés par erreur ou de manière frauduleuse.

Il sert également de monitoring centralisé sur les autorités de certification utilisées au sein de l'organisation. Il aide à identifier les certificats supplémentaires liés aux services CDN ou cloud.

Ce dernier point est particulièrement pratique : les certificats ajoutés via un service intermédiaire n'apparaissent souvent pas dans l'inventaire interne, mais bien dans le journal.

La DFN-PKI utilise ce système depuis 2018. Comme pratiquement tous les certificats serveur délivrés dans le monde avec ancrage dans les navigateurs apparaissent dans les journaux, la couverture est élevée pour les certificats publiquement fiables.

La détection des certificats délivrés incorrectement est soumise à une condition : les mécanismes de l'autorité de certification pour l'écriture dans les journaux CT doivent être intacts, c'est-à-dire ne pas avoir été contournés par un attaquant. Si cette condition est remplie, l'interrogation continue des journaux pour vos propres domaines fournit un signal d'alerte précoce, indépendant de la communication propre à l'autorité de certification.

Portée : ce que la vérification ne couvre pas

Les certificats provenant d'autorités de certification internes, qui ne sont pas reconnues par défaut comme fiables dans le navigateur ou le système d'exploitation, ne sont pas enregistrés par Certificate Transparency. Pour de tels certificats – par exemple au sein d'une organisation, entre systèmes ou dans une infrastructure à clés publique (PKI) propre – le registre ne fournit aucune preuve ; il faut alors mettre en place ses propres voies de vérification, comme un aperçu propre des délivrances et une liste de confiance interne.

Une entrée valide dans le journal atteste du dépôt du certificat, pas de son utilisation. On ne peut pas en déduire si le certificat est effectivement servi par un serveur, si la clé privée correspond ou si la configuration est correcte. Seule l'exploitation propre répond à ces questions – via un inventaire des certificats utilisés et un contrôle de la configuration des serveurs.

De plus, l'affirmation du certificat lui-même est limitée : les certificats garantissent généralement que l'on communique avec un domaine spécifique, mais pas avec la bonne entreprise ou la bonne organisation. Un certificat peut être falsifié et le serveur peut se faire passer pour quelqu'un qu'il n'est pas. CT rend les certificats falsifiés ou frauduleux plus faciles à détecter, mais ne remplace pas une vérification de l'organisation derrière un domaine.

Un contrôle supplémentaire est nécessaire pour les certificats provenant d'autorités de certification internes, pour les certificats dont l'utilisation réelle doit être attestée, et chaque fois que l'indication du domaine ne suffit pas pour la transaction commerciale. Dans ces cas, des preuves extérieures au registre s'ajoutent, obtenues directement auprès de l'émetteur ou lors de l'exploitation interne.

Trois étapes de vérification qui doivent s'articuler

Première étape : vérifier l'entrée dans le registre. Le SCT dans le champ de signature doit provenir d'un journal accepté par le navigateur – pas d'un journal de test comme Sapling, Twig ou un journal basé sur Sunlight. Deuxième étape : vérifier l'émetteur. L'autorité de certification signataire doit être celle attendue ; des émetteurs inattendus pour vos propres domaines constituent un signal d'alarme. Troisième étape : vérifier la portée. Les noms de domaine couverts, la durée de vie et l'usage prévu doivent correspondre à l'utilisation planifiée.

Cette séquence peut être intégrée comme routine récurrente dans une gestion existante des certificats : interrogation continue du registre pour vos propres domaines, vérification de l'émetteur et de la portée à chaque nouvelle délivrance et lors de chaque inventaire. Ponctuellement, une interrogation auprès d'un agrégateur comme crt.sh suffit ; pour une exploitation continue, il faut une solution propre avec une bande passante suffisante. Les deux approches donnent le même résultat : une entrée dans le registre qui, combinée à l'émetteur et à la portée, atteste de la validité.