Un outil de recherche de sous-domaines permet de découvrir les noms situés sous un domaine, comme shop.example.com ou help.example.com. Screpy interroge les certificats publics, regroupe les noms répétés et fournit une liste à filtrer, copier ou exporter. Les motifs génériques restent séparés pour ne pas être confondus avec des sites individuels.
Utilisez le résultat comme point de départ d’un inventaire de la présence publique d’un site. Un enregistrement de certificat prouve qu’un nom figure dans cet enregistrement ; il ne confirme pas que ce nom se résout actuellement dans le DNS, sert une page ou apparaît dans Google. Ces questions demandent des vérifications distinctes.
Trouver des sous-domaines dans les certificats
Saisissez un domaine comme example.com, puis choisissez Rechercher les sous-domaines. Vous pouvez aussi coller une URL HTTP ou HTTPS : la recherche utilise son nom d’hôte. Le chemin d’une page ne limite pas la recherche de certificats à cette page. Si vous saisissez shop.example.com, la recherche reste sous cet hôte au lieu de remplacer discrètement votre saisie par example.com.
La recherche lit les champs Common Name et Subject Alternative Name des certificats reçus. La correspondance respecte les étiquettes DNS : help.example.com se trouve sous example.com, contrairement à notexample.com. Les variantes de casse et les occurrences répétées sont réunies dans une seule ligne. Le domaine parent lui-même ne compte pas comme sous-domaine.
Les journaux Certificate Transparency consignent les certificats et précertificats dans des journaux publics où seules des entrées peuvent être ajoutées. Cet historique peut révéler des noms absents des liens ordinaires d’une page d’accueil. L’outil lit les résultats de recherche de certificats ; il n’explore pas les hôtes trouvés, ne devine pas de noms et ne tente aucune connexion à un compte.
Lire les noms, les jokers et les dates des certificats
Les résultats distinguent les noms concrets de sous-domaines des motifs génériques. Cet exemple fictif illustre la différence ; les lignes ne proviennent pas d’une recherche réelle.
| Nom reçu | Type | Ce que vous pouvez en déduire |
|---|---|---|
shop.example.com |
Nom d’hôte | Ce nom précis figure dans un enregistrement de certificat conservé. |
help.example.com |
Nom d’hôte | Un autre nom concret à comparer à votre inventaire. |
*.example.com |
Joker | Le certificat indique un motif, sans énumérer les hôtes couverts. |
Un joker ne prouve pas l’existence de shop, mail ou de toute autre étiquette précise. Screpy compte donc les jokers séparément des sous-domaines concrets. Les noms imbriqués, comme api.shop.example.com, restent visibles si les enregistrements reçus les mentionnent explicitement.
Le nombre d’enregistrements correspond aux identifiants distincts des enregistrements de certificats conservés qui mentionnent un nom. Un hôte peut en avoir beaucoup, car les certificats sont renouvelés ou consignés sous différentes formes. Dix enregistrements pour un nom produisent toujours une seule ligne d’hôte ; ce nombre ne représente ni du trafic, ni dix sites, ni une importance SEO.
Les colonnes de dates indiquent le début de validité le plus ancien et la fin la plus tardive parmi les certificats conservés pour ce nom. Ce ne sont ni sa date de création, ni sa première ou dernière présence en ligne, ni une inspection du certificat actuel. Une expiration future ne prouve pas que l’hôte existe encore ou utilise ce certificat. Une date manquante reste indisponible au lieu d’être estimée.
Comprendre les limites de la découverte passive
Aucun outil fondé sur les certificats ne peut garantir un inventaire complet et actuel d’un domaine. Un nom peut manquer parce qu’il n’a jamais été cité individuellement dans les enregistrements consultés, utilise un certificat privé, est seulement couvert par un joker ou n’est pas encore arrivé dans les données du service de recherche. Inversement, un nom reçu peut appartenir à un service retiré dont le certificat reste dans l’historique.
Cette recherche ne résout pas les noms découverts, n’inspecte pas leurs réponses HTTP, ne vérifie pas leur indexation dans Google et n’établit pas leur propriétaire actuel. Les étiquettes dev et admin sont des noms, pas des preuves de serveur de développement exposé ou de vulnérabilité. Séparez vos conclusions de ce que dit réellement l’enregistrement.
Screpy traite jusqu’à 5 000 enregistrements de certificats reçus et conserve jusqu’à 2 000 noms uniques, motifs génériques compris. Un rapport limité le précise explicitement. Même une réponse traitée avec succès ne couvre que les enregistrements fournis par la source.
Une recherche réussie mais vide signifie qu’aucun nom de sous-domaine correspondant n’a été extrait de ces données. Un délai dépassé ou une source indisponible signifie que la recherche n’a pas pu aboutir. Réessayez une requête échouée plus tard ; une erreur ne confirme pas l’absence de sous-domaines.
Transformer les noms trouvés en audit SEO
Commencez par comparer la liste aux hôtes que vous gérez déjà. Cherchez une boutique distincte, un centre d’aide, un site régional ou une ancienne campagne absents de votre inventaire de travail. Considérez le nom comme une piste à vérifier, pas comme une preuve du rôle du service. Un inventaire utile indique l’hôte, son responsable, sa fonction prévue et la prochaine vérification nécessaire.
Pour les hôtes que vous gérez, suivez cette courte séquence :
- Vérifiez la réponse. Utilisez le vérificateur de statuts HTTP en lot sur les URL HTTP ou HTTPS précises à auditer. Il distingue une réponse correcte, une redirection et une erreur ; la recherche de certificats ne le fait pas.
- Confirmez la visibilité souhaitée. Un article public et un portail client privé ont des exigences différentes. Examinez les directives pertinentes avec le vérificateur noindex plutôt que de supposer que chaque hôte découvert doit se positionner.
- Examinez les destinations dupliquées. Si un hôte public sert du contenu disponible ailleurs, le vérificateur de balises canonical peut examiner l’URL canonique déclarée. Un nom seul ne renseigne ni sur les doublons ni sur l’URL canonique choisie par Google.
- Vérifiez le bon sitemap. Utilisez le vérificateur de sitemap pour le site ou sitemap réellement concerné. La liste de sous-domaines n’est pas une liste de toutes les pages et la présence dans un sitemap ne garantit pas l’indexation.
Conservez un nom retiré dans l’inventaire jusqu’à confirmation de sa configuration DNS et de service actuelle dans les systèmes que vous contrôlez. Sa présence dans l’historique des certificats justifie une investigation, pas une suppression automatique ni une explication d’un changement de classement.
Exporter la liste et préserver son contexte
Utilisez le filtre de noms pour cibler un hôte ou une partie de son nom, et le sélecteur de type pour séparer les hôtes concrets des motifs génériques. Le tableau affiche jusqu’à 50 lignes par page. La copie et l’export CSV portent sur tous les noms correspondant aux filtres actuels, pas seulement sur la page visible. Identifiez toujours les lignes génériques comme des motifs dans votre inventaire.
Téléchargez le JSON pour obtenir le rapport reçu dans son ensemble, avec les enregistrements de certificats conservés derrière les noms. Il comprend le domaine recherché, l’heure de la recherche, les limites de couverture et les indicateurs précisant que DNS et HTTP n’ont pas été vérifiés. Ces champs aident une autre personne à comprendre ce que représente la liste exportée.
Conservez le contexte de la recherche avec vos conclusions. Un rapport partiel, un ancien certificat et une réponse en direct sont des preuves différentes. Une nouvelle recherche peut produire d’autres résultats lorsque la source évolue ; l’export est un instantané de cette réponse, pas une surveillance continue.