Découvrir les certificats fantômes : un playbook d'inventaire en 30 jours

Pourquoi les certificats fantômes existent (et ce n'est pas toujours du shadow IT)

Chaque équipe PKI qui a mené un projet d'inventaire de certificats sérieux arrive au même constat : le nombre est trois à dix fois supérieur à ce que suggère la base centrale de la CA.

Le réflexe est de blâmer le shadow IT, mais la plupart des certificats fantômes ne sont pas le produit d'un contournement malveillant. Ce sont les résidus d'un travail d'ingénierie normal effectué sous pression. Un responsable PKI sénior qui lance un premier audit de certificats devrait s'attendre à six sources récurrentes plutôt qu'à une seule.

La première source est le certificat auto-signé d'urgence. Un incident de production à 2 h du matin, un load balancer qui ne démarre pas sans certificat serveur, une équipe qui n'a pas ses identifiants ACME sous la main. Quelqu'un lance openssl req -x509 -newkey rsa:2048 -nodes -keyout key.pem -out cert.pem -days 365, redémarre le service et oublie d'ouvrir un ticket. Le certificat apparaît sur le réseau le lendemain matin, signé par un CN qui n'existe nulle part dans la hiérarchie de CA d'entreprise. Six mois plus tard, il est toujours là.

La deuxième source est le développeur qui a oublié de renouveler. Un cluster de test reçoit un certificat DV d'un an d'une CA publique, le développeur quitte l'entreprise, le certificat expire, quelqu'un le réémet via un autre canal d'approvisionnement, et la trace du cycle de vie du certificat est perdue.

La troisième source est le scanner tiers qui crée des certificats par effet de bord. Les plateformes d'observabilité SaaS, les flux d'onboarding CDN et les ingress controllers émettent des certificats automatiquement dès qu'un domaine est ajouté.

La quatrième source est l'équipement fourni par un fournisseur : baies de stockage, pare-feu, passerelles de visioconférence et automates HVAC qui sortent d'usine avec des certificats auto-signés que les équipes d'exploitation remplacent de manière inégale, voire pas du tout.

La cinquième source est l'auto-émission d'ingress Kubernetes via cert-manager, où une seule annotation Ingress déclenche une commande ACME que l'équipe PKI ne voit jamais.

La sixième source est la plus embarrassante opérationnellement : les équipes internes qui ont acheté des certificats CA externes sur une carte d'entreprise parce que le délai de la PKI centrale était trop long.

Aucune de ces sources ne reflète une mauvaise foi. Elles reflètent une friction de processus. Un playbook réussi à 30 jours les traite comme des éléments de preuve, pas comme des coupables, et utilise l'inventaire pour corriger le flux sous-jacent décrit dans le guide des certificats fantômes et de la visibilité.

Jours 1 à 10 : découverte basée réseau

Les dix premiers jours consistent à voir ce qu'un attaquant verrait. La découverte de certificats basée réseau trouve chaque point de terminaison qui répond à une sonde TLS et enregistre la chaîne qu'il présente. Elle ne nécessite aucun identifiant interne, ce qui signifie qu'elle peut tourner en parallèle du travail politique d'obtention des accès cloud et Kubernetes. L'objectif au jour 10 est une liste dédupliquée de tous les certificats observables depuis l'extérieur, tous ceux observables depuis le réseau d'entreprise interne, et un premier écart entre les deux.

Définissez le périmètre avant de scanner. Extrayez chaque plage IPv4 et IPv6 routable de l'IPAM, chaque zone DNS publique du registrar, chaque VIP de load balancer des comptes cloud, chaque /16 interne utilisé pour la production, le staging et les sous-réseaux développeurs. Écrivez le périmètre sous forme de trois fichiers CSV : external_ranges.csv, internal_ranges.csv, dns_zones.csv.

Tout ce qui est en dehors de ces fichiers est hors périmètre pour les 30 premiers jours, et vous devez résister à l'envie d'élargir en cours de projet. Le scope creep est la première raison pour laquelle les projets d'inventaire ratent leur échéance.

Mettez la stack de scan debout au jour 2. testssl.sh est l'outil de fond pour l'énumération approfondie d'un seul hôte : suites de chiffrement, versions de protocole, chaîne de certificat, OCSP stapling, HSTS. Lancez testssl.sh --json-pretty --severity LOW host.example.com:443 et la sortie tombe dans un fichier structuré que le parseur peut consommer.

sslyze est plus rapide en largeur : sslyze --regular --json_out results.json target1.example.com:443 target2.example.com:8443. sslscan est le plus léger, utile pour balayer des milliers d'hôtes en une heure.

Encapsulez-les dans un pool de workers avec un timeout de 30 secondes par hôte. Attendez-vous à ce que 5 à 15 % des hôtes expirent au premier passage ; relancez-les en série avec des timeouts étendus au jour 4. Un environnement de 10 000 hôtes se scanne en environ six heures sur un hôte de scan 16 cœurs avec un parallélisme réglé à 64.

Distinguez explicitement le périmètre authentifié du non authentifié. Le scan non authentifié attrape tout ce qui est joignable sur les ports TLS standard : 443, 465, 636, 853, 989, 990, 993, 995, 5061, 8443. Le scan authentifié exige des identifiants et trouve les interfaces de management cachées derrière les VPN et bastions : IPMI, iLO, idrac, management de pare-feu sur 4443, API Kubernetes sur 6443, etcd sur 2379, Elasticsearch sur 9200.

Construisez deux profils de scan et lancez les deux. Le différentiel entre les deux est le jeu de données le plus utile du projet : il montre où TLS se termine à l'intérieur de la frontière de confiance et où la propriété de ces points de terminaison n'est pas définie.

Les jours 6 à 10 appartiennent à la surveillance des journaux de Certificate Transparency et aux balayages DNS. crt.sh est le moyen le plus rapide d'énumérer chaque certificat publiquement reconnu jamais émis pour vos domaines. La requête https://crt.sh/?q=%25.example.com&exclude=expired&output=json retourne chaque certificat non expiré couvrant n'importe quel sous-domaine d'example.com en JSON. Pipez-la dans jq -r '.[] | [.name_value, .issuer_name, .not_after] | @csv' et vous avez un CSV qui peut être différencié de la base centrale de la CA en quelques minutes.

Censys offre un langage de requête plus riche : parsed.names: example.com and parsed.validity.end: [2026-01-01 TO *] retourne les mêmes données avec expansion des SAN et visibilité historique. Croisez les deux : Censys porte parfois des certificats qui ont été retirés de crt.sh à cause du timing de fusion.

Le balayage DNS referme la boucle. Tirez chaque enregistrement A, AAAA, CNAME et TXT de chaque zone autoritative. Pour chaque FQDN, tentez un handshake TLS sur 443 et 8443. Tout ce qui retourne un certificat mais n'est pas dans votre balayage testssl.sh est un hôte que vous avez manqué. Tout ce qui est dans la base CT dont le sujet ne résout pas en DNS est soit un certificat obsolète, soit un enregistrement mal configuré.

À la fin du jour 10, l'inventaire devrait porter au minimum trois colonnes : FQDN, empreinte SHA-256 observée, issuer DN. Une organisation de 5 000 collaborateurs atterrit typiquement entre 8 000 et 25 000 lignes. Ne paniquez pas devant le chiffre. Les dix jours suivants apportent la structure.

Jours 11 à 20 : découverte basée API

Le scan réseau manque tout ce qui ne termine pas TLS sur un socket public : certificats à l'intérieur des KMS cloud, keystores sur les serveurs d'applications, certificats de signature pour le code, certificats embarqués dans des images de firmware, certificats émis pour l'authentification client. La découverte basée API couvre le reste. Les jours 11 à 20 consistent à parcourir chaque API qui peut lister des certificats et à les rassembler dans le même CSV. La transition est aussi un basculement politique : là où les jours 1 à 10 n'avaient besoin que d'un scanner et d'une exception d'ACL réseau, les jours 11 à 20 ont besoin d'identifiants IAM dans chaque compte et chaque namespace.

Commencez par les comptes cloud parce que ce sont les plus rentables.

• AWS Certificate Manager est le magasin canonique des certificats ALB et CloudFront : aws acm list-certificates --certificate-statuses ISSUED --region eu-west-1 --output json, répété sur chaque région et chaque compte, retourne ARN, domaine, not-after et algorithme de clé. ACM Private CA est une API distincte : aws acm-pca list-certificate-authorities. Les server certificates IAM, utilisés pour les classic load balancers hérités, se cachent sous aws iam list-server-certificates.
• Azure Key Vault exige une boucle par vault : az keyvault list suivi de az keyvault certificate list --vault-name <vault>, avec un passage séparé pour les certificats App Service et les listeners Application Gateway.
• GCP Certificate Manager et les SSL certificates Compute Engine ont besoin de gcloud certificate-manager certificates list et gcloud compute ssl-certificates list, plus un parcours par projet.

Écrivez un fin wrapper Python qui émet un objet JSON par certificat avec les champs cloud, account_id, region, service, arn_or_id, cn, sans, issuer, not_after, key_algo, key_size. Ajoutez la sortie au CSV maître.

Kubernetes est la deuxième plus grande source de certificats fantômes dans les stacks modernes. Parcourez chaque cluster avec kubectl get secrets --all-namespaces -o json | jq -r '.items[] | select(.type=="kubernetes.io/tls") | [.metadata.namespace, .metadata.name] | @tsv', puis décodez chaque secret avec kubectl get secret <name> -n <ns> -o jsonpath='{.data.tls\.crt}' | base64 -d | openssl x509 -noout -text.

cert-manager ajoute ses propres ressources : kubectl get certificates,certificaterequests,orders --all-namespaces fait apparaître chaque émission pilotée par ACME et l'émetteur responsable. Suivez Issuer et ClusterIssuer séparément pour savoir quelles racines de confiance sont acceptées dans chaque cluster.

Un parc de 100 clusters faisant tourner ingress-nginx avec cert-manager détient typiquement entre 3 000 et 8 000 secrets TLS, la plupart auto-générés.

Active Directory Certificate Services garde tout dans sa base CA. Sur chaque CA émettrice, certutil -view -out "RequestID,RequesterName,CertificateTemplate,NotBefore,NotAfter,SerialNumber,CertificateHash" -restrict "Disposition=20" /q csv:issued.csv exporte en CSV l'ensemble complet des certificats actuellement émis.

La disposition 20 est « émis » ; basculez sur 21 pour « révoqué », 9 pour « échoué », 30 pour « refusé ». Répétez pour chaque CA de la forêt.

Les CA subordonnées standalone exploitées par des unités métier individuelles sont une découverte fréquente ici, et elles sont par définition des infrastructures fantômes même si elles vivent sous forme de CA officielle. Documentez-les dans le même CSV avec une colonne les signalant comme infrastructure d'émission hors bande.

Les moteurs PKI HashiCorp Vault et les CA internes similaires ont besoin d'appels API plutôt que d'exports CSV. vault list pki/certs retourne les numéros de série ; vault read pki/cert/<serial> retourne le PEM.

Les logs d'orders ACME de Let's Encrypt, ZeroSSL, Buypass et Google Trust Services vous donnent une seconde fenêtre sur les mêmes données. Si vous opérez Boulder, Pebble ou step-ca en interne, dumpez la table d'orders directement depuis la base. Si vous utilisez un fournisseur ACME hébergé, le tableau de bord de compte exporte l'historique des orders des 12 derniers mois.

Au jour 20, le CSV d'inventaire devrait contenir six sources catégorielles — scan réseau, log CT, API cloud, Kubernetes, AD CS, Vault/ACME — avec au moins une ligne par certificat découvert par source. Attendez-vous à ce que le même certificat apparaisse dans trois ou quatre sources ; c'est l'entrée de la réconciliation.

Jours 21 à 25 : réconciliation et cartographie de propriété

La réconciliation est ingrate et décide si le projet aboutit. Cinq jours suffisent seulement parce que les vingt précédents ont été passés à normaliser le schéma. L'objectif est d'avoir une ligne par certificat unique, chaque ligne rattachée à une application, chaque application rattachée à un propriétaire. Tout ce qui échoue à l'une ou l'autre des deux dernières conditions est un orphelin, et la véritable valeur du projet réside dans le décompte des orphelins.

Dédupliquez d'abord. Calculez le SHA-256 du certificat encodé en DER pour chaque ligne et utilisez-le comme clé de jointure : openssl x509 -in cert.pem -outform DER | openssl dgst -sha256 -hex. Deux lignes avec la même empreinte sont le même certificat, même si elles ont été observées à des IP différentes, sur des ports différents ou sous des noms de fichier différents. Repliez les colonnes sources dans un champ multi-valué : un certificat trouvé dans des logs CT, dans AWS ACM et dans un secret Kubernetes devrait produire une seule ligne avec sources=[ct,acm,k8s] plutôt que trois.

Le facteur de déduplication dans un environnement typique est de 2,5 à 4 fois, ce qui explique pourquoi le décompte post-réconciliation passe généralement de 25 000 instances observées à 7 000 à 10 000 certificats uniques.

Normalisez le schéma dans le même passage. Mettez en minuscules le CN. Triez la liste des SAN. Convertissez notBefore et notAfter en ISO 8601 UTC. Calculez days_to_expiry en entier. Parsez la clé publique en key_algo (rsa/ecdsa/ed25519), key_size (bits) et curve (P-256/P-384/etc.). Extrayez l'organisation et le common name de l'émetteur dans des colonnes séparées pour qu'un tableau croisé groupe par ancre de confiance sans regex.

Marquez le type de certificat depuis l'EKU : serverAuth, clientAuth, codeSigning, emailProtection, timeStamping. L'EKU est le champ le plus susceptible d'exposer des certificats utilisés à des fins que leur émetteur n'a pas anticipées — un certificat serverAuth qui apparaît sur un endpoint d'authentification client, par exemple.

Corrélez les certificats aux applications en utilisant deux entrées : le DNS et la CMDB. La jointure DNS est mécanique : chaque SAN se mappe à un FQDN, chaque FQDN se mappe à un service via la table de mapping DNS-vers-application que l'équipe plateforme maintient déjà pour la supervision. Pour les SAN qui ne résolvent pas, repliez-vous sur la paire IP/port observée pendant le scan réseau.

La jointure CMDB est politique : demandez à chaque unité métier de revendiquer une liste de FQDN, et traitez le reliquat non revendiqué comme l'ensemble des orphelins. Un bon objectif au jour 25 est 80 % des certificats mappés à un propriétaire d'application nommé, 15 % mappés à une unité métier mais pas encore à un individu, 5 % marqués comme orphelins. Le marqueur d'orphelin est l'entrée de la conversation suivante, pas un mode d'échec.

Faites un passage de classification final pour marquer les certificats visibles depuis les attaquants. Tout SAN qui résout vers une IP publiquement routable est exposé sur Internet. Tout ce qui est émis par une CA publiquement reconnue apparaît dans les logs CT. Tout ce qui est utilisé sur un endpoint client authentifié exige un soin supplémentaire parce que le coût de révocation est plus élevé. La sortie de réconciliation devrait répondre à quatre questions sur une seule ligne : qui possède ça, où ça réside, quel chemin de confiance le valide, et à quel point il est exposé.

Jours 26 à 30 : scoring de risque et reporting

L'inventaire réconcilié est maintenant l'entrée d'une grille de scoring. La grille est un petit ensemble défendable de poids qui transforme la table en une file de travail priorisée. Ce n'est pas un modèle prédictif. C'est un moyen de s'assurer que le même certificat reçoit le même score de risque quel que soit l'ingénieur qui l'évalue.

Six facteurs portent le poids dans la plupart des playbooks.

• Fenêtre d'expiration : 50 points si days_to_expiry < 30, 30 points si < 60, 10 points si < 90.
• Force de clé : 40 points pour RSA < 2048 ou ECDSA < 256, 20 points pour RSA = 2048, 0 point pour RSA ≥ 3072 ou ECDSA/Ed25519 moderne.
• Algorithme : 50 points pour une signature SHA-1 ou MD5, 0 pour SHA-256 ou plus fort.
• Exposition Internet : 30 points si le SAN résout vers une IP publique, 10 points si joignable depuis un réseau partenaire, 0 si interne uniquement.
• Présence dans les logs CT : 20 points si le certificat est publiquement reconnu et absent des logs CT (indicateur d'un émetteur non conforme ou d'une entrée délibérément supprimée).
• Émetteur inconnu : 25 points si le DN de l'émetteur n'apparaît pas dans la liste des CA approuvées.

Sommez et regroupez : 0-25 informationnel, 26-60 moyen, 61-100 élevé, >100 critique. Ajustez les poids une fois avec l'architecte sécurité, documentez-les dans le playbook, ne les changez pas en cours de projet. La même logique de pondération est discutée dans le guide de la politique et de la gouvernance des certificats pour les organisations qui veulent s'aligner sur leur registre de politique existant.

Les jours 28 à 30 sont pour le reporting. Trois artefacts sortent du projet. Le premier est le CSV brut d'inventaire, traité comme source de vérité et stocké dans un endroit que les opérations peuvent interroger quotidiennement.

Le deuxième est le one-pager prêt pour le conseil d'administration : total des certificats découverts, répartition par émetteur, pourcentage dans chaque case de risque, top trois des thèmes de remédiation, coût projeté de l'inaction exprimé en heures d'indisponibilité attendues par trimestre. Le one-pager existe pour financer le programme continu, pas pour documenter la découverte.

Le troisième est un tracker de remédiation : chaque constat critique et élevé devient un ticket avec un propriétaire, une date d'échéance et une décision de renouvellement ou de remplacement. Les tickets sans propriétaire sont retournés au responsable d'unité métier avec un SLA de 10 jours avant qu'ils ne basculent par défaut sur l'équipe PKI.

L'historique des interruptions liées aux certificats est le matériau le plus persuasif pour la conversation au conseil ; tirez les 24 derniers mois d'interruptions et convertissez-les en heures et en impact sur le chiffre d'affaires.

Templates : schémas CSV et matrice de propriété

Le CSV d'inventaire est l'artefact qui survit aux 30 jours. Son schéma doit être spécifié avant que le scan ne commence, pas après, parce que chaque rapport en aval dépend de noms de colonnes qui ne changent pas. Un schéma exploitable inclut 22 champs.

• Identité : fingerprint_sha256, serial_number, issuer_dn, subject_dn, cn, sans (délimités par point-virgule).
• Validité : not_before, not_after, days_to_expiry.
• Cryptographie : key_algo, key_size, curve, signature_algo.
• Confiance : issuer_org, chain_depth, is_publicly_trusted, eku.
• Déploiement : sources (multi-valué : ct, acm, kv, k8s, adcs, vault, scan), environments (prod/stage/dev), endpoints (liste IP:port).
• Propriété : application, owner_email, business_unit.
• Risque : risk_score, risk_bin, remediation_ticket.

Gardez le fichier en gestion de versions. Différenciez chaque semaine. Le diff est plus important que le snapshot.

La matrice RACI pour la propriété des certificats tourne en parallèle. Cinq rôles couvrent la plupart des organisations.

• L'équipe d'exploitation PKI est responsable de l'émission, de l'automatisation du renouvellement, de la hiérarchie de CA et du programme de découverte.
• Le propriétaire d'application est responsable de la finalité du certificat, des FQDN qu'il couvre et de la réponse aux alertes d'expiration.
• L'équipe plateforme est responsable du substrat de déploiement (load balancer, Kubernetes, mesh) et de garantir que les certificats peuvent être renouvelés sans interruption.
• L'équipe sécurité est responsable de l'application de la politique, de la liste de CA approuvées et des poids de scoring de risque.
• Le responsable d'unité métier est imputable du budget et de la désignation d'un propriétaire d'application quand il manque.

Publiez la matrice sur la même page que le tableau de bord d'inventaire pour que chaque chemin d'escalade soit visible depuis une seule URL. La structure s'aligne naturellement avec le cadre de stratégie CLM qu'un programme mature adopte à terme.

Au-delà du jour 30 : transformer la découverte en supervision continue

Un inventaire à 30 jours est un instantané. Un instantané se dégrade en quelques semaines : chaque nouvel ingress, chaque événement d'autoscale de cluster, chaque compte cloud provisionné pour une nouvelle équipe produit ajoutent des certificats que le playbook n'a pas vus. Au-delà du jour 30, le programme passe du sprint aux opérations.

Le delta hebdomadaire est l'artefact unique le plus utile. Réexécutez le scan réseau, la requête de logs CT et les parcours d'API cloud/Kubernetes une fois par semaine. Calculez la différence d'ensemble par rapport à la semaine précédente. Reportez trois chiffres : nouveaux certificats introduits, certificats retirés (renouvelés ou décommissionnés) et certificats dont le score de risque a franchi une frontière de case. Envoyez le delta sous forme d'e-mail d'une page au responsable PKI et à l'architecte sécurité chaque lundi. Traitez tout ce qui est dans la case élevée ou critique et qui est nouveau comme un incident, pas comme un constat.

Intégrez l'inventaire à l'automatisation du renouvellement pour que la découverte alimente directement l'action. Chaque certificat que l'inventaire marque comme proche de l'expiration devrait déclencher un order ACME si l'émetteur est capable d'automatisation, un ticket de workflow sinon. Le guide de la gestion automatisée des certificats couvre la couche protocole ; la contribution du playbook est le contexte de propriété et d'exposition que l'automatisation seule ne peut pas fournir. Sans ce contexte, le renouvellement automatisé prolonge la vie de certificats qui auraient dû être retirés et ajoute du coût sans réduire le risque.

Fixez un SLO sur l'âge des certificats et un sur la fraîcheur de l'inventaire. Le SLO d'âge de certificat est piloté par politique : une politique de durée de vie de 90 jours avec une fenêtre de renouvellement de 30 jours se traduit par : aucun certificat de production ne peut avoir days_to_expiry < 30 sans un ticket de renouvellement actif.

Le SLO de fraîcheur est piloté par l'observabilité : 90 % des certificats de l'inventaire doivent avoir été observés dans les 7 derniers jours. Suivez les deux comme des panneaux Grafana adossés au même CSV que produit le playbook. Tout ce qui dérive est un écart de découverte, pas un écart de renouvellement, et est routé vers l'équipe plateforme. La découverte continue est aussi le socle de la découverte et de l'inventaire de certificats comme capacité permanente plutôt que comme projet.

La cadence compte autant que le contenu pour le reporting au conseil. Une mise à jour trimestrielle au conseil maintient le programme certificats visible sans consommer l'attention des dirigeants sur les détails. La structure recommandée tient en quatre slides : total de certificats et tendance sur les quatre derniers trimestres, pourcentage dans chaque case de risque avec delta trimestre sur trimestre, top trois des quasi-incidents évités par le programme et taux de couverture de l'automatisation du renouvellement.

L'arc narratif au fil des trimestres devrait être un déclin régulier des cases élevée et critique et une montée régulière de la couverture d'automatisation. Si aucune courbe ne bouge, le programme stagne. Si les deux bougent dans le mauvais sens, l'inventaire régresse et la cadence de découverte doit se resserrer.

Le rôle d'Evertrust

Un playbook de 30 jours prouve que le programme est possible. Le maintenir est un problème différent. Le coût récurrent de la découverte, de la réconciliation, de la cartographie de propriété, du scoring de risque et de la corrélation au renouvellement est ce qui fait que la plupart des projets d'inventaire prennent du retard sur la réalité en l'espace d'un trimestre.

Les équipes qui réussissent à long terme déplacent la part récurrente du travail sur une plateforme qui le fait en continu et qui publie les mêmes artefacts que le playbook manuel produisait — le CSV, le delta, la case de risque, le ticket de renouvellement, la vue conseil — sans la taxe d'ingénierie hebdomadaire.

Evertrust prend les artefacts du playbook et les opère en tant que service. La découverte tourne en continu sur les réseaux, les comptes cloud, les clusters Kubernetes, les forêts AD CS et les émetteurs ACME.

La réconciliation face aux CA émettrices est automatique. La propriété est capturée par certificat et par unité métier, avec des chemins d'escalade câblés sur la même matrice RACI que le playbook définit.

Le scoring de risque utilise la grille que votre équipe a approuvée, appliquée à chaque certificat observé, rafraîchie à chaque scan.

Le renouvellement est automatisé face aux protocoles que l'inventaire a déjà découverts, de sorte que le chemin entre certificat observé et certificat renouvelé selon la politique est un seul workflow, pas trois.

Pour voir comment le playbook se transforme en capacité permanente, explorez le certificate manager et Evertrust Certificate Lifecycle Management.