Qu'est-ce que la détectionTLS ? Guide complet pour identifier tous les certificats de votre environnement

Cet inventaire n’a jamais été aussi important.La durée de vie des certificats devrait diminuerpour atteindre environ un mois et demi d’ici 2029, le nombred’identités de machinesne cesse d’augmenter, et les organisations entament le long processus de migration de leur infrastructure cryptographique vers la cryptographie post-quantique. Rien de tout cela n’est possible si l’on ne peut pas d’abord répondre à une question d’une simplicité trompeuse : de quels certificats disposons-nous réellement, et où se trouvent-ils ?

Une petite précision terminologique. Ce guide utilise systématiquementTLS, car TLS du protocole moderne qui a remplacé les anciennes SSL . Bien que les deux protocoles soient techniquement différents, le secteur continue d'utiliser les termesSSLetTLSde manière plus ou moins interchangeable ; vous verrez donc ces termes utilisés comme synonymes dans la plupart des outils et de la documentation.

Pourquoi la détection TLS est-elle importante ?

La plupart des organisations ne sont pas confrontées à un problème de visibilité par négligence. Ce problème provient du fait que les certificats s’accumulent discrètement, dans toutes les directions, à un rythme que nul processus manuel ne peut suivre. Les certificats sont émis par plusieurs autorités de certification, déployés à la fois dans des environnements cloud et sur site, et demandés par différentes équipes qui s’attachent chacune à résoudre leur propre problème immédiat. Il en résulte l’absence d’une source unique de référence, et personne ne peut affirmer avec certitude combien de certificats existent ni quand le prochain expirera.

C'est ce défi que les professionnels de la gestion des certificats qualifient de « manque de visibilité ». À mesure que le nombre de certificats augmente, l'incertitude s'accroît également. Vous ne savez pas combien de certificats vous gérez, ni combien d'entre eux sont sur le point d'expirer. L'inventaire est la solution à cette lacune spécifique : il automatise la recherche à l'échelle de l'entreprise et établit un inventaire précis des certificats, ce qui vous permet d'éviter les interruptions de service coûteuses et potentiellement préjudiciables résultant d'une perte de visibilité.

Plusieurs facteurs rendent aujourd’hui ce manque de visibilité particulièrement dangereux :

• Les certificats « fantômes ».
  Lorsqu’une unité opérationnelle obtient un certificat en dehors des procédures de gouvernance habituelles, le service de sécurité n’en a jamais connaissance. Ces angles morts correspondent précisément aux certificats les plus susceptibles de présenter des défaillances silencieuses ou d’être mal configurés.
• Prolifération des certificats.
  À mesure que la durée de vie des certificats diminue, un même ensemble de certificats doit être renouvelé beaucoup plus souvent, ce qui multiplie la charge opérationnelle et le risque d'oublier quelque chose.
• Explosiondu nombre d’identitésde machines.
  Les maillages de services et les infrastructures de gestion des identités des charges de travail émettent désormais des certificats en quantités que personne ne demande et que personne ne consultera jamais. Il s’agit d’un parc distinct et bien plus vaste, créé et supprimé automatiquement au sein de grands environnements, qui n’est jamais passé par un service de demande.
• Migration imposée de l’extérieur.
  Les transitions cryptographiques les plus importantes sont celles que vous ne pouvez pas planifier. Sans un inventaire complet basé sur la chaîne de confiance intégrale, vous ne pouvez même pas déterminer lesquels de vos certificats actifs sont concernés, alors que cette identification constitue l’essentiel de la réponse.Absence de base pour la politique ou la planification.Sans inventaire complet, les équipes ne peuvent pas appliquer de politique, planifier les renouvellements ni se préparer à des transitions cryptographiques telles que la préparation à l’ère post-quantique. Vous ne pouvez pas protéger, migrer ou certifier ce que vous ne voyez pas.

