Journaux Certificate Transparency : ce qu'ils révèlent sur vos domaines
Certificate Transparency (CT) est un système de journaux en ajout seul qui enregistrent les certificats TLS au moment où les autorités de certification les émettent. N'importe qui peut lire ces journaux. Pour votre entreprise, cela signifie 2 choses : les journaux montrent à tout le monde pour quels noms d'hôtes vous avez des certificats, et ils vous permettent de repérer un certificat pour votre domaine que personne de votre côté n'a demandé.
Le protocole a été décrit pour la première fois dans la RFC 6962 (juin 2013) et mis à jour en version 2.0 dans la RFC 9162 (décembre 2021). Ce sont deux RFC expérimentales, mais les navigateurs s'appuient sur CT dans la pratique : Chrome exige que les certificats TLS reconnus soient conformes à CT, et Apple applique sa propre politique CT sur ses plateformes.
Donc, si un navigateur fait confiance à un certificat pour yourcompany.com, il existe presque certainement une entrée correspondante dans un journal.
Ce que les journaux révèlent sur votre entreprise
Une entrée CT contient les noms couverts par le certificat, l'autorité émettrice et les dates de validité. Mises bout à bout, les entrées de votre domaine montrent :
- Vos sous-domaines.
vpn.yourcompany.com,jira.yourcompany.com,staging-api.yourcompany.com: chaque nom qui a eu un jour son propre certificat. - Vos fournisseurs. Les émetteurs et les conventions de nommage laissent souvent deviner quelles plateformes d'hébergement, de messagerie ou SaaS vous utilisez.
- Votre historique. Les anciennes entrées restent dans le journal, si bien que les noms de projets arrêtés depuis des années restent visibles.
- Les nouveaux certificats dès leur apparition. Une nouvelle entrée pour un nom que vous ne reconnaissez pas, ou d'une autorité que vous n'utilisez pas, mérite une question.
Rien de tout cela n'est un défaut de CT. Le but du système est précisément que les certificats émis à tort ne puissent pas rester cachés. La conséquence, c'est que votre liste de noms d'hôtes n'est pas privée : mieux vaut donc la lire avant les autres.
Comment consulter les journaux vous-même
Le plus simple est crt.sh, une interface de recherche dans les journaux CT. Saisissez votre domaine, ou utilisez % comme joker pour inclure tous les sous-domaines :
https://crt.sh/?q=%25.yourcompany.com
Pour obtenir une liste exploitable, ajoutez &output=json :
curl -s 'https://crt.sh/?q=%25.yourcompany.com&output=json' \
| jq -r '.[].name_value' | sort -u
En lisant les résultats, cherchez :
- Les noms que personne ne reconnaît. Chacun doit correspondre à un système dont le responsable est connu.
- Les noms de test et de préproduction comme
dev,test,old,beta. Ils pointent souvent vers des serveurs de préproduction oubliés. - Les noms qui ne se résolvent plus ou qui pointent vers une plateforme que vous avez quittée. Vérifiez-les pour détecter un DNS orphelin et une prise de contrôle de sous-domaine.
- Les émetteurs inattendus. Un certificat émis par une autorité que vous n'avez jamais utilisée mérite une vérification avec l'équipe qui gère votre DNS et votre hébergement.
- Les dates récentes inexpliquées. Un certificat tout neuf pour votre nom d'hôte de connexion principal, que personne n'a demandé, est le cas le plus urgent.
Gardez à l'esprit que les certificats génériques (*.yourcompany.com) ne listent pas les sous-domaines individuels : les journaux vous montrent beaucoup, mais pas tout.
Limiter qui peut émettre : l'enregistrement CAA
Vous pouvez indiquer aux autorités de certification lesquelles d'entre elles peuvent émettre pour votre domaine grâce à un enregistrement CAA, défini dans la RFC 8659. Les autorités le vérifient avant d'émettre. Une configuration typique :
yourcompany.com. CAA 0 issue "letsencrypt.org"
yourcompany.com. CAA 0 issuewild ";"
yourcompany.com. CAA 0 iodef "mailto:security@yourcompany.com"
Cela autorise une seule autorité, interdit les certificats génériques et fournit une adresse pour les signalements. CAA ne remplace pas CT : il réduit ce qui peut être émis, tandis que CT vous montre ce qui l'a réellement été.
Des certificats plus courts, des journaux plus chargés
En vertu du vote SC-081 du CA/Browser Forum, désormais intégré aux Baseline Requirements, la durée de validité maximale des certificats TLS reconnus est de 200 jours pour les certificats émis à partir du 15 mars 2026, de 100 jours à partir du 15 mars 2027 et, à partir du 15 mars 2029, de seulement 47. Les renouvellements seront plus fréquents et le plus souvent automatisés, donc vos domaines produiront davantage d'entrées CT. La lecture manuelle devient moins praticable et une référence claire des certificats « attendus » devient plus utile. Pour le volet renouvellement de ce changement, voir pourquoi l'expiration des certificats fait encore tomber des sites web.
Que faire si vous trouvez quelque chose d'inattendu
- Identifiez le responsable. Demandez à l'informatique, au marketing et à vos agences s'ils ont demandé le certificat.
- Si personne ne l'a fait, contactez l'autorité émettrice. Chacune publie une procédure pour signaler un certificat émis à tort et demander sa révocation.
- Vérifiez votre DNS et votre registrar. Un certificat inattendu peut faire suite à une modification DNS : passez en revue les points de notre article sur les changements de serveurs de noms et de registrar.
- Ajoutez ou resserrez CAA pour que la même autorité ne puisse plus émettre sans votre accord.
Une courte liste de contrôle
- Cherchez
%.yourcompany.comsur crt.sh et enregistrez la liste des noms. - Associez chaque nom à un système et à un responsable.
- Supprimez ou corrigez les noms qui ne pointent vers rien.
- Publiez un enregistrement CAA qui nomme les autorités que vous utilisez.
- Examinez les nouvelles entrées régulièrement, pas une fois par an.
La place de Datahorses
Datahorses surveille votre entreprise depuis l'extérieur chaque jour, et Certificate Transparency fait partie de ce qu'il lit pour vous : nouveaux certificats émis pour vos domaines, nouveaux sous-domaines et enregistrements CAA censés les limiter. Nous n'entrons pas dans vos systèmes et n'avons besoin d'aucun accès. Quand quelque chose semble anormal, vous recevez le constat avec des étapes claires, comme décrit dans ce qui se passe quand nous trouvons quelque chose. La liste complète de ce que nous surveillons figure sur la page d'accueil.
Plus d’articles
Fausses pages de connexion à votre marque : comment elles apparaissent et comment les faire supprimer
Une copie de votre page de connexion sur un domaine similaire peut collecter les mots de passe de vos clients. Voici comment ces pages apparaissent, comment les repérer tôt et les faire supprimer.
Surveillance de la surface d'attaque ou EDR et XDR : un complément, pas un concurrent
L'EDR et le XDR regardent vers l'intérieur : postes, connexions, processus. La surveillance de la surface d'attaque externe regarde votre entreprise depuis Internet. Voici pourquoi il vous faut les deux.
PHP2Shell : quelles versions de PHP sont corrigées et comment contrôler la vôtre
Le projet PHP a corrigé 2 failles critiques le 21 octobre 2026. Voici les versions qui contiennent le correctif, comment voir ce qu'annonce votre serveur et quoi demander à votre hébergeur.