Dernière mise à jour : 15 septembre 2025

Au cours des trois dernières décennies, les certificats numériques (X.509) sont progressivement devenus partie intégrante des infrastructures critiques, les entreprises s’appuyant sur eux pour assurer le bon fonctionnement de leurs opérations. Pourtant, parce que l’usage des certificats numériques s’est étendu au fil du temps, de nombreuses organisations n’ont pas suivi les meilleures pratiques ; elles continuent de gérer les certificats de façon ad hoc, sans supervision ni contrôle centralisés. Ces pratiques accroissent les risques business, les expositions à des failles inconnues et provoquent des interruptions de service fréquentes.

Ce document est structuré comme suit : dans la première partie, nous allons examiner les outils de gestion du cycle de vie des certificats (CLM) et leurs fonctionnalités. Nous aborderons les PKI privées et publiques, incluant leurs avantages et inconvénients. Dans la seconde partie, nous décrirons un programme CLM étape par étape, applicable à toute organisation, quels que soient sa taille ou son secteur. Si vous suivez ce programme, vous pourrez reprendre la main sur votre parc de certificats numériques, de l’inventaire de base jusqu’à la visibilité et au contrôle, pour arriver à l’automatisation et aux meilleures pratiques de sécurité.

La gestion du cycle de vie des certificats est un processus complet permettant de gérer les certificats numériques de leur création à leur révocation. Il s’agit d’un élément majeur de la cybersécurité, qui garantit que les identités numériques et les communications réseau d’une organisation restent sûres et dignes de confiance. Un programme CLM efficace doit répondre à deux exigences principales : 1) faciliter la découverte et la surveillance de tous les certificats de l’organisation et 2) fournir un support opérationnel pour toutes les opérations sur les certificats, y compris l’automatisation de leur émission, déploiement, rotation et révocation.

Les activités liées à la gestion des certificats doivent être envisagées dans le contexte plus large de la gouvernance de la cryptographie. La découverte des ressources cryptographiques et l’inventaire sont deux initiatives connexes qui s’entrelacent avec la gestion du cycle de vie des certificats. La CLM doit s’envisager comme un programme continu, conçu pour répondre aux besoins organisationnels en matière de disponibilité, conformité et sécurité.

La gestion du cycle de vie des certificats est indispensable à la plupart des entreprises, mais actuellement deux dynamiques imposent une réaction rapide :

• Réduction de la durée de vie des certificats : dans la sphère de la PKI publique, la durée de vie des certificats va être réduite du maximum actuel d’un an, à 200 jours en mars 2026, puis à 100 jours en mars 2027, et enfin à seulement 47 jours en mars 2029. Si le renouvellement des certificats n’est pas automatisé, ces changements entraîneront une hausse directe des coûts liés aux renouvellements ainsi qu’une plus forte probabilité de panne. Consultez notre article de blog sur ce sujet pour en savoir plus.
• Migration post-quantique : la menace imminente d’un ordinateur quantique apte à briser la cryptographie nécessite de migrer des algorithmes à clé publique actuellement utilisés. Le consensus général veut que la migration des propriétés sensibles soit achevée d’ici cinq ans.

Une Infrastructure à clé publique (PKI) sert à la gestion des identités numériques. Une identité numérique repose sur une clé privée, qui en constitue le cœur, et sur le certificat correspondant, qui inclut une clé publique et des métadonnées. Ces identités, accompagnées de règles d’émission, d’usage et de révocation, forment une PKI.

Une PKI est en général conçue pour servir un besoin particulier. En réalité, il est recommandé de séparer les PKI qui n’ont pas d’usages communs, car cela améliore la sécurité par compartimentation.

Certaines PKI sont destinées à la collaboration inter-organisationnelle : on les désigne alors comme publiques. Si une organisation crée une PKI à ses propres fins, on la dit privée. La grande différence entre les deux tient dans la gouvernance : pour une PKI publique, il existe une structure de gouvernance séparée et tous les acteurs respectent les mêmes règles. Avec une PKI privée, l’organisation qui la crée et l’exploite dispose d’un contrôle total et peut la concevoir pour répondre à ses besoins exacts.

