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
L'infrastructure à clé publique est le cadre de confiance qui sous-tend chaque connexion HTTPS, chaque e-mail signé numériquement et chaque équipement authentifié sur votre réseau. Ce guide explique ce qu'est la PKI, comment elle fonctionne, où les organisations échouent à la mettre en œuvre et comment choisir la plateforme adaptée à vos besoins.
Une infrastructure à clé publique (PKI) est l'ensemble des rôles, politiques, équipements matériels, logiciels et procédures nécessaires pour créer, gérer, distribuer, utiliser, stocker et révoquer des certificats numériques, et pour administrer le chiffrement à clé publique.
Voyez la PKI comme le système de passeports du monde numérique. De la même manière qu'un État délivre des passeports via des organismes de confiance, vérifie l'identité avant la délivrance et tient à jour la liste des documents révoqués, une PKI émet des certificats numériques via des autorités de certification (CA) de confiance, vérifie l'identité des demandeurs avant l'émission et publie les informations de révocation pour que les parties prenantes puissent vérifier qu'un certificat est toujours valide.
Sans PKI, il serait impossible de vérifier que le site web que vous visitez est authentique, que l'e-mail reçu a bien été envoyé par votre collègue ou que la mise à jour logicielle que vous installez n'a pas été altérée. La PKI est le socle invisible qui rend la confiance numérique possible à grande échelle.
La PKI n'est ni un produit unique ni un simple protocole. C'est un cadre architectural qui combine cryptographie asymétrique, normes de certificats (X.509), protocoles de validation et procédures opérationnelles en un modèle de confiance cohérent. Toute organisation qui utilise HTTPS, signe du code, chiffre des e-mails ou authentifie des équipements s'appuie déjà sur une PKI, qu'elle la gère délibérément ou non.
L'entité qui a besoin d'un certificat (un serveur, un utilisateur ou un équipement) génère une paire de clés asymétriques. La clé privée reste secrète ; la clé publique sera intégrée dans le certificat. La génération doit s'appuyer sur des générateurs aléatoires cryptographiquement sûrs, et la clé privée doit idéalement être stockée dans un dispositif matériel (HSM ou TPM).
Le demandeur crée une CSR contenant la clé publique et les informations d'identité (nom de domaine, organisation, etc.). La CSR est signée avec la clé privée du demandeur, prouvant qu'il la possède sans la révéler. Elle est ensuite transmise à la CA ou à la RA.
L'autorité de certification vérifie l'identité du demandeur. Pour les certificats TLS publics, cela passe par une validation de domaine (DV), d'organisation (OV) ou étendue (EV). Pour une PKI privée, la validation suit les politiques propres à l'organisation. Une fois approuvé, le certificat est signé par la CA avec sa clé privée.
Le certificat signé est renvoyé au demandeur et installé sur le système cible (serveur web, serveur de messagerie, équipement, etc.) accompagné des certificats CA intermédiaires nécessaires à la formation d'une chaîne de confiance complète. Cette étape peut être automatisée via des protocoles comme ACME, SCEP ou EST.
Lorsqu'un client se connecte à un serveur présentant un certificat, il le valide : il vérifie la signature de la CA, remonte la chaîne de confiance jusqu'à une CA racine présente dans son magasin de confiance, contrôle que le certificat n'est pas expiré et vérifie le statut de révocation via CRL ou OCSP. Si toutes les vérifications sont concluantes, une session chiffrée est établie.
Avant leur expiration, les certificats doivent être renouvelés. Avec la réduction de la durée de vie TLS à 47 jours d'ici 2029, chaque certificat devra être renouvelé environ 8 fois par an. Si une clé est compromise ou si le statut d'une entité change, le certificat doit être révoqué immédiatement et la révocation publiée via CRL/OCSP.
L'entité de confiance qui émet et signe les certificats numériques. Une CA vérifie l'identité du demandeur avant de lier sa clé publique à une identité. Les organisations peuvent utiliser des CA publiques pour leurs services exposés à l'extérieur, et des CA privées pour un usage interne. La clé privée de la CA, généralement protégée par un HSM, est l'actif le plus critique de l'ensemble de la PKI.
Joue le rôle de point de contrôle entre les demandeurs de certificats et la CA. La RA vérifie les déclarations d'identité, valide les Certificate Signing Requests (CSR) et approuve ou rejette les demandes avant qu'elles n'atteignent la CA pour signature. Dans les déploiements plus modestes, la fonction RA est souvent intégrée à la CA elle-même.
Les justificatifs d'identité concrets émis par la CA. Chaque certificat lie une clé publique à une identité (un domaine, un utilisateur, un équipement) selon la norme X.509. Les certificats contiennent des métadonnées telles que l'émetteur, la période de validité, les contraintes d'usage de clé et les Subject Alternative Names (SAN).
Mécanismes permettant d'invalider des certificats avant leur expiration. Les Certificate Revocation Lists (CRL) sont des listes périodiquement publiées de numéros de série révoqués. OCSP fournit des contrôles de statut en temps réel et par certificat. Les deux sont indispensables pour maintenir la confiance lorsqu'une clé est compromise ou qu'une affiliation change.
L'ensemble des certificats de CA racine auxquels un équipement, un navigateur ou un système d'exploitation accorde sa confiance par défaut. Lorsqu'un client reçoit un certificat, il construit une chaîne de confiance depuis ce certificat jusqu'à une racine présente dans son magasin. Si la chaîne est valide et la racine de confiance, le certificat est accepté.
La CP (Certificate Policy) et le CPS (Certification Practice Statement) sont les documents de gouvernance qui définissent les règles de la PKI : qui peut demander des certificats, quelle validation est requise, comment les clés doivent être protégées et ce qui se passe en cas de révocation. Ces documents sont essentiels pour la conformité et l'audit.
Stocker les clés de signature d'une CA dans un logiciel constitue une vulnérabilité critique. Si la clé de la CA est compromise, tous les certificats qu'elle a émis deviennent suspects. Les clés des CA racines et émettrices doivent toujours être protégées par des modules matériels de sécurité (HSM) certifiés FIPS 140-3 niveau 3.
Utiliser une CA racine qui émet directement des certificats d'entité finale est risqué. Si cette CA est compromise ou doit être remplacée, tous les certificats doivent être réémis. La meilleure pratique consiste à mettre en place une hiérarchie à deux (ou trois) niveaux : une CA racine hors-ligne et une ou plusieurs CA émettrices en ligne.
Si vous ne savez pas quels certificats existent dans votre environnement, vous ne pouvez pas les gérer. Les certificats fantômes émis par des développeurs, des équipes cloud ou hérités de fusions-acquisitions créent des angles morts. La découverte des certificats doit être continue, pas ponctuelle.
Suivre les certificats dans des tableurs ou des systèmes de tickets est une bombe à retardement. Les incidents liés aux certificats coûtent des millions aux entreprises et entament la confiance des clients. Avec des certificats dont la durée de vie passe à 47 jours, l'automatisation n'est plus une option.
Les ordinateurs quantiques finiront par casser RSA et ECC. Les organisations doivent commencer dès maintenant à bâtir une PKI crypto-agile : inventorier les actifs cryptographiques, tester les algorithmes post-quantiques et s'assurer que leur plateforme PKI peut prendre en charge la migration d'algorithmes sans nécessiter une refonte d'architecture.
Émettez des certificats depuis votre propre CA — Evertrust PKI est une autorité de certification complète qui prend en charge l'enrôlement via ACME, SCEP, EST, CMP et API REST. Déployez-la on-premises ou dans le cloud avec une intégration HSM native pour garantir la souveraineté de vos clés.
Gérez tous vos certificats au même endroit — Evertrust CLM découvre les certificats à travers toute votre infrastructure (réseau, cloud, postes de travail), quelle que soit la CA émettrice. Obtenez une vue unifiée de votre PKI hybride.
Automatisez l'ensemble du cycle de vie — De l'enrôlement au renouvellement en passant par la révocation, automatisez les opérations sur les certificats à grande échelle. Prêt pour l'ère des certificats TLS à 47 jours grâce à la prise en charge native d'ACME.
Remplacez ADCS sans rupture — Migrez de Microsoft ADCS vers une plateforme PKI moderne et multi-protocoles avec un déploiement en parallèle. Conservez votre intégration AD existante tout en gagnant la prise en charge d'ACME, du cloud et une visibilité complète sur le cycle de vie.