Audit des logs de transparence des certificats TLS

Que fait Audit des logs de transparence des certificats TLS ?

Quand l'utiliser

• Surveiller les domaines possédés pour détecter toute émission de certificat non autorisée ou inattendue par des autorités de certification inconnues
• Découvrir des sous-domaines et services cachés via les certificats enregistrés dans les logs CT publics
• Détecter les infrastructures de phishing qui utilisent des certificats de domaines imitant les vôtres (typosquatting, attaques homographes)
• Auditer la conformité des autorités de certification en vérifiant que tous les certificats émis apparaissent dans les logs CT comme l'exigent les politiques des navigateurs
• Mettre en place une surveillance continue des certificats dans un pipeline d'opérations de sécurité, avec alertes pour les nouvelles émissions

À ne pas utiliser pour attaquer ou perturber les autorités de certification, pour scraper les logs CT en violation des limites de débit ou des conditions d'utilisation, ou comme seule méthode d'énumération de sous-domaines sans corroborer les résultats par une vérification DNS.

Prérequis

• Python 3.10+ avec les bibliothèques requests, cryptography et pyOpenSSL installées
• Accès réseau à crt.sh (HTTPS) et aux serveurs de logs CT publics
• Une liste de domaines à surveiller (domaines possédés, variations de marque, candidats au typosquatting)
• Identifiants SMTP ou URL de webhook pour les alertes lors de nouvelles découvertes de certificats
• Compréhension de base de la structure des certificats X.509 et de la validation de la chaîne de certificats TLS

Workflow

Étape 1 : Inventaire des domaines et état de référence

Construire l'inventaire initial des certificats pour les domaines surveillés :

• Définir le périmètre de surveillance : Lister tous les domaines racines possédés, les noms de marque enregistrés et les filiales connues. Inclure les motifs génériques (%.example.com) pour une couverture complète des sous-domaines.
• Interroger crt.sh pour les certificats historiques : Utiliser l'API JSON de crt.sh pour récupérer tous les certificats connus pour chaque domaine. Le point d'accès https://crt.sh/?q=%.example.com&output=json renvoie les certificats correspondant au motif générique, avec des champs tels que issuer_ca_id, issuer_name, common_name, name_value, not_before, not_after et serial_number.
• Construire une base de données de référence : Stocker l'ensemble initial de certificats dans une base de données SQLite locale avec des colonnes pour l'ID du certificat, le domaine, l'émetteur, les dates de validité, les SAN (Subject Alternative Names) et l'horodatage de première observation. Cette référence permet d'éviter les alertes sur les certificats déjà connus.
• Identifier les AC autorisées : À partir de la référence, extraire l'ensemble des autorités de certification ayant légitimement émis des certificats pour vos domaines. Toute future émission provenant d'une AC non présente dans cet ensemble déclenche une alerte de haute priorité.
• Cartographier les sous-domaines : Extraire tous les sous-domaines uniques du champ name_value de tous les certificats pour construire un inventaire initial des sous-domaines.

Étape 2 : Surveillance continue des logs CT

Mettre en place une surveillance continue des nouvelles émissions de certificats :