• Conçues pour la collaboration et l’interopérabilité inter-organisationnelles.
• Gouvernance indépendante : tout le monde suit les mêmes règles.
• Grande part du travail effectuée par des tiers (programmes racine, AC,...)
• Changements lents, parfois soumis à des considérations politiques ou dépendants de la réactivité du plus lent.

• Conçues pour l’usage interne à une organisation.
• Contrôle total sur la conception et le fonctionnement de la PKI.
• Nécessite un effort d’implémentation pour couvrir toutes les facettes de la PKI.
• Peut évoluer au rythme de l'organisation.

Il existe plusieurs PKI publiques pouvant nous concerner. Internet PKI désigne le système mondial qui sécurise l’internet en délivrant des certificats numériques pour valider les connexions entre participants au réseau, généralement via le protocole Transport Layer Security (TLS). Web PKI est un sous-ensemble de l’Internet PKI, utilisé uniquement par les navigateurs et adapté à leurs besoins. Les deux PKI se chevauchent et leurs noms sont fréquemment employés indifféremment. S/MIME PKI est destinée à protéger les échanges email et obéit à des règles distinctes.

Les grandes PKI publiques sont gouvernées par les principaux programmes racine, tels que ceux d’Apple, Chrome, Microsoft et Mozilla. Ces programmes établissent les règles et décident des ACs habilitées à participer. Par ailleurs, le CA/Browser Forum est un organisme industriel qui encadre certains aspects techniques des PKI publiques.

Les caractéristiques essentielles sont les suivantes :

• Participation ouverte à tous
• Émission fondée sur la preuve de contrôle d’infrastructure
• Courte durée de vie des certificats imposant l’automatisation
• Certificats majoritairement gratuits
• Enregistrement public de tous les certificats
• Cryptographie faible interdite
• Profils de certificats fixes
• Options limitées de vérification de révocation

L’atout principal des PKI publiques réside dans leur gestion par de grandes entités mondiales, ce qui rend la participation peu - voire pas - coûteuse. Cela assure l’interopérabilité, mais au détriment de la souplesse. Ce compromis convient à de nombreux usages, d’autant plus que les certificats publics sont désormais gratuits. Même les grandes organisations emploient fréquemment des certificats publics pour leurs infrastructures privées.

Cependant, certains cas d’usage dépassent les capacités des PKI publiques :

• Authentification de l’émission insuffisamment rigoureuse 
• Aucune maîtrise de la durée de vie des certificats
• Les certificats divulguent des informations sur l’infrastructure privée
• Pas de support pour les certificats client ou appareil
• Pas de support pour la signature de code ou de documents
• Pas de support pour des profils de certificats personnalisés
• Émission de certificats soumise à des limitations de débit
• Choix restreints de protocoles d’émission
• L’adoption de nouveaux standards (ex : crypto post-quantique) prend plus de temps

En fonction des besoins, des expertises et du budget, une organisation pourra choisir de mettre en place et d’héberger sa propre PKI ou utiliser des options managées proposées par les fournisseurs cloud ou les autorités de certification.

Nous avons vu que les certificats sont créés dans leurs PKI respectives. Grâce au protocole largement répandu Automated Certificate Management Environment (ACME), les serveurs peuvent obtenir leurs propres certificats en communiquant directement avec l’AC de leur choix. Cette approche est adoptée aussi bien par les petites que les grandes structures.

Des organisations souhaitant davantage de contrôle ou de visibilité opteront pour des outils CLM. Par exemple, un organisme voulant surveiller ses activités pourra déployer un produit CLM assurant la découverte et la surveillance.

Les grandes organisations peuvent s’appuyer sur un ou plusieurs outils CLM afin d’imposer une émission centralisée et de mieux maîtriser les AC utilisées pour chaque besoin. Cela s’avère essentiel notamment pour les PKI privées pilotant les infrastructures internes.

Comme pour toute démarche, la clé pour lancer un programme CLM réussi est de cerner les besoins business sous-jacents. Par exemple, considérez les exigences de sécurité et de conformité suivantes :