Ces deux derniers points inscrivent le processus de recensement dans une perspective à plus long terme. Le secteur se prépare à déployer une cryptographie résistante aux attaques quantiques, afin de protéger les informations et les infrastructures contre les attaques menées à l’aide de supercalculateurs quantiques. La première étape de toute migration de ce type consiste à identifier les certificats dont vous disposez et la cryptographie sur laquelle ils reposent. Le recensement constitue le fondement de l’ensemble des efforts visant à assurer l’agilité cryptographique.

Les certificats reposant sur la norme X.509, un inventaire de qualité doit refléter les détails structurés définis par cette norme, ce qui rend ce registre utile tant pour les opérations que pour les audits.

Fonctionnement de la détection TLS

La découverte n'est pas une technique unique. Les programmes aboutis combinent plusieurs méthodes, car chacune d'entre elles offre une vision différente de l'environnement et aucune approche ne permet à elle seule de tout détecter. Les trois principales approches sont l'analyse basée sur le réseau, la découverte basée sur les CA et la découverte basée sur des agents ou dans le cloud.

Analyse en réseau

L'analyse du réseau est la méthode la plus courante. Un outil de découverte parcourt les réseaux que vous avez définis, se connecte aux TLS et extrait les informations relatives aux certificats qu'il y trouve. Concrètement, vous définissez la portée d'un réseau de l'une des trois manières suivantes : par notation réseau (CIDR), par adresses IP individuelles ou par noms d'hôtes individuels. Chaque réseau défini fait l'objet d'une tâche de découverte distincte, ce qui permet aux administrateurs de segmenter les environnements de grande envergure et d'optimiser les performances, plutôt que d'analyser l'ensemble du réseau en une seule fois.

Plusieurs mesures de contrôle garantissent l'efficacité et la sécurité de la numérisation :

• Pools d'Orchestrator.
  Les tâches d'analyse peuvent être attribuées à des pools d'Orchestrator en fonction de leur emplacement, afin que le scanner approprié intervienne sur la partie du réseau concernée.
• Plages de ports.
  Vous indiquez les ports à analyser, en concentrant l'analyse sur les ports où TLS sont effectivement à l'écoute.
• Calendriers.
  Les tâches de découverte s'exécutent selon une fréquence définie et concernent tous les terminaux inclus dans la définition du réseau.
• Périodes de silence.
  Vous pouvez définir des plages horaires pendant lesquelles les analyses ne seront pas exécutées, ce qui permet d'éviter les analyses pendant les périodes sensibles et d'optimiser davantage leur moment et leur mode d'exécution.

L'avantage de l'analyse du réseau réside dans le fait qu'elle permet de détecter les certificats activement utilisés sur les terminaux auxquels vous avez accès. Sa limite est l'inverse : elle ne détecte que ce qui est à l'écoute sur un réseau que vous contrôlez, c'est pourquoi elle est plus efficace lorsqu'elle est associée aux deux autres méthodes.

Découverte basée sur la CA

La découverte basée sur CA renverse la logique. Au lieu de se diriger vers le point d'extrémité (les « feuilles » de la PKI ), on se tourne vers l'émetteur, selon le principe que l'autorité qui a émis un certificat en conserve une trace faisant autorité. Cela permet une distinction claire entre le domaine privé et le domaine public.

Pour PKI interne, vous vous intégrez directement à l’autorité de certification émettrice et répertoriez les certificats qu’elle a émis. Avec Microsoft AD CS, cela implique d’interroger la base de données de l’AC via ses interfaces de gestion ou ses outils command; avec EJBCA implique d’utiliser l’API REST ou SOAP. Vous obtenez tous les certificats émis par l’autorité de certification, ainsi que les métadonnées relatives aux demandes, telles que le demandeur, le modèle ou le profil utilisé, et l’état de révocation. Élément crucial : en fonction de la fréquence de l’outil de découverte, celui-ci peut recenser chaque certificat dès sa création, avant même que celui-ci ne soit déployé où que ce soit.