• Interroger crt.sh périodiquement : Interroger l'API crt.sh à intervalles réguliers (toutes les 15 à 60 minutes) pour les nouveaux certificats. Utiliser le paramètre exclude=expired pour se concentrer sur les certificats actuellement valides. Comparer les résultats avec la base de données de référence pour identifier les nouvelles entrées.
• Analyser les détails des certificats : Pour chaque nouveau certificat, extraire la liste complète des SAN, la chaîne d'émetteurs, la période de validité, le type et la taille de la clé, les détails SCT (Signed Certificate Timestamp) du log CT et l'empreinte du certificat (SHA-256).
• Détecter les précertificats : Les logs CT incluent des précertificats (certificats empoisonnés soumis avant l'émission finale). Les suivre comme alertes précoces, car ils indiquent qu'un certificat est sur le point d'être émis mais peut ne pas encore être actif.
• Surveiller les Signed Tree Heads (STH) des logs CT : Pour une surveillance avancée, interroger directement les serveurs de logs CT pour récupérer le dernier STH et vérifier les preuves de cohérence entre les arbres consécutifs. Une incohérence indique un comportement anormal du log (attaque split-view).
• Respect des limites de débit : Respecter les limites de débit de crt.sh en espaçant les requêtes et en mettant en cache les réponses. Implémenter un backoff exponentiel en cas de réponse HTTP 429. Pour une surveillance à volume élevé, envisager d'interroger directement l'interface PostgreSQL de crt.sh à l'adresse crt.sh:5432.
• Alternative via flux Atom/RSS : S'abonner au flux Atom de crt.sh pour une surveillance plus légère : https://crt.sh/atom?q=%25.example.com fournit des notifications en temps réel des nouvelles entrées du log.

Étape 3 : Découverte de sous-domaines via les données CT

Extraire et valider les sous-domaines trouvés dans les données de transparence des certificats :

• Expansion des motifs génériques : Les certificats avec des SAN génériques (*.dev.example.com) révèlent l'existence de sous-domaines qui peuvent ne pas figurer dans les fichiers de zone DNS. Enregistrer le domaine parent comme cible pour une énumération ultérieure.
• Exploitation des certificats historiques : Interroger crt.sh sans le paramètre exclude=expired pour trouver des sous-domaines à partir de certificats expirés qui peuvent encore résoudre dans le DNS. Ces certificats représentent une infrastructure historique qui pourrait être vulnérable à une prise de contrôle de sous-domaine.
• Validation DNS : Pour chaque sous-domaine découvert, effectuer une résolution DNS (enregistrements A, AAAA, CNAME) pour déterminer si le sous-domaine est actuellement actif. Recouper avec les plages d'adresses IP connues pour identifier les services informatiques fantômes ou non autorisés.
• Détection de typosquatting : Générer des permutations du domaine surveillé (bitsquatting, homographe, insertion, omission, transposition, remplacement par touches adjacentes) et interroger les logs CT pour les certificats émis pour ces variations. Les certificats pour les domaines typosquattés indiquent fortement une infrastructure de phishing.
• Déduplication et enrichissement : Normaliser les sous-domaines découverts (minuscules, suppression des points finaux), dédupliquer et enrichir avec les données WHOIS, la géolocalisation IP et les en-têtes de réponse HTTP pour prioriser les investigations.

Étape 4 : Alertes sur les émissions de certificats

Configurer les règles d'alerte pour les événements de certificats pertinents pour la sécurité :

• Alerte AC non autorisée : Déclencher lorsqu'un certificat est émis par une AC ne figurant pas dans la liste des AC autorisées. Il s'agit de l'alerte de plus haute priorité car elle peut indiquer un détournement de domaine, un détournement BGP pour la validation de domaine ou une AC compromise.
• Alerte nouveau sous-domaine : Déclencher lorsqu'un certificat contient un SAN avec un sous-domaine jamais vu auparavant. Cela permet de détecter les déploiements informatiques fantômes et les services non autorisés.
• Alerte certificat générique : Déclencher sur toute nouvelle émission de certificat générique, car les certificats génériques ont un impact plus large en cas de compromission et leur émission doit être strictement contrôlée.
• Anomalie de certificat à courte durée de vie : Alerter lorsque les certificats ont des périodes de validité anormalement courtes (moins de 24 heures) qui s'écartent du cycle de vie normal des certificats de l'organisation, car cela peut indiquer un abus de Let's Encrypt ou une infrastructure de phishing automatisée.
• Avertissement d'expiration : Alerter lorsque les certificats pour les services critiques approchent de l'expiration (30, 14, 7 jours) en fonction du champ not_after des données du log CT.
• Livraison des alertes : Envoyer les alertes par email (SMTP), webhook Slack, PagerDuty, ou écrire dans un format de log JSON compatible SIEM pour une intégration avec la surveillance de sécurité existante.

Étape 5 : Vérification de l'intégrité des logs CT et rapports

Vérifier l'intégrité des logs et produire des preuves de conformité :

• Surveillance des Signed Tree Heads (STH) : Récupérer le dernier STH de chaque log CT surveillé via le point d'accès get-sth. Le STH contient la taille de l'arbre et un horodatage signé. Vérifier la signature à l'aide de la clé publique du log.
• Vérification de la preuve de cohérence : Entre deux récupérations consécutives du STH, demander une preuve de cohérence via get-sth-consistency pour vérifier que le log reste en mode "append-only" et qu'aucune entrée n'a été modifiée ou supprimée.
• Rapport d'inventaire des certificats : Produire un inventaire complet de tous les certificats émis pour les domaines surveillés, regroupés par émetteur, avec le statut de validité et les mesures de force des clés.
• Analyse de la diversité des AC : Rapporter combien d'AC différentes émettent des certificats pour l'organisation, en identifiant les opportunités de consolidation et les points uniques de défaillance.
• Preuves de conformité : Pour les organisations soumises à PCI-DSS, SOC 2 ou des cadres similaires, les logs de surveillance CT fournissent des preuves de la gestion du cycle de vie des certificats et des capacités de détection des émissions non autorisées.

Concepts clés

Terme	Définition
Transparence des certificats (CT)	Un cadre ouvert (RFC 6962) obligeant les autorités de certification à enregistrer tous les certificats émis dans des logs publics vérifiables et en "append-only", permettant aux propriétaires de domaines de détecter les émissions non autorisées
Signed Certificate Timestamp (SCT)	Une promesse d'un log CT qu'un certificat sera inclus dans le délai maximal de fusion (généralement 24 heures) ; les navigateurs exigent des SCT de plusieurs logs avant de faire confiance à un certificat
Arbre de Merkle	La structure de données cryptographique utilisée par les logs CT où les nœuds feuilles sont des hachages de certificats et les nœuds parents sont des hachages de leurs enfants, permettant des preuves de cohérence et d'inclusion efficaces
Précertificat	Un certificat soumis aux logs CT avant l'émission finale, contenant une extension poison (OID 1.3.6.1.4.1.11129.2.4.3) qui l'empêche d'être utilisé pour TLS mais réserve sa place dans le log
crt.sh	Un service web gratuit exploité par Sectigo qui agrège les certificats de tous les principaux logs CT dans une base de données PostgreSQL consultable, offrant un accès web et API
Prise de contrôle de sous-domaine	Une vulnérabilité où l'enregistrement DNS d'un sous-domaine pointe vers un service décommissionné (fournisseur cloud, CDN) qu'un attaquant peut récupérer, rendu détectable via des certificats CT expirés
Délai maximal de fusion (MMD)	Le temps maximum (généralement 24 heures) dont dispose un log CT pour incorporer un certificat soumis dans son arbre de Merkle après avoir renvoyé un SCT
Enregistrement CAA	Enregistrement DNS de délégation d'autorité de certification qui spécifie quelles AC sont autorisées à émettre des certificats pour un domaine ; la surveillance CT détecte les violations de la politique CAA

Outils et systèmes

• crt.sh : Agrégateur principal de logs CT offrant un accès API JSON à https://crt.sh/?q=<query>&output=json avec prise en charge des requêtes génériques, du filtrage par identité et de la récupération des détails des certificats
• ct-woodpecker : Outil open-source de surveillance des logs CT de Let's Encrypt qui s'intègre à Prometheus et Grafana pour la surveillance opérationnelle de la santé et de la cohérence des logs
• certspotter : Moniteur de logs CT de SSLMate qui surveille les certificats nouvellement émis et envoie des notifications ; disponible en service hébergé ou auto-hébergé
• Google Argon / Xenon / Icarus : Logs CT exploités par Google parmi les plus utilisés, interrogeables via l'API RFC 6962 à leurs URLs de log respectives
• OpenSSL : Outil en ligne de commande pour analyser les détails des certificats, vérifier les chaînes et extraire les listes SAN des certificats récupérés via la surveillance CT

Scénarios courants

Scénario : Détection d'une émission non autorisée de certificat pour une entreprise de services financiers

Contexte : Une banque surveille son domaine principal (bank.example.com) et découvre via les logs CT qu'un certificat a été émis par une AC qu'elle n'a jamais utilisée, couvrant secure-login.bank.example.com -- un sous-domaine qui n'existe pas dans son DNS.

Approche :

1. L'agent de surveillance CT détecte un nouveau certificat de "FreeSSL CA" pour secure-login.bank.example.com dans les résultats crt.sh, qui n'est pas dans la liste des AC autorisées (DigiCert, Sectigo)
2. L'alerte se déclenche en tant qu'AC non autorisée + nouveau sous-domaine, remontant à l'équipe de sécurité dans les 15 minutes suivant l'entrée dans le log CT
3. Enquêter sur le certificat : extraire la clé publique, vérifier si le domaine a été validé via le défi HTTP-01 ou DNS-01, interroger WHOIS pour l'organisation émettrice
4. La recherche DNS pour secure-login.bank.example.com révèle qu'il résout une adresse IP dans un fournisseur d'hébergement non utilisé par la banque -- confirmant qu'il s'agit d'une infrastructure d'attaquant
5. Lancer la réponse aux incidents : demander la révocation du certificat à FreeSSL CA, déposer un rapport d'abus de domaine, ajouter l'IP aux listes de blocage et notifier l'équipe anti-phishing
6. Implémenter des enregistrements DNS CAA (bank.example.com. CAA 0 issue "digicert.com") pour empêcher les AC non autorisées d'émettre de futurs certificats

Pièges :

• Ne pas surveiller les motifs génériques (%.bank.example.com) et manquer les certificats pour les sous-domaines
• Ignorer les précertificats qui apparaissent dans les logs CT avant l'émission réelle du certificat, perdant ainsi l'avantage de l'alerte précoce
• Ne pas vérifier que les enregistrements CAA sont correctement configurés sur tous les domaines après un incident
• Suralerter sur les renouvellements légitimes de certificats parce que la base de données de référence n'a pas été mise à jour après des changements autorisés

Scénario : Cartographie de la surface d'attaque via la découverte de sous-domaines dans les logs CT

Contexte : Un testeur d'intrusion utilise les logs CT comme première phase de reconnaissance externe pour cartographier les services exposés sur Internet de l'organisation cible avant l'analyse active.

Approche :

1. Interroger crt.sh pour %.target.com et tous les domaines de filiales connus, collectant 2 400 certificats uniques couvrant 8 ans
2. Extraire 347 sous-domaines uniques des champs SAN de tous les certificats, y compris ceux expirés
3. Résoudre DNS pour les 347 sous-domaines, trouvant 189 actuellement actifs avec des enregistrements A/AAAA
4. Identifier 12 sous-domaines pointant vers des services cloud décommissionnés (CNAME vers des buckets S3, points d'accès Azure) qui sont candidats à une prise de contrôle de sous-domaine
5. Découvrir staging-api.target.com et dev-portal.target.com qui ne sont pas dans le périmètre documenté de la cible mais sont joignables et exécutent des versions logicielles plus anciennes
6. Présenter les résultats à l'organisation cible en montrant l'écart entre leur inventaire d'actifs connu et la surface d'attaque dérivée des CT

Pièges :

• Supposer que tous les sous-domaines découverts par CT sont dans le périmètre sans confirmer avec le propriétaire de l'actif
• Ne pas vérifier les réponses DNS génériques qui donnent l'impression que des sous-domaines existent alors qu'ils résolvent vers un attrape-tout
• Se fier uniquement aux données CT sans recouper avec les bases de données DNS passives pour une couverture complète

Format de sortie

## Rapport de surveillance des logs CT

**Domaine** : example.com
**Période de surveillance** : 2026-03-01 à 2026-03-19
**Total des certificats suivis** : 142
**Nouveaux certificats détectés** : 7
**Alertes générées** : 2

### Alerte : Émission par AC non autorisée
- **Gravité** : Critique
- **CN du certificat** : secure-login.example.com
- **SAN** : secure-login.example.com,
…

[La suite est tronquée pour la traduction]

Conclusion

L'audit des logs de transparence des certificats est un pilier de la posture de sécurité moderne. Il permet de détecter les émissions frauduleuses, de cartographier la surface d'attaque des sous-domaines et de garantir la conformité. En intégrant cette compétence dans vos opérations de sécurité, vous transformez les logs CT en un capteur proactif contre les menaces liées aux certificats.