• Gestion des risques et gouvernance ; obtenir la visibilité sur tous les certificats émis, base d’un contrôle et d’une supervision efficaces.
• Exigences réglementaires et conformité ; vérifier que les certificats respectent toutes les réglementations applicables.
• Renforcement de la sécurité ; surveiller les déploiements de certificats pour garantir l’usage d’une cryptographie suffisamment robuste.
• Agilité cryptographique ; permettre à l’organisation d’identifier ses ressources cryptographiques et de migrer rapidement vers de nouveaux algorithmes si nécessaire.
• Migration vers la cryptographie post-quantique ; soutenir votre organisation dans la transition loin des algorithmes vulnérables à moyen terme.
• Réduction des coûts et notation de sécurité ; minimiser les coûts en assurant des certifications conformes aux politiques de sécurité. Par ailleurs, améliorer la posture de sécurité visible publiquement peut diminuer le coût de l’assurance cybersécurité.

Côté opérationnel, les exigences sont moins nombreuses mais demandent une exécution irréprochable, car toute erreur peut entraîner une indisponibilité du service :

• Automatisation : communiquer avec des autorités de certification (AC) pour faire émettre, déployer, renouveler et révoquer les certificats en fonction des besoins.
• Disponibilité et interopérabilité ; s’assurer que les certificats conviennent aux publics visés et répondent aux critères d’interopérabilité, de performance, et de robustesse.
• Prévention des pannes et disponibilité : limiter les interruptions en surveillant l’expiration, la révocation imprévue et autres problèmes de disponibilité des certificats déployés.

Étant donné la complexité du monde PKI, il existe de nombreux outils CLM et PKI, chacun conçu pour un besoin précis, sans outil universel qui couvrirait tout. Les fonctionnalités se répartissent en général dans l’une de ces catégories :

• Automatisation simple de l’émission ; outils automatisant l’émission et le renouvellement, souvent installés directement sur l’infrastructure utilisatrice des certificats. Généralement via ACME et de plus en plus intégré dans les logiciels serveur.
• Solutions de PKI privée ; outils pour créer et gérer des PKI privées, auto-hébergés ou managés, souvent proposés par les grands fournisseurs cloud ou AC.
• Découverte et visibilité ; outils assurant l’inventaire des certificats et offrant une vue globale sur tout le parc de certificats de l’organisation, leur usage et leur emplacement.
• Automatisation du cycle de vie ; outils pour l’orchestration avancée de l’émission de certificats, souvent intégrés à plusieurs PKI publiques ou privées. Pour prendre en charge ces fonctionnalités avancées, ces outils offrent des modules pour s’intégrer à différents systèmes et logiciels serveur.
• Surveillance de certificats ; généralement incluse dans les outils de supervision de la sécurité réseau, de la disponibilité ou de la gestion des opérations IT.

Pour choisir les bons outils, il faut d’abord cerner ses objectifs et besoins, étudier ce que proposent les différents éditeurs, et retenir ceux qui y répondent le mieux.

Avec la montée en puissance d’ACME, il existe de plus en plus d’outils gérant l’émission et le renouvellement des certificats. La fonctionnalité de client ACME est de plus en plus incorporée dans les logiciels serveur et équipements, simplifiant nettement la gestion des certificats. Bientôt, la plupart des logiciels utilisant des certificats proposeront ACME en natif, permettant la gestion automatisée de base.

Cette automatisation simple est souvent suffisante, mais ne prend pas en charge toute la gestion du cycle de vie. Certaines opérations, comme le changement d’AC émettrice ou le remplacement anticipé de certificats, peuvent rester à réaliser manuellement.

Les outils CLM assurant une automatisation complète du cycle de vie prennent en charge ces tâches d’emblée, via ACME ou des modules d’intégration propriétaires. Il s’agit donc de choisir entre automatiser uniquement l’essentiel — quitte à devoir gérer certaines tâches à la main — ou investir tôt dans l’automatisation complète et réduire l’effort manuel ultérieurement. En cas de choix pour l’automatisation complète, vérifiez la compatibilité de votre CLM avec vos plateformes et logiciels. Nous vous recommandons de démarrer par un essai représentatif avant un déploiement à grande échelle.