Pour les certificats de confiance publique, le mécanisme utilisé est la « Certificate Transparency » (CT). Les navigateurs exigent désormais que les certificats de confiance publique soient enregistrés dans des journaux CT en mode « append-only » avant d’être acceptés ; ainsi, en interrogeant les agrégateurs CT (tels que crt.sh ou Censys) ou les journaux directement pour vos propres domaines, vous obtiendrez les certificats émis à votre nom par n’importe quelle autorité de certification publique. C’est cette méthode qui permet de détecter les « certificats fantômes » : ceux qu’une équipe a obtenus sans en informer le service de sécurité, déployés sur une infrastructure que vous n’analysez pas, ainsi que toute émission abusive usurpant l’identité de vos domaines. Une analyse de vos propres plages d’adresses ne permettrait jamais de les détecter.

La force de la recherche basée sur les autorités de certification (CA) réside dans son caractère faisant autorité et son exhaustivité pour un émetteur donné, quel que soit l'endroit où se trouve le certificat. La limite réside dans le fait que c'est l'inverse d'un balayage du réseau : une entrée d'autorité de certification indique qu'un certificat a été émis, mais pas où il se trouve ni s'il est utilisé. Le CT ne couvre que les certificats publics, et l'énumération interne ne couvre que les autorités de certification auxquelles vous pouvez accéder ; les deux méthodes sont donc complémentaires plutôt que redondantes. Pour boucler la boucle, vous recoupez les données d'émission avec les données de déploiement.

Découverte basée sur des agents et dans le cloud

Les agents s'attaquent au point faible commun aux deux méthodes précédentes : les certificats au repos. Vous installez un processus local léger sur chaque hôte, qui inspecte la machine de l'intérieur. Il parcourt le système de fichiers à la recherche de fichiers de certificats et de clés (tels que .pem, .crt, .pfx et .jks), lit les magasins de la plateforme comme le magasin de certificats Windows et les keystores Java, et analyse la configuration des services pour déterminer quel certificat est associé à quel service. Comme il s’exécute avec des privilèges locaux, il voit ce que le réseau ne peut pas voir : les certificats non associés à un port ouvert, l’emplacement exact des fichiers et l’association aux services, ainsi que l’état de la clé privée. Il peut également signaler un certificat nouvellement installé dès son apparition, plutôt qu’au cours de la prochaine fenêtre d’analyse ; de plus, comme le même agent peut écrire dans les magasins de clés et redémarrer des services, la détection et la correction peuvent être regroupées en un seul canal. Le compromis réside dans la gestion du parc : vous devez déployer et maintenir des agents sur de nombreux systèmes d’exploitation, et il y aura toujours des appliances et des systèmes tiers sur lesquels vous ne pourrez pas en installer.

La découverte dans le cloud étend ce même principe aux infrastructures ne disposant d’aucun hôte sur lequel installer un agent. Les certificats modernes résident de plus en plus au sein des services des fournisseurs plutôt que sur des serveurs ; vous attribuez donc à un outil de découverte des identifiants d’accès en lecture seule à l’API, puis vous effectuez une énumération à travers les comptes, les abonnements, les projets et les régions. Concrètement, cela couvre les services de certificats et les gestionnaires de secrets, les configurations des équilibreurs de charge et des écouteurs CDN, les passerelles API, TLS de Kubernetes, ainsi que l’identité du maillage de services. Ces certificats sont souvent éphémères, provisionnés automatiquement et nombreux ; ils sont de fait invisibles pour les analyses de réseau sur site et pour les agents hôtes. Le point faible réside dans la fragmentation de la couverture : chaque compte et chaque région constituent une intégration distincte, et dès qu’un compte n’ayant pas fait l’objet d’une intégration est créé, cette partie du système devient inaccessible.

« Discovery » et « monitoring » : comprendre la différence

On parle souvent de « découverte » et de « suivi » dans le même souffle, mais ces deux notions ont des rôles distincts, et un programme efficace doit s'appuyer sur les deux.

Les tâches de découverte recherchent de nouveaux certificats. Elles analysent chaque terminal au sein d'un réseau défini et ajoutent à votre inventaire les certificats jusque-là inconnus. Les tâches de surveillance, en revanche, ne prennent en compte que les certificats existants qui ont été marqués pour être suivis, et elles déclenchent des alertes en fonction d'un seuil d'expiration configuré. En d'autres termes, la découverte identifie ; la surveillance surveille.

