Certificats serveur TLS
Sécurisez le trafic web à grande échelle
Inventaire des certificats
Découvrez et suivez tous vos certificats
Certificats DevOps
Automatisez pour les pipelines CI/CD
Chiffrement d'e-mails
S/MIME pour la messagerie d'entreprise
Directive NIS2
Obligations européennes en cybersécurité
DORA
Résilience opérationnelle numérique
eIDAS 2.0
Identification électronique et services de confiance
RGPD
Protection des données et vie privée
Cyber Resilience Act
Règlement européen sur la sécurité des produits
À mesure que les volumes de certificats augmentent, la gestion improvisée s'effondre. Un cadre de gouvernance solide, fondé sur des politiques claires, des rôles définis et une application automatisée, fait toute la différence entre une PKI sécurisée et une dette incontrôlée.
Lorsqu'une organisation gère une poignée de certificats, la gouvernance est simple. Quelqu'un demande un certificat, quelqu'un d'autre l'approuve, et un tableur suit les dates d'expiration. Mais les entreprises modernes n'en gèrent pas une poignée ; elles en gèrent des dizaines de milliers, parfois des centaines de milliers, répartis sur plusieurs autorités de certification, fournisseurs cloud et unités opérationnelles.
À cette échelle, l'absence de politique n'est pas de la liberté ; c'est du chaos. Les équipes choisissent des algorithmes de clé différents, les certificats sont émis avec des conventions de nommage incohérentes, les durées de validité varient fortement, et personne ne peut dire avec certitude quelles CA sont réellement en usage. Le résultat est un environnement difficile à auditer, coûteux à maintenir et vulnérable aussi bien aux pannes qu'aux failles de sécurité.
La politique et la gouvernance des certificats résolvent ce problème en établissant un ensemble clair de règles qui définissent qui peut demander des certificats, quels types de certificats sont autorisés, comment ils doivent être configurés et comment la conformité est vérifiée. Ce chapitre explique comment construire et faire respecter ce cadre.
Quelles CA sont autorisées à émettre des certificats pour votre organisation ? Cela inclut à la fois les CA publiques (pour le TLS exposé à l'externe) et les CA internes (pour le mTLS, l'identité des appareils et la signature de code). Une liste de CA approuvées empêche les équipes de se procurer des certificats auprès de fournisseurs non vérifiés ou non audités, réduisant le risque de certificats fantômes.
Définissez les types et tailles de clés minimaux acceptables. La plupart des organisations exigent aujourd'hui RSA 2048 (ou plus) et migrent vers ECDSA P-256 ou P-384 pour de meilleures performances et une sécurité renforcée. Votre politique doit également traiter la préparation au post-quantique et fixer un calendrier pour les transitions d'algorithmes.
Combien de temps les certificats doivent-ils rester valides ? Les certificats TLS publics sont déjà limités à 398 jours par le CA/Browser Forum et passeront bientôt à 90 jours (puis 47 jours). Les certificats internes peuvent avoir des exigences différentes. Votre politique doit définir la durée maximale de validité pour chaque type de certificat et chaque cas d'usage.
Des Subject Distinguished Names (DN) et Subject Alternative Names (SAN) standardisés rendent les certificats plus faciles à identifier, rechercher et gérer. Une bonne politique de nommage précise les champs obligatoires (Organization, Organizational Unit, Country), interdit les certificats wildcard lorsqu'ils ne sont pas nécessaires et définit les modèles de SAN pour les différents environnements.
La CP est un document de haut niveau qui énonce ce que l'organisation exige. Elle définit les règles, obligations et attentes en matière d'usage des certificats : quels types de certificats sont autorisés, quels niveaux d'assurance sont requis et dans quelles conditions les certificats peuvent être émis ou révoqués. Considérez-la comme la « constitution » de votre PKI.
Le CPS décrit comment la CA met en œuvre les exigences fixées par la CP. Il couvre les procédures opérationnelles, les contrôles techniques et les mesures de sécurité physique en place. Si la CP indique « les certificats doivent utiliser RSA 2048 ou plus », le CPS explique précisément comment la CA fait respecter cette exigence dans son pipeline d'émission.
Le cadre standard pour la rédaction des documents CP et CPS est défini par la RFC 3647. Elle fournit une structure commune en neuf sections couvrant tout, des obligations et de la responsabilité aux contrôles techniques de sécurité, ce qui facilite la comparaison des politiques entre organisations et CA.
Sans CP, il n'y a pas de règles communes. Sans CPS, les règles n'existent que sur le papier. Ensemble, ils forment une chaîne de gouvernance complète : la CP fixe la norme, et le CPS prouve qu'elle est respectée. Les auditeurs et les régulateurs attendent que les deux soient à jour et alignés.
Définir et appliquer les politiques de manière centralisée — Evertrust CLM vous permet de définir les politiques de certificats (CA approuvées, algorithmes de clé, limites de validité, règles de nommage) et de les faire respecter automatiquement à chaque demande de certificat, quelle que soit la CA émettrice.
Contrôle d'accès basé sur les rôles — Le RBAC intégré, doté de workflows d'approbation configurables, garantit que les bonnes personnes approuvent les bons certificats. La séparation des tâches est appliquée par la plateforme, pas par convention.
Reporting prêt pour l'audit — Chaque action sur un certificat est consignée dans une piste d'audit immuable. Des tableaux de bord de conformité mettent en évidence les violations de politique en temps réel, et des rapports exportables simplifient les audits.
Émission basée sur des templates — Evertrust PKI fournit des modèles de certificats préconfigurés qui intègrent les exigences de politique directement dans le processus d'émission. Les demandeurs sélectionnent un template ; la plateforme prend en charge la conformité.