Il peut être difficile de trouver l’outil idéal pour votre programme CLM, tant les fonctionnalités varient et couvrent rarement tous les besoins à la fois. Lors de l’élaboration de vos critères d’évaluation, vérifiez dans quelle mesure les outils savent répondre aux questions suivantes :

• Disposons-nous de l’inventaire complet de nos certificats ?
• Tous les certificats utilisent-ils une cryptographie robuste ?
• Quelles sont les AC utilisées ?
• Les bonnes AC sont-elles utilisées aux bons endroits ?
• Où, sur notre réseau, sont installés les certificats ?
• Les certificats et protocoles sont-ils correctement et sécuritairement déployés ?
• Utilisons-nous l’échange de clés post-quantique sur nos propriétés importantes ?
• Les certificats sont-ils émis et renouvelés automatiquement ?
• Pouvons-nous remplacer les certificats à la demande ?
• Pouvons-nous gérer une révocation inopinée ?
• Qui émet nos certificats et où ?
• Quels tiers émettent des certificats en notre nom ?
• Existe-t-il des certificats frauduleusement émis en notre nom ?

Dans la seconde moitié de ce document, nous détaillons un guide étape par étape pour mettre en œuvre un programme de gestion du cycle de vie pour vos certificats publics. Le domaine de la gestion PKI et CLM se résume en trois étapes :

1. Maîtrise de votre parc PKI public
2. Pilotage et évolution des déploiements PKI privés
3. Déploiement d’un ou plusieurs outils CLM pour l’automatisation complète

Nous avons bâti ce programme sur le constat que toutes les organisations participent à la PKI publique, mais très peu disposent de la visibilité suffisante, et moins encore contrôlent réellement l’émission des certificats de leurs propriétés. Or, cette étape peut être menée de façon autonome et plus rapide que les autres. En prenant la main sur votre PKI publique, vous acquérez aussi une précieuse expertise qui facilitera la gestion de vos besoins privatifs et l’automatisation des certificats par la suite.

L’imminente réduction de la durée de validité des certificats à moins d’un an vous oblige d’ailleurs à traiter sans délai vos certificats publics. Dès mars 2026, la première étape abaissera la validité à 200 jours : agissez vite, sous peine d’une forte hausse du volume de renouvellements manuels à traiter.

Commencez par recenser vos besoins et objectifs. Aucun environnement ne ressemble à un autre, c’est d’autant plus vrai pour la PKI. Nous avons présenté de nombreux objectifs courants en première partie. À ce stade, évaluez chaque objectif et hiérarchisez-les; cela créera le fil conducteur pour vos futurs choix.

Les tendances du secteur et les exigences réglementaires influenceront aussi l’ordre de vos priorités. Étudiez la réglementation pour connaître les exigences de conformité. La cryptographie est devenue centrale ces dernières années — DORA, NIS2, NIST, FIPS, PCI DSS, HIPPA, et d’autres exigent de bonnes pratiques pour l’usage de la cryptographie et la gestion des clés. Le monde opère sa transition vers la cryptographie post-quantique avec des délais courts et beaucoup de travail à prévoir : découvrez ce qu’il faut faire et pour quand.

La force des PKI Internet est de permettre d’obtenir une visibilité complète sur les certificats publics, ce qui est plus difficile pour les PKI privées. C’est possible grâce à Certificate Transparency (CT), système conçu pour collecter et publier tous les certificats publics à des fins d’audit et de surveillance. En pratique CT n’est pas obligatoire, mais comme Apple, Google et Microsoft l’exigent pour reconnaître un certificat comme valide, quasiment tous les certificats y sont présents.

Muni du bon outil, la visibilité complète sur les certificats publics se fait quasi instantanément via une base de données exhaustive entretenue par les éditeurs. À partir d’une liste de domaines appartenant à l’organisation, la découverte via CT scrute des milliards de certificats pour identifier ceux qui correspondent directement aux domaines (et sous-domaines) indiqués. Red Sift Certificates est notre produit conçu à cet effet.