Voici comment tout cela s'articule :

• Discovery permet de constituer l'inventaire.
  Il répond aux questions « Qu'avons-nous ? » et « Où se trouve-t-il ? ».
• La surveillance permet de maintenir l'inventaire à jour.
  Elle permet de savoir « quels éléments sont sur le point d'expirer ou de ne plus être conformes à la politique ».
• Les deux s'exécutent en continu.
  Discovery doit s'exécuter selon une fréquence régulière afin de détecter rapidement les nouveaux certificats, tandis que la surveillance s'exécute en parallèle pour déclencher des alertes avant toute expiration.

Une bonne pratique consiste à configurer la fonction de détection pour qu’elle intègre automatiquement les certificats nouvellement détectés dans le système de surveillance, afin qu’aucun certificat ne reste dans l’inventaire sans faire l’objet d’une surveillance. Ainsi, dès qu’un certificat est détecté, le compte à rebours pour les alertes d’expiration est déjà lancé.

Les risques liés au fait de ne pas retrouver vos certificats

L'intérêt de la découverte prend tout son sens lorsqu'on examine les problèmes qui surviennent en son absence. Chaque risque correspond à une lacune que la découverte est censée combler.

Interruptions imprévues dues à des certificats périmés

Les certificats arrivant à expiration sont les ennemis de la disponibilité. Il suffit d’une seule expiration manquée pour déclencher une vague de défaillances : une application cesse de répondre, un service dépendant génère une erreur, et la perturbation se répercute en une interruption de service pour les clients. Ces pannes sont particulièrement frustrantes car elles sont tout à fait évitables. Le certificat n’a pas échoué ; il a simplement été oublié. La fonctionnalité de détection élimine cette catégorie des « certificats oubliés » en garantissant que chaque certificat est répertorié et, grâce à la surveillance, suivi jusqu’à sa date de renouvellement bien avant qu’il ne devienne un problème.

Failles de sécurité et manquements à la conformité

Les certificats non détectés sont généralement ceux qui sont le moins bien gérés. Ils peuvent reposer sur des versions de protocole obsolètes ou des algorithmes faibles, être liés à des ancres de confiance que vous ne contrôlez plus, ou comporter des configurations qui enfreignent discrètement les règles. Comme personne ne les surveille, ils deviennent les points faibles que recherche un attaquant. TLS anciennes TLS SSL TLS (TLS .0 et 1.1) en particulier devraient être désactivées au profit du TLS moderne TLS TLS .3), mais vous ne pouvez imposer cette mesure que si vous savez où se trouvent ces configurations obsolètes.

Il existe également un aspect réglementaire. Les cadres réglementaires régissant les données en transit exigent que le chiffrement soit mis en œuvre et géré. Par exemple,

• L'exigence n° 4 de la norme PCI DSS porte sur le chiffrement de la transmission des données des titulaires de carte,
• les dispositions relatives à la sécurité des transmissions prévues par la règle de sécurité HIPAA s'appliquent aux informations médicales protégées en cours de transmission, et
• L'article 32 du RGPD prévoit le chiffrement dans le cadre de la sécurité du traitement.

Un certificat non géré ou mal configuré peut vous mettre en situation de non-conformité par rapport à l'une ou l'autre de ces exigences, et vous ne pourrez pas prouver votre conformité pour des certificats que vous ne pouvez même pas répertorier.

Incapacité à se préparer aux transitions cryptographiques

Deux évolutions sont déjà en train de transformer la gestion des certificats : le passage à des durées de vie nettement plus courtes et la migration à terme vers la cryptographie post-quantique. Ces deux évolutions exigent que vous sachiez exactement de quoi vous disposez. Vous ne pouvez pas planifier une migration vers des algorithmes résistants à l’attaque quantique si vous ne savez pas quels certificats utilisent quelle cryptographie, et vous ne pouvez pas vous adapter à des durées de vie plus courtes si vous ne connaissez pas l’ensemble des certificats nécessitant un renouvellement plus rapide. L’inventaire, associé à une base de données complète, est la condition préalable à une gestion du cycle de vie des certificats qui assure leur sécurité depuis leur émission jusqu’à leur expiration.

