Recherche de transparence des certificats
Chaque certificat de confiance publique jamais émis pour un domaine est inscrit dans des journaux publics — cette recherche les relit pour vous. Saisissez un domaine et voyez ce que crt.sh a enregistré pour lui et ses sous-domaines : qui a émis chaque certificat, quels noms il couvre et quand il était valide. C’est l’audit qui trouve les certificats que vous avez oubliés — et ceux que vous n’avez jamais demandés.
Vous voulez que ce soit surveillé en continu ? Surveillez-le gratuitement avec myeventwatch — alertes d’expiration et de panne, sans carte.
Ce que mesure la recherche
La transparence des certificats transforme l’émission de certificats d’une transaction privée en un enregistrement public. Quand une autorité de certification émet un certificat pour un nom public, elle soumet le certificat à plusieurs journaux CT, et les navigateurs refusent les certificats qui ne sont pas journalisés. L’effet secondaire est un cadeau pour les défenseurs : l’historique complet d’émission de chaque domaine est là, en public, en attente d’être lu. La page appelle GET /api/check/cert-search sur le serveur de sysosx, qui fait une seule requête à crt.sh — l’index public de ces journaux — pour le domaine et tout ce qui se trouve dessous, normalise la réponse, la trie du plus récent au plus ancien et la met en cache pendant une heure. Jusqu’à 200 entrées sont affichées ; un domaine qui en a davantage reçoit un avis de troncature et le total réel, jamais une coupure silencieuse.
Lisez le résultat comme un inventaire, pas comme un verdict. La question productive pour chaque entrée est « lequel de nos systèmes a demandé cela ? ». Les infrastructures modernes émettent des certificats depuis plus d’endroits que leurs propriétaires ne le pensent : l’hébergeur web, le CDN, le fournisseur de messagerie, le créateur de site de l’équipe marketing, un ingress Kubernetes sur un cluster que quelqu’un a monté l’an dernier. La plupart sont légitimes et plusieurs seront de toute façon une nouvelle pour vous — ce qui est utile en soi, car un inventaire de certificats que vous n’avez jamais vu ne peut faire partie du plan de renouvellement ou de révocation de personne. Les entrées qui comptent le plus sont celles que personne ne peut associer à un système : un émetteur inconnu, un sous-domaine inconnu, une date d’émission sans aucun déploiement à proximité. Elles sont rares, et ce sont exactement celles que CT a été conçu pour faire remonter.
Trois outils, trois questions
Cette recherche répond à « qu’est-ce qui a jamais été émis ? ». Le vérificateur SSL répond à « qu’est-ce que le serveur présente en ce moment même ? » avec une poignée de main en direct — la seule façon de savoir ce que les visiteurs reçoivent réellement. Le noteur SSL répond à « dans quelle mesure le TLS de ce serveur est-il bien configuré ? » — versions de protocole, confidentialité persistante, HSTS, avec une note en lettres. Et l’analyseur de certificats SSL côté navigateur lit un fichier de certificat que vous détenez déjà. Un renouvellement qui existe dans les journaux mais n’a jamais été déployé apparaît ici et pas dans le vérificateur ; un serveur présentant un ancien certificat apparaît dans le vérificateur et pas ici. Quand ils ne sont pas d’accord, chacun dit sa propre vérité — utilisez celui qui correspond à votre question.
Questions fréquentes
Qu’est-ce que la transparence des certificats, en un paragraphe ?
Depuis 2018, les navigateurs exigent que les certificats de confiance publique soient publiés dans des journaux de transparence des certificats (CT) — des listes publiques, en ajout seul, de chaque certificat qu’une CA émet. Les journaux existent pour que les émissions abusives ne puissent pas se cacher : si un certificat pour votre domaine apparaît que vous n’avez jamais demandé, il est visible par quiconque regarde, vous compris. Cet outil regarde en votre nom, via crt.sh, l’index public le plus connu de ces journaux.
En quoi est-ce différent du vérificateur SSL et du noteur SSL ?
Trois questions différentes. Le vérificateur SSL demande quel certificat un serveur présente en ce moment même, dans une poignée de main en direct. Le noteur SSL audite la façon dont le TLS de ce serveur est configuré — protocoles, suites de chiffrement, HSTS — et le note. Cette recherche demande ce qui a jamais été émis pour le domaine, selon les journaux publics. Elle peut faire remonter des certificats que les outils en direct ne peuvent pas : des certificats de préproduction oubliés, des certificats de CA que votre organisation n’utilise plus, et — le cas pour lequel CT a été créé — des certificats que personne dans votre équipe n’a demandés du tout.
Pourquoi cela s’exécute-t-il depuis le serveur plutôt que dans mon navigateur ?
L’analyseur de certificats côté navigateur de ce site propose lui aussi une consultation crt.sh, et dit clairement que son fonctionnement dépend des en-têtes inter-origines de crt.sh — un navigateur ne peut lire que ce qu’un service tiers l’autorise à lire. Une requête côté serveur n’a aucune politique inter-origines à satisfaire, donc la recherche ici fonctionne de la même façon à chaque fois. L’échange est celui de toujours : le domaine que vous saisissez est envoyé à crt.sh depuis le serveur de sysosx (et, pendant une heure, la réponse est mise en cache), ce que la page énonce au lieu de le cacher.
Je vois des certificats que je ne reconnais pas. Dois-je paniquer ?
Pas encore. La plupart des entrées inconnues sont banales : un hébergeur ou un CDN émettant en votre nom (Cloudflare, un répartiteur de charge, un créateur de site web), une autorité de certification que votre organisation a abandonnée, ou un système de renouvellement automatique que quelqu’un a configuré puis oublié. Parcourez la liste par émetteur et par date et associez chaque entrée à un système que vous exploitez ou à un fournisseur que vous payez. La panique — enfin, l’enquête urgente — est pour le reste : un certificat d’une CA que personne n’utilise, couvrant des noms que personne n’exploite, émis à un moment où personne n’a rien déployé. C’est soit un coin oublié de votre propre parc qui mérite d’être documenté, soit l’émission abusive que CT existe pour attraper, et elle doit être traquée jusqu’à être expliquée.
Pourquoi le résultat est-il mis en cache pendant une heure, et pourquoi la recherche peut-elle échouer ?
Parce que crt.sh est un service public gratuit, notoirement lent sous charge, et que l’historique des certificats change en jours plutôt qu’en minutes — une heure de cache ne coûte rien en fraîcheur et évite que cet outil ajoute à la charge de crt.sh : au plus une requête amont par domaine et par heure. Quand crt.sh est en panne ou trop lent, la recherche le dit avec une erreur explicite au lieu de renvoyer une liste vide, car « aucun certificat trouvé » et « la recherche dans les journaux a échoué » sont des conclusions opposées et une seule des deux est vraie.