L’aisance d’exploitation de Certificate Transparency révèle parfois une autre faiblesse : beaucoup d’organisations ne disposent pas d’une liste exhaustive de leurs noms de domaine. Ces listes sont souvent compilées à la demande, ce qui exige un effort important.

Pour contrer ce problème, les outils CLM peuvent être couplés à d’autres outils de découverte de l’infrastructure, souvent désignée comme Attack Surface Monitoring (ASM). À partir de quelques domaines-clés fournis par le client et de bases de données mondiales, ces solutions trouvent et tiennent à jour la liste des ressources de l’organisation. L’intégration avec les registres, les fournisseurs DNS, et les ACs garantit l’exhaustivité de l’inventaire. Red Sift Certificates intègre cette découverte automatique pour une meilleure expérience utilisateur.

Résultats attendus :

• Liste exhaustive des domaines enregistrables de l’organisation
• Synchronisation automatique des noms de domaine depuis les sources officielles
• Recensement continu de tous les sous-domaines
• Découverte continue de nouveaux domaines
• Inventaire exhaustif des certificats publics émis
• Rapport sur les AC émettrices et les problèmes liés aux certificats

Disposer d’un inventaire complet est un bon point de départ, mais le vrai bénéfice réside dans la connaissance de leur usage et de leur localisation. Cela exige une surveillance réseau active pour relever où chaque certificat est installé et comment il est utilisé.

• Surveillance des domaines et sous-domaines : à partir de l’inventaire, l’outil surveille et scanne en continu toutes les adresses IP concernées. Cette méthode gère d’elle-même tous les services publics.
• Reconfiguration des pare-feu : certains services peuvent tourner sur une infrastructure publiquement routable mais inaccessible au public. Autoriser l’accès de l’outil de supervision via le pare-feu augmente la visibilité sans grand effort.
• Surveillance des plages réseau statiques : le scan des plages affectées à l’organisation permet d’identifier des domaines oubliés ou des services sur des IP brutes. Idéalement, on privilégiera le scan managé sans agent afin de limiter la charge de travail.
• Surveillance du réseau privé : une part de l’infrastructure reste injoignable via le réseau public. Il faut alors installer des agents, un par environnement, ce qui constitue la tâche la plus chronophage de la supervision.

Résultats attendus :

• Découverte de tous les déploiements de certificats
• Identification des tiers connectés et de leur niveau de sécurité
• Repérage des certificats internes ou externes risquant d’expirer
• Identification des certificats mal configurés
• Liste des services, protocoles et configurations cryptographiques
• Rapport sur la couverture de migration post-quantique
• Rapport sur le niveau d’automatisation déployé
• Rapport sur le partage de certificats entre services

À ce stade, vous devriez avoir une visibilité complète de tous vos certificats, de leur emplacement et des informations associées. Contrairement aux trois premières étapes, qui s’enchaînent toujours, ici vous allez probablement traiter les priorités de façon plus souple. Certaines failles critiques apparaîtront très vite, que ce soit des certificats expirés, mal configurés ou mal utilisés. Le manque ou la présence de l’échange de clés post-quantique est un exemple d’aspect à examiner d’entrée de jeu (nous aborderons ce point en détail plus loin). Autant résoudre cela en priorité, car la suite reposera sur la coopération transversale entre services.

La principale finalité de cette étape est de découper votre parc PKI en groupes logiques pour votre environnement, habituellement sur la base des entités métiers, de la criticité et des types de données détenues. Acquérir la vision circonstanciée requise nécessite souvent de nombreux échanges internes.

La deuxième action consiste à identifier les équipes responsables de chaque groupe. Cette étape est cruciale : elle garantit que chaque problème détecté est transmis aux bons interlocuteurs pour traitement. À l’occasion, vous repérerez les tiers sur qui vous vous reposez pour la livraison de services. Selon la nature de votre relation, vous pourrez ou non les intégrer à la liste des équipes référentes.

Une fois les groupes et équipes définis, l’implémentation de l’alerte ne tiendra plus qu’à un bouton à activer. Après cette étape, idéalement, vous ne devriez plus jamais subir de certificat expiré inaperçu.

Cette étape fonde la suite de votre démarche : prenez le temps de cartographier tous les intervenants et impliquez-les dans ce programme. Réfléchissez aussi à l’opportunité de relier vos outils PKI à d’autres applications métiers, pour que l’information sur les certificats soit accessible partout où elle est utile.

Résultats attendus :

• Identification des propriétés à haute priorité à traiter d’urgence
• Définition des entités métiers et équipes assignées
• Regroupement des ressources selon la priorité et la responsabilité
• Paramétrage de l’alerte anti-panne, aiguillée vers les bons interlocuteurs
• Identification des services tiers, embarqués ou livrés sur vos domaines
• Intégration des alertes dans des systèmes externes via API

En 2025, l’automatisation concerne tout le monde, car les certificats encore renouvelés à la main — actuellement une fois par an — devront l’être deux fois par an dès mars 2026, la durée passant à 200 jours. Puis la réduction continuera (100 jours en mars 2027, 47 jours en mars 2029). Vous devez donc agir rapidement pour identifier ce qui n’est pas automatisé et mobiliser votre organisation pour éliminer les renouvellements manuels.

L’adoption du protocole Automatic Certificate Management Environment (ACME) progresse chaque jour et va devenir la norme pour tous les certificats. L’avantage d’ACME est son universalité : il offre la possibilité de passer à tout AC compatible. Les CLM les plus complets proposent des intégrations avancées, mais enferment chez un éditeur. Miser sur ACME reste donc le choix le plus sûr, libre à vous de passer à un CLM propriétaire pour vos propriétés majeures si le besoin se présente.

Vous devrez choisir les AC à utiliser ; là encore, cela dépendra de votre contexte. Pour la PKI publique, les AC gratuites offrent souvent la meilleure valeur, fournissant les mêmes services sans frais. D’ailleurs, Let's Encrypt est souvent en avance dans l’intégration de nouvelles fonctionnalités et sécurités. Pour les PKI privées, les besoins en support, outils et services professionnels sont différents.

Résultats attendus :

• Chemin vers l’automatisation bien identifié
• Inventaire de tous les environnements devant recevoir des certificats
• Documentation d’aide à l’automatisation pour chaque contexte
• Décision sur l’usage d’ACME versus intégration CLM propriétaire
• Court listing des AC de confiance à utiliser

Les grandes PKI publiques ont pour avantage d’intégrer des mécanismes de surveillance et d’audit, via la Certificate Transparency (CT). Nous avons abordé le CT à la première étape, pour sa précieuse capacité à recenser rapidement tous les certificats de votre parc PKI. À ce stade, l’objectif était d’identifier tous vos certificats non expirés. Mais on peut également s’en servir pour repérer en temps réel les nouveaux certificats, au fur et à mesure qu’ils sont créés et inscrits dans les logs publics. C’est essentiel, non seulement pour la visibilité immédiate, mais aussi pour détecter toute émission non autorisée.

Pour la PKI publique, le détenteur de domaine n’a pas la main techniquement sur l’émission. Au final, n’importe quelle AC habilitée peut émettre un certificat pour n’importe quel domaine, sans l’accord du propriétaire. Il est donc crucial de mettre en place une surveillance afin de détecter toute émission frauduleuse.

Un autre atout du CT est d’aider à comprendre la structure d’infrastructure liée à vos certificats. Chaque certificat liste un ou plusieurs domaines valides, fournissant des pistes pour la découverte de nouveaux sous-domaines dès qu’un certificat le mentionne.

Les certificats publics sont consignés dans les journaux CT accessibles à tous. Avec le bon outil, l’accès est facile, surtout si ce dernier automatise la gestion de volumes importants et facilite la compréhension de l’usage réel des certificats. Des outils open source existent également pour exploiter ces accès directement.

Au début, recevoir un courriel à chaque émission de certificat peut sembler pratique — mais cela devient vite envahissant, et que faire de ces notifications successives ? Comment distinguer vos vrais certificats d’une émission frauduleuse ? C’est typiquement un problème qui doit être automatisé.

Les outils de surveillance CT se concentrent souvent sur la détection d’émissions sous les domaines connus, mais il est possible d’étendre la surveillance à l’ensemble du PKI public pour détecter des manœuvres frauduleuses. Par exemple, on peut ainsi repérer des certificats sur un domaine ressemblant au vôtre, signe avant-coureur de phishing. Ce type de détection s’inscrit plutôt dans le champ des solutions de protection de réputation de marque et de domaines. Red Sift’s Brand Trust en est un exemple.

Résultats attendus :

• Surveillance en temps réel des certificats nouvellement émis
• Traitement automatisé de l’émission courante pour éliminer les faux positifs
• Identification des émissions atypiques nécessitant attention
• Identification des tentatives d’usurpation sur l’ensemble de la PKI publique

La PKI publique a ceci de particulier que l’émission de certificats ne repose pas sur une authentification classique. Pour simplifier l’usage, il suffit de prouver la maîtrise de l’infrastructure concernée pour obtenir un certificat. Si la plupart du temps cela fonctionne, il peut arriver qu’une configuration erronée permette d’obtenir à tort un certificat. C’est le cas du problème dit du Dangling DNS, où un nom de domaine pointe vers une IP que le propriétaire a abandonnée. Par exemple, vous détruisez un serveur cloud mais négligez de modifier la configuration DNS qui le désignait : une autre personne obtenant la même IP pourra obtenir un certificat à votre nom.

Un standard relativement récent, Certification Authority Authorization (CAA), tend à rétablir un peu d’ordre et à donner la main sur l’émission des certificats aux titulaires de domaines. Le CAA permet de publier dans le DNS les politiques d’émission que toutes les AC doivent respecter. Ce n’est pas une authentification forte — en dernier lieu, tout dépend de l’AC — mais c’est ce qui se rapproche le plus d’une sécurité solide dans la PKI publique actuelle.

Les politiques CAA s’expriment en enregistrements DNS sur les domaines à contrôler. Au plus simple, cela permet de choisir une ou plusieurs AC de confiance, interdisant implicitement toutes les autres d’émettre. On peut verrouiller l’émission sur les certificats standards, les jokers, S/MIME, BIMI, etc. Dans le cas où une unique AC est autorisée, des consignes supplémentaires sont possibles pour renforcer la sécurité.

Le CAA peut être utilisé de diverses façons, mais de façon générale, voici trois situations : 1) par défaut, sans CAA, toute AC peut émettre pour vos domaines ; 2) une configuration élargie (large CAA) avec plusieurs AC est simple à déployer et réduit résolument l’exposition ; 3) une configuration très restrictive (narrow CAA) permet la sécurité maximale sur les propriétés les plus sensibles.

NOTE : En juin 2025, le CA/Browser Forum a voté l’obligation du contrôle DNSSEC sur toutes les opérations DNS relatives à l’émission de certificats, incluant la vérification CAA. Dès mars 2026, la présence de DNSSEC permettra de valider la politique CAA par cryptographie, réduisant le risque d’attaque visant à la contourner.

Une supervision CT bien menée, comme vue à l’étape précédente, trouve toute sa puissance associée à des politiques CAA complètes : ensemble, ces deux outils filtrent tout ce qui n’est pas autorisé ou attendu.

Résultats attendus :

• Liste limitée d’AC fiables, moins susceptibles d’erreurs ou de compromission
• Déploiement d’une configuration CAA générale sur tous les domaines
• Blocage systématique (deny-all) CAA sur les domaines « parkés »
• Déploiement de CAA restrictive sur les propriétés sensibles
• Supervision CT avancée intégrée avec les politiques CAA

Le monde opère actuellement une transition vers la cryptographie post-quantique, pour se prémunir contre l’arrivée redoutée des ordinateurs quantiques pertinents pour la cryptographie (CRQC), capables de casser les algorithmes à clé publique aujourd’hui utilisés. Selon le contexte, la migration complète peut prendre cinq ans pour les propriétés majeures, dix pour tout le reste. Nul ne sait quand surviendra le Q-Day, mais il vaut mieux s’y préparer sans tarder.

Pour votre PKI publique, la seule action immédiate est d’augmenter la couverture de l’échange de clés post-quantique sur vos propriétés essentielles. Même si l’on ne pense pas qu’un CRQC soit opérationnel aujourd’hui, il existe une attaque dite « Stockez maintenant, déchiffrez plus tard » (« Harvest Now, Decrypt Later ») basée sur la capture de trafic chiffré, qui serait déchiffré plus tard quand ces machines existeront. Selon votre analyse de risque, il peut être urgent d’agir, surtout pour des données devant rester secrètes sur une décennie. Si un CRQC survient prochainement, ce sera trop tard pour le trafic déjà capturé…

Nous avons préparé un guide complet dédié pour vous accompagner dans la transition post-quantique.

Résultats attendus :

• Déploiement immédiat de l’échange de clés post-quantique sur les propriétés sensibles
• Chemin d’évolution clair pour le reste du parc

Dernière étape de votre gestion du parc PKI public, elle vise à traiter les nombreuses problématiques de configuration pouvant nuire à la sécurité. Si vous échouez ici, avoir le contrôle total des certificats n’aura aucun intérêt s’ils sont mal déployés. Quelques axes à surveiller :

• Algorithmes et force de la clé publique : s’assurer que les certificats utilisent des algorithmes et tailles de clé adaptés. Du côté PKI publique, les AC rejettent les clés trop faibles, mais des failles subsistent, davantage visibles sur les PKI privées.
• Configuration des protocoles cryptographiques : garantir l’usage de protocoles sûrs et paramétrés de façon adéquate. Ce paramétrage n’est pas binaire, puisque parfois des compromis sont nécessaires pour supporter d’anciens user agents.
• Chaîne de certificats correcte : vérifier que tous les certificats comportent une chaîne complète et valide bouclant sur une racine acceptée des utilisateurs visés. La racine elle-même n’a pas à être explicitement configurée. Une chaîne incorrecte peut tout bloquer et est difficile à diagnostiquer.
• HTTP Strict Transport Security : déployer et précharger la politique HTTP Strict Transport Security (HSTS) sur tous les domaines afin que les alertes de certificat invalide ne puissent être contournées et que tous les flux HTTP soient chiffrés automatiquement. HSTS empêche les utilisateurs de forcer le passage via une attaque réseau active.
• Cookies HTTP sécurisés : s’assurer que les cookies sont marqués comme sécurisés et déployer les prefixes de noms de cookie (RFC 6265bis) pour corriger des faiblesses historiques dans leur gestion par les navigateurs. L’absence de ces mesures sur un site par ailleurs sûr pourrait permettre l’usurpation de session utilisateur.
• Contenu mixte HTTP : garantir non seulement le chiffrement du contenu principal d’un site, mais aussi de toutes les ressources embarquées et des liens externes.
• Politique CAA : déjà traitée précédemment, elle doit être appliquée à chaque propriété pour limiter l’émission de certificats aux seuls acteurs légitimes.

Reposez-vous sur vos outils PKI pour détecter les sites concernés par ces failles. Tous les outils ne couvrent pas l’ensemble de ces standards. La majorité des CLM gèrent PKI et TLS, mais peinent sur la configuration sécurisée du « dernier kilomètre ». Nous couvrons tous ces aspects dans les produits Red Sift. Si votre outil actuel ne les gère pas, essayez notre solution gratuite sur hardenize.com pour couvrir les lacunes. Ce test peut aussi convenir en cas de travail avec des tiers n’ayant pas vos outils.

Pour plus d’information, consultez notre guide complet sur la configuration SSL/TLS et PKI, qui couvre en détail tous ces sujets.

Résultats attendus :

• Guide des meilleures pratiques cryptographiques
• Nouveaux systèmes déployés selon les bonnes pratiques
• Plan de mise en conformité progressive de l’existant
• Plan de gouvernance pour l’évolution continue des politiques