Les critères à prendre en compte pour choisir un outil de détection TLS

Tous les outils de découverte ne se valent pas. Utilisez la liste de contrôle ci-dessous pour évaluer n'importe quelle solution au regard des exigences d'un parc de certificats moderne et en constante évolution.

• Analyse complète.
  L'outil doit prendre en charge la découverte via le réseau, via une autorité de certification (CA) et native du cloud. Aucune méthode prise isolément ne permet d'éviter les angles morts ; il convient donc de vérifier en priorité l'étendue de la couverture.
• Analyses approfondies par certificat.
  Trouver un certificat n’est qu’un début ; sa valeur réside dans les attributs qui y sont associés. Recherchez la résolution complète de la chaîne de certificats, l’ensemble complet des noms alternatifs du sujet, les dates de validité, le type et la taille des clés, ainsi que l’algorithme de la clé du sujet et l’algorithme de signature utilisés par l’émetteur. Cette distinction entre les deux algorithmes est importante pour la flexibilité cryptographique, car la force d’authentification d’un certificat dépend de la signature la plus faible de sa chaîne.
• Planification automatisée.
  Discovery doit s'exécuter selon un calendrier récurrent sans intervention manuelle, avec des contrôles tels que les « heures calmes » pour gérer les horaires.
• Inventaire centralisé.
  Un référentiel unique doit regrouper tous les certificats détectés, quelle que soit la manière dont ils ont été identifiés, afin de disposer d'un point centralisé pour la recherche et la génération de rapports.
• Alertes d'expiration.
  Des notifications configurables doivent être déclenchées lorsque les certificats approchent de leur date d'expiration.
• Intégration à la gestion du cycle de vie.
  L'inventaire devrait alimenter directement les workflows de renouvellement, d'attribution et de révocation, plutôt que de constituer un rapport autonome.
• Évolutivité.
  La prise en charge de la segmentation des grands réseaux en zones d'analyse, grâce à l'utilisation de pools d'orchestrateurs, permet de maintenir des performances optimales à mesure que le parc s'étend.
• Rapports et conformité.
  L'outil doit générer des rapports prêts pour l'audit et, dans l'idéal, conserver l'historique à des dates précises afin que vous puissiez répondre à des questions rétrospectives, telles que : quels certificats étaient actifs au cours d'une période donnée ?

Plus les informations par certificat sont détaillées, plus l’inventaire offre de possibilités par la suite, et la gestion devient également plus rigoureuse et précise. Des attributs tels que l’état de la clé privée (où se trouve la clé et si elle est exportable), les liaisons de déploiement (tous les emplacements où un certificat est installé, et pas seulement un) et la provenance de l’émission (quelle autorité de certification, quel modèle, quel demandeur) sont ce qui transforme une simple liste en un outil permettant d’effectuer des audits et de procéder à des migrations. Négliger la profondeur des informations lors de la collecte limite discrètement les capacités de l’inventaire en aval.

L'impact de la réduction de la durée de validité des certificats sur la recherche

La principale raison pour laquelle la découverte passe d’un projet ponctuel à une pratique continue réside dans la décision du secteur de raccourcir la durée de validité des certificats. Le CA/Browser Forum a approuvé une réduction progressive, dans le cadre du vote SC-081v3, qui ramène progressivement la durée de validité maximale sur plusieurs années, pour aboutir à environ un mois et demi (47 jours) d’ici début 2029. Selon le résumé du calendrier fourni par DigiCert, les étapes intermédiaires prévoient une durée de validité maximale de 200 jours début 2026 et de 100 jours début 2027, avant la dernière étape.

Les chiffres ne mentent pas. Un certificat qui, auparavant, ne nécessitait qu'une intervention environ une fois par an devra désormais être renouvelé plusieurs fois par an. Multipliez cela par l'ensemble du parc informatique, et l'ampleur de la charge de travail apparaît clairement :

• Le suivi manuel ne s'adapte plus à l'évolution des choses.
  Avec des durées de vie aussi longues, les tableurs et les rappels de calendrier ne suffisent plus. À ce stade, le suivi et le renouvellement manuels ne sont pas seulement inefficaces ; ils constituent un véritable handicap.
• L'inventaire doit être continu.
  Un audit ponctuel devient obsolète presque immédiatement lorsque les certificats changent aussi rapidement. L'inventaire doit être effectué de manière automatisée et récurrente afin que la liste ne s'éloigne jamais trop de la réalité.
• Investir tôt, c'est payant.
  Les organisations qui mettent en place dès maintenant un processus de découverte automatisé franchiront sans heurts chaque étape aux délais de plus en plus courts, tandis que celles qui attendront vivront chaque raccourcissement de délai comme une nouvelle situation d'urgence.

La réduction de la durée de vie des systèmes ne modifie pas la nature même de la découverte. Elle influe sur la fréquence à laquelle celle-ci doit être effectuée et rend impossible toute exécution manuelle.

Comment Keyfactor vous aider

Keyfactor conçu pour répondre précisément aux défis liés à la détection décrits ci-dessus. Sa fonctionnalité SSL analyse les réseaux définis afin d'identifier tous TLS et d'importer les détails des certificats dans un inventaire centralisé, vous offrant ainsi un registre précis que les processus manuels ne permettent pas de maintenir à jour.

Ce processus correspond directement aux critères d'évaluation abordés précédemment :

• Analyse flexible et segmentée.
  Agilesecexécute des tâches d'analyse organisées par réseau ; celles-ci peuvent être segmentées pour optimiser les performances, attribuées à des pools d'orchestrateurs en fonction de leur emplacement, planifiées selon des intervalles flexibles et adaptées aux heures creuses.
• Inscription automatique à la surveillance.
  Les certificats détectés lors de l'analyse peuvent être automatiquement ajoutés à la surveillance, avec des alertes d'expiration configurables, afin qu'aucun élément ne soit intégré à l'inventaire sans faire l'objet d'une surveillance.
• Automatisation du cycle de vieet bien plus encore.
  Keyfactor Command s'intègre à AgileSec, regroupant ainsi la gestion de l'inventaire, l'automatisation du cycle de vie et les rapports de conformité, de sorte que la recherche d'un certificat débouche directement sur son renouvellement, son provisionnement et sa révocation.
• Prêts pour la suite ?
  La plateforme facilite la préparation à la réduction des durées de vie et aux transitions post-quantiques grâce à son agilité cryptographique, en vous offrant les bases en matière de gestion des actifs et d'automatisation nécessaires à ces changements.

L'offre globale Keyfactor, qui comprend notamment les solutions de découverte et d'inventaire cryptographiques ainsi que l'automatisation du cycle de vie des certificats, est conçue pour que la découverte ne soit pas une tâche isolée, mais constitue la première étape d'un programme complet de gestion des certificats.

Principaux enseignements

• La détection TLS consiste à identifier automatiquement tous les certificats présents dans votre environnement et à enregistrer leurs informations clés.
• Sans ce processus de découverte, les organisations s'exposent à des interruptions de service évitables, à des failles de sécurité et à des manquements en matière de conformité.
• La détection et la surveillance sont complémentaires : la détection identifie les nouveaux certificats, tandis que la surveillance suit ceux déjà connus jusqu'à leur expiration.
• L'analyse du réseau, la découverte basée sur les certificats de sécurité (CA) et la découverte via agent ou dans le cloud couvrent chacune une partie différente de l'environnement ; c'est pourquoi les solutions performantes combinent ces trois approches.
• L'évolution vers des cycles de vie d'environ 47 jours d'ici 2029 rend indispensable, et non plus facultative, une découverte continue et automatisée.
• Un outil de découverte performant offre une analyse complète, des informations détaillées sur chaque certificat, une planification automatisée, une gestion centralisée du parc et une intégration à la gestion du cycle de vie.
• Keyfactor des fonctionnalités complètes de découverte, de surveillance et d'automatisation du cycle de vie des certificats sur une plateforme unique.