Qu'est-ce qu'une autorité de certification ? Guide complet sur la confiance numérique

Chaque connexion chiffrée à laquelle vous faites confiance, qu’il s’agisse d’une connexion à votre compte bancaire ou d’un appel d’API entre microservices, repose sur la réponse correcte à une seule question : l’entité à l’autre bout est-elle vraiment celle qu’elle prétend être ? Les autorités de certification ont pour rôle de répondre à cette question. Elles constituent les piliers de confiance qui rendent possible, à grande échelle, une communication authentifiée et chiffrée.

Ce guide explique ce qu'est une autorité de certification, comment fonctionne le processus de délivrance, la hiérarchie de confiance qui garantit la sécurité du système, ainsi que la manière de déterminer quel type d'autorité de certification répond le mieux aux besoins de votre organisation.

Qu'est-ce qu'une autorité de certification ?

Une autorité de certification est une entité de confiance qui vérifie l'identité des utilisateurs, des machines, des organisations, des services, etc., puis délivre des certificats signés numériquement qui attestent de ces identités. Dans le cadre d'une infrastructure à clé publique, la fonction principale de l'autorité de certification consiste à délivrer et à révoquer des certificats, tout en prenant en charge les processusde gestion des certificats, notamment la validation des demandes et leur publication.

Fondamentalement, une autorité de certification (CA) associe une identité à une paire de clés cryptographiques. Lorsqu’une CA délivre un certificat, elle fait une déclaration vérifiable : « J’ai confirmé que cette clé publique appartient à cette entité. » Toute personne qui fait confiance à la CA peut alors se fier à cette déclaration, ce qui permet à des tiers d’établir des connexions sécurisées sans avoir de relation préalable.

Le terme « CA » peut désigner à la fois l'organisme qui certifie les identités et l'infrastructure serveur utilisée pour émettre et gérer les certificats. Qu'elle soit gérée par un fournisseur international ou déployée en interne par l'équipe informatique d'une entreprise, sa fonction reste la même : authentifier une entité, émettre un certificat signé et gérer ce certificat tout au long de son cycle de vie.

Pourquoi les autorités de certification sont-elles nécessaires ?

Les autorités de certification ont pour rôle de résoudre efficacement un problème fondamental de la cryptographie à clé publique : comment savoir si une clé publique appartient bel et bien à l'entité à laquelle elle prétend appartenir ?

La cryptographie à clé publique permet à deux parties de communiquer en toute sécurité sans avoir à partager au préalable une clé secrète, mais elle présente une faille majeure. Si vous recevez une clé publique prétendant provenir de votre banque, rien dans la clé elle-même ne permet de vérifier cette affirmation. Un pirate pourrait présenter sa propre clé, se faire passer pour la banque et intercepter l'intégralité de votre connexion. La cryptographie garantit la validité des calculs, mais pas l'identité de celui qui les effectue.

En l'absence d'un tiers de confiance chargé de vérifier les identités, les organisations s'exposent à de graves risques :

• Attaques de type « homme du milieu » :un pirate intercepte la communication entre deux parties et se fait passer pour chacune d'elles auprès de l'autre.
• Usurpation d'identité :des acteurs malveillants présentent des identifiants frauduleux qui semblent légitimes, ce qui leur permet d'accéder sans autorisation à des systèmes et à des données.
• Interception de données :les informations sensibles transmises via des connexions non vérifiées peuvent être interceptées et exploitées.

Les autorités de certification (CA) résolvent ces problèmes en jouant le rôle de tiers de confiance qui garantissent le lien entre une identité et une clé publique. La CA vérifie qu’une entité est bien celle qu’elle prétend être, puis délivre un certificat signé numériquement attestant de ce lien. Comme la CA signe avec sa propre clé privée, n’importe qui peut vérifier l’authenticité du certificat à l’aide de la clé publique bien connue de la CA. Vous n’avez pas besoin de faire confiance à l’entité qui présente le certificat ; il vous suffit de faire confiance à l’autorité de certification qui s’en est portée garante.

C'est ce modèle qui permet de rendre la confiance évolutive. Plutôt que chaque partie doive établir individuellement une relation de confiance avec toutes les autres (ce qui est impossible à l'échelle d'Internet, voire au sein d'une entreprise moderne), chacun s'appuie sur un ensemble relativement restreint d'autorités de certification (CA). Les systèmes d'exploitation et les navigateurs sont livrés avec un ensemble préinstallé d'autorités de certification racines de confiance, et cette base commune permet chaque jour à des milliards de connexions de s'établir en toute sécurité.

Fonctionnement d'une autorité de certification

Le processus de délivrance des certificats suit une séquence bien définie. La compréhension de chaque étape permet de mieux saisir comment les autorités de certification (CA) établissent et vérifient la confiance.

Étape 1 : Générer une paire de clés.
Le demandeur crée une paire de cléspublique et privée. La clé privée reste secrète et ne quitte jamais le contrôle du demandeur.

Étape 2 : Créer une demande de signature de certificat (CSR).
Le demandeur génère une CSR contenant sa clé publique et des informations d'identification (telles qu'un nom distinctif pour un certificat X.509). La CSR est signée à l'aide de la clé privée du demandeur afin d'en prouver la possession.

Étape 3 : Envoyer la CSR à l'autorité de certification.
Le demandeur envoie la CSR à l'autorité de certification, accompagnée de toute pièce d'identité requise. Selon le type de certificat, l'autorité de certification peut exiger des documents juridiques, une vérification de la propriété du domaine ou une validation de l'organisation.

Étape 4 : L'autorité de certification valide la demande.
L'autorité de certification examine la demande de certificat (CSR), vérifie l'identité du demandeur et s'assure que la demande est conforme à ses politiques d'émission.

Étape 5 : L'autorité de certification (CA) signe et renvoie le certificat.
Une fois validé, l'autorité de certification signe le certificat à l'aide de sa propre clé privée et renvoie le certificat finalisé au demandeur. Le certificat peut désormais être déployé sur des serveurs, des appareils ou des applications.

Dans IoT , ce processus est adapté à la fabrication des appareils. Dans certains cas, la « racine de confiance » (Root of Trust) de l’appareil génère une paire de clés ECC et une demande de certificat (CSR), qui sont ensuite transmises à l’ PKI du fournisseur. L’autorité intermédiaire d’attestation de produit (PAI) signe la demande et délivre un certificat d’attestation d’appareil (DAC) qui est stocké de manière sécurisée sur l’appareil.

Le rôle des clés publiques et privées

La cryptographie asymétrique est à la base de l'ensemble du processus d'autorité de certification (CA). Chaque autorité de certification dispose de sa propre paire de clés : une clé privée utilisée pour signer les certificats et une clé publique largement diffusée afin que tout le monde puisse vérifier ces signatures.

Lorsqu’une autorité de certification (CA) émet un certificat, elle génère une signature numérique en chiffrant un hachage du contenu du certificat à l’aide de sa clé privée. Tout destinataire peut alors vérifier cette signature à l’aide de la clé publique de l’autorité de certification. Si la vérification aboutit, la signature est valide et le certificat est fiable.

Ce mécanisme garantit que les certificats ne peuvent pas être falsifiés. Seule l'autorité de certification (CA) détenant la clé privée peut générer une signature valide, tandis que toute personne disposant de la clé publique peut la vérifier.

La hiérarchie de confiance des autorités de certification

Le modèle de confiance des autorités de certification (CA) repose sur une hiérarchie à plusieurs niveaux qui concilie sécurité et souplesse opérationnelle. Les chaînes de confiance partent d'une autorité de certification racine unique, passent par des autorités intermédiaires, pour aboutir aux certificats installés sur les terminaux.

Autorités de certification racines

L'autorité de certification racine se situe au sommet de la hiérarchie et sert de point d'ancrage de confiance. Pour qu'un certificat d'entité finale soit considéré comme fiable, il doit être lié à une autorité de certification racine intégrée au système d'exploitation, au navigateur ou à l'appareil chargé de valider ce certificat.

Les autorités de certification racines (CA racines) sont hautement sécurisées et généralement conservées hors ligne. Leurs clés privées sont stockées dans des installations conformes aux normes GSA, soumises à des contrôles stricts. Étant donné que la compromission d'une CA racine compromettrait tous les certificats de sa hiérarchie, les CA racines délivrent rarement des certificats directement. Elles délèguent plutôt cette responsabilité à des autorités de certification subordonnées.

Autorités de certification intermédiaires, subordonnées et émettrices

Les autorités de certification intermédiaires (CA intermédiaires) interviennent entre l'autorité de certification racine et les certificats des entités finales. Leur rôle principal consiste à définir et à autoriser les types de certificats pouvant être demandés à l'autorité de certification racine. On les appelle également « autorités de certification subordonnées », car leur propre certificat a été signé par une autre autorité de certification.

Les organisations déploient généralement des autorités de certification subordonnées distinctes à des fins différentes. Dans les hiérarchies publiques, par exemple, les autorités de certification subordonnées TLS S/MIME doivent être séparées. Parmi les autres configurations courantes, on peut citer des autorités subordonnées distinctes pour différentes zones géographiques, ou une autorité subordonnée pour les certificats utilisant des clés ECC et une autre pour les clés RSA.

Une autorité de certification intermédiaire dédiée à la signature de certificats pour les utilisateurs finaux (entités finales) est appelée « autorité de certification émettrice ». Une autorité de certification émettrice est donc presque toujours une autorité de certification subordonnée, car les autorités de certification racines délivrent rarement des certificats aux utilisateurs finaux.

Certificats d'entité finale

Les entités finales correspondent aux utilisateurs finaux mentionnés plus haut. Les certificats d’entités finales constituent le dernier maillon de la chaîne de confiance ; on les appelle également les « feuilles » de la PKI . Il s’agit des certificats installés sur les serveurs, les machines, hardware cryptographique et les périphériques. Ils représentent l’identité d’un point d’extrémité spécifique et permettent à ce dernier d’établir des connexions authentifiées et chiffrées.

Chaque certificat d'entité finale est relié, par le biais d'une ou plusieurs autorités de certification intermédiaires, à une autorité de certification racine de confiance. C'est en vérifiant cette chaîne que les systèmes s'assurent de la légitimité d'un certificat.

Types d'autorités de certification

Autorités de certification publiques

Les autorités de certification publiques sont considérées comme fiables par défaut dans les navigateurs, les systèmes d'exploitation et les appareils. Elles délivrent des certificats pour les sites web, les applications et les services accessibles au public, où les utilisateurs externes et les clients doivent pouvoir vérifier l'identité du serveur sans aucune configuration manuelle.

Les organisations font appel à des autorités de certification publiques (telles que DigiCert) pour obtenir TLS qui sécurisent les interactions avec leurs clients. Ces autorités de certification publiques sont soumises à une gouvernance externe stricte, notamment aux exigences de base du CA/Browser Forum, et leurs certificats sont enregistrés via le programme « Certificate Transparency » afin de garantir la traçabilité.

Autorités de certification privées

Les autorités de certification privées sont gérées en interne par les organisations afin de délivrer des certificats destinés à des cas d'utilisation ne nécessitant pas de confiance publique. Parmi les utilisations courantes des autorités de certification privées, on peut citer :

• Communications sécurisées entre les services internes, y compris les environnements cloud conteneurisés et connectés via des API
• Sites intranet
• Certificat de réseau privé virtuel (VPN) ou authentification sans fil
• Identification de l'appareil
• Charges de travail et identification des conteneurs
• IoT (Internet des objets) projets

Avec une autorité de certification (CA) privée, l'organisation devient sa propre référence de confiance. Elle détermine quelles identités sont valides, délivre des certificats à ses propres services et appareils, et contrôle l'ensemble de la hiérarchie de confiance. C'est pourquoi une CA privée peut authentifier des communications de machine à machine qu'aucune CA publique ne cautionnerait jamais, permettant ainsi la mise en place d'architectures« zero trust »sur les réseaux internes.

Comment choisir entre une autorité de certification publique et une autorité de certification privée

Le choix entre une autorité de certification publique et une autorité de certification privée dépend en fin de compte de l'identité de celui qui doit faire confiance au certificat.

Dimension	AC Publique	AC Privée
Qui s'y fie ?	Reconnu comme fiable par tous grâce aux répertoires de certificats racine préinstallés dans les navigateurs, les systèmes d'exploitation et les appareils	N'est considéré comme fiable que par les systèmes explicitement configurés pour faire confiance à votre racine
Cas d'utilisation principal	Services destinés aux utilisateurs : sites web publics, API clients, serveurs de messagerie	Infrastructure interne : mTLS, authentification de service à service, VPN, identité des appareils et des charges de travail
Référence de confiance	L'autorité de certification publique (tiers externe)	Votre organisation
Vérification de l'identité	Validation obligatoire du domaine/de l'organisation conformément à des règles externes	Quel que soit le système d'identification que vous définissez (noms d'hôtes internes, comptes de service, identifiants de périphériques)
Règles applicables	Exigences de base du CA/Browser Forum, normes obligatoires	Votre propre politique interne
Durée de validité des certificats	Imposée par des facteurs externes, elle tend à se raccourcir progressivement	Réglez ce paramètre en fonction de votre environnement
Exploitation forestière publique	Enregistré via Certificate Transparency	Aucune information n'a été publiée
Modèle de coûts	Tarification par certificat (ou formules gratuites comme Let’s Encrypt)	Aucun coût par certificat ; vous prenez en charge les coûts d'infrastructure et d'exploitation
Économies d'échelle	Ce n'est pas une solution viable pour des milliers de certificats à courte durée de vie	Conçu pour la diffusion interne à grande échelle
Contrôle	Limitée, soumise à la politique extérieure	Contrôle total sur les règles, la mise en œuvre et la hiérarchie

Le principe est le suivant : une autorité de certification publique (CA) échange le contrôle contre une confiance universelle et une externalisation des opérations, tandis qu’une autorité de certification privée (CA) échange la charge opérationnelle contre un contrôle total et des économies d’échelle internes. La plupart des organisations exploitent les deux, chacune correspondant à une frontière de confiance distincte.

Types d'autorités de certification selon le format des certificats

Au-delà de la distinction entre autorités de certification publiques et privées, celles-ci peuvent également être classées en fonction des types de certificats qu'elles délivrent.

Autorités de certification X.509

X.509 est le type d'autorité de certification (CA) le plus courant ; il est utilisé pour la messagerie électronique sécurisée, la connexion, l'authentification Web, les VPN et bien d'autres applications, comme le définit la RFC 5280. Les certificats X.509 constituent le format standard SSL et sont à la base de la plupart PKI . Ils définissent la structure des certificats numériques, notamment les noms distinctifs, les durées de validité, les extensions et les algorithmes cryptographiques utilisés pour la signature.

Autorités de certification CVC

Les autorités de certification (CA) CVC délivrent des certificats « Card Verifiable » (CV), qui sont des certificats spécialisés conçus pour les passeports électroniques de l'UE dotés du contrôle d'accès étendu (EAC). Ces certificats permettent une vérification électronique sécurisée de l'identité dans le cadre des contrôles aux frontières et des systèmes d'identification gouvernementaux.

Autorités de certification SSH

Les autorités de certification SSH (SSH CA) émettent des certificats dans un format propre au protocole SSH, offrant ainsi une alternative à l'authentification traditionnelle par clé SSH. Plutôt que de distribuer des clés publiques individuelles à chaque serveur, les entreprises peuvent recourir à une autorité de certification SSH pour émettre des certificats à durée de vie limitée qui sont automatiquement considérés comme fiables par tout serveur configuré pour reconnaître cette autorité.

Autorités de certification pour l'enregistrement dans les systèmes C-ITS

Les certificats C-ITS (systèmes de transport intelligents coopératifs) utilisent un format défini par l'Union européenne pour les communications « Vehicle-to-Everything » (V2X). Ces certificats spécialisés permettent une communication sécurisée entre les véhicules, les infrastructures et les systèmes de gestion du trafic, et jouent un rôle essentiel dans la sécurité automobile et des transports.

Conformité des autorités de certification et normes de sécurité

Les autorités de certification (CA) doivent respecter des normes rigoureuses en matière de sécurité et de conformité afin de préserver la confiance. Les cadres régissant les activités des CA englobent les réglementations sectorielles, les normes techniques et les exigences de sécurité physique.

Normes sectorielles et réglementaires

Les autorités de certification opèrent dans le respect de plusieurs cadres réglementaires, en fonction de leur contexte de déploiement :

• DORA(loi sur la résilience opérationnelle numérique) : s'applique aux entités du secteur financier dans toute l'Union européenne et impose des mesures de résilience numérique, notamment en matière de PKI .
• NIS2(directive relative à la sécurité des réseaux et de l'information) : étend les exigences en matière de cybersécurité à l'ensemble des entités essentielles et importantes de l'UE.
• HIPAA(Health Insurance Portability and Accountability Act) : impose le chiffrement et des contrôles d'identité pour les données de santé, ce qui a une incidence directe sur la manière dont les autorités de certification (CA) sont déployées dans les environnements médicaux.
• PCI/DSS(Payment Card Industry Data Security Standard) : impose le chiffrement des données des titulaires de cartes, ce qui nécessite des opérations de certification (CA) robustes pour les systèmes de traitement des paiements.
• FedRAMP(Federal Risk and Authorization Management Program) : définit les normes de sécurité applicables aux services cloud utilisés par les agences fédérales américaines.
• FIPS 140-2, 140-3 :La norme FIPS 140-2 définit les exigences de sécurité applicables aux modules cryptographiques, notamment au hardware software par les autorités de certification (CA) pour la génération et le stockage des clés. Ces exigences sont reprises dans la norme FIPS 140-3, où elles sont, à certains égards, renforcées.

Exigences de base du CA/Browser Forum

Le CA/Browser Forum définit des normes que toutes les autorités de certification reconnues par le public doivent respecter. Ces « exigences de base » régissent les pratiques d'émission des certificats, les procédures de validation et les contraintes techniques.

L'une des exigences notables concerne l'entropie du numéro de série des certificats. Les certificats conformes doivent comporter au moins 64 bits d'informations entièrement aléatoires dans leur numéro de série. Cela permet de se prémunir contre les attaques par collision basées sur des fonctions de hachage visant la signature du certificat, renforçant ainsi la PKI les attaques par préimage.

Modules Hardware et protection des clés

Les autorités de certification (CA) s'intègrent aux modules hardware (HSM) pour assurer le stockage sécurisé des clés et les opérations cryptographiques. Les HSM offrent des environnements inviolables dans lesquels les clés privées sont générées, stockées et utilisées sans jamais être exposées en clair.

La maintenance des infrastructures pour les déploiements d'autorités de certification (CA) à haut niveau de sécurité comprend des autorités de certification racines hors ligne hébergées dans des installations physiquement sécurisées, dotées de contrôles d'accès stricts, d'une surveillance environnementale et d'un journal d'audit. Cette approche par couches garantit que, même en cas de compromission des systèmes opérationnels, l'ancrage de confiance racine reste protégé.

Protocoles des autorités de certification et intégration technique

Les autorités de certification (CA) prennent en charge toute une gamme de protocoles d'inscription et de gestion qui permettent d'automatiser les opérations liées aux certificats à grande échelle. Le choix du protocole approprié dépend de l'environnement, des appareils concernés et du niveau d'automatisation requis.

Protocoles d'inscription courants

• SCEP(Simple Certificate Enrollment Protocol) : largement utilisé pour l'enregistrement des appareils, notamment dans le domaine des infrastructures réseau et de la gestion des appareils mobiles. Le protocole SCEP permet aux appareils de demander et de recevoir des certificats avec un minimum d'intervention manuelle.
• CMP(Certificate Management Protocol) : protocole normalisé prenant en charge l'ensemble du cycle de vie des certificats, notamment leur émission, leur renouvellement, leur révocation et la récupération des clés.
• EST(Enrollment over Secure Transport) : protocole d'inscription moderne TLS, conçu pour remplacer le SCEP tout en offrant une sécurité renforcée. L'EST utilise le protocole HTTPS pour le transport et prend en charge le renouvellement des certificats ainsi que la réinscription.
• ACME(Automatic Certificate Management Environment) : permet la délivrance et le renouvellement entièrement automatisés des certificats ; cette technologie est le plus souvent associée à Let’s Encrypt, mais elle est de plus en plus utilisée pour PKI internes.
• Inscription automatique Microsoft :intègre le déploiement des certificats à Active Directory, ce qui permet de délivrer automatiquement des certificats aux ordinateurs et aux utilisateurs membres du domaine, en fonction des paramètres de stratégie de groupe.

Formats des certificats

Le format de certificat X.509 (défini dans la RFC 5280) est la structure la plus couramment utilisée pour les certificats numériques. Un certificat X.509 comprend des champs tels que le nom distinctif du sujet, le nom distinctif de l'émetteur, la période de validité (dates de début et de fin), la clé publique du sujet, un numéro de série et la signature numérique de l'autorité de certification. Parmi les autres formats de certificats courants, on peut citer les certificats OpenPGP, les certificats OpenSSH, les certificats CVC, etc.

La CSR (demande de signature de certificat) qui lance le processus d'émission contient des informations d'identification concernant le demandeur (telles qu'un nom distinctif) ainsi que la clé publique choisie par ce dernier. La CSR doit être signée avec la clé privée du demandeur afin de prouver qu'il est bien en possession de cette clé.

Autorités de certification et nouveaux cas d'utilisation

Identité IoT

Dans IoT , les autorités de certification (CA) constituent le fondement del'identité sécurisée des appareils. Chaque appareil se voit attribuer un certificat unique lors de sa fabrication ou de sa mise en service, ce qui permet l'authentification mutuelle entre les appareils et les services.

Une mise en œuvre typique de la hiérarchie des autorités de certification (CA) au sein d’un IoT se présente comme suit : une autorité de certification racine (CA racine, maintenue hors ligne) délivre des certificats à une autorité d’attestation de produit (PAA), qui délègue à des intermédiaires d’attestation de produit (PAI) pour différents types de produits. Chaque PAI délivre un certificat d’attestation de périphérique (DAC) unique à chaque périphérique physique. La racine de confiance de l’appareil génère une paire de clés publique/privée ainsi qu’une demande de certificat (CSR), que l’infrastructure PKI du fournisseur PKI et renvoie sous la forme du DAC.

Cette approche garantit que chaque appareil connecté dispose d'une identité unique et vérifiable, ancrée dans une chaîne de certificats fiables, depuis l'appareil lui-même jusqu'à l'autorité de certification racine du fabricant.

État de préparation à la cryptographie post-quantique

À mesure que l'informatique quantique progresse, les autorités de certification (CA) doivent se préparer à la transition vers des algorithmes résistants aux attaques quantiques. Les algorithmes à clé publique actuels (RSA, ECDH, ECDSA, etc.) sont vulnérables aux attaques menées par des ordinateurs quantiques suffisamment puissants, ce qui signifie que les certificats émis aujourd'hui par les CA pourraient à terme être compromis.

Les plateformes CA modernes prennent déjà en charge les algorithmesde cryptographie post-quantique. Par exemple, EJBCA des algorithmes de signature post-quantique tels que DILITHIUM5, qui ne peuvent être utilisés qu’en association avec des clés DILITHIUM5. L’émission de certificats hybrides, qui combine des signatures classiques et des signatures résistantes à l’informatique quantique au sein d’un même certificat, est également disponible, ce qui permet aux organisations de bénéficier d’une « crypto-agilité » face à la menace quantique.

Comment Keyfactor vous aider

La gestion des autorités de certification à grande échelle ne se limite pas à des processus manuels. Keyfactor uneplateformeunifiée destinée aux organisations qui exploitent des autorités de certification publiques, privées ou les deux.

• EJBCA :Une PKI d’autorité de certification (CA) et PKI complète et évolutive, prenant en charge les types de certificats X.509, CVC, SSH et C-ITS. EJBCA des contrôles de sécurité intégrés, des fonctionnalités d’automatisation et la gestion du cycle de vie, tout en prenant en charge plusieurs autorités de certification (CA), autorités de validation et autorités d’enregistrement au sein d’un même déploiement.
• Keyfactor Command:visibilité et gestion centralisées de toutes les autorités de certification (CA) depuis un seul et même écran. Command les CA publiques (telles que DigiCert), les CA Microsoft et les CA privées internes, offrant ainsi un inventaire des certificats en temps réel, une analyse automatisée, une surveillance et des fonctionnalités de renouvellement en un clic. Il intègre également des autorités de certification utilisant la cryptographie post-quantique, notamment celles recourant à MLDSA-65 et à des algorithmes hybrides, offrant ainsi aux organisations une voie vers la préparation quantique au sein de leur infrastructure d’autorités de certification existante. Les administrateurs peuvent configurer des plannings d’analyse, définir des seuils d’alerte en cas d’émission massive de certificats et gérer le cycle de vie des certificats à l’échelle de l’ensemble de l’organisation.
• PKI service:Associe PKI gérée PKI l'automatisation de la gestion des certificats, ce qui réduit la charge opérationnelle liée à l'exploitation d'une infrastructure d'autorité de certification (CA) interne tout en conservant un contrôle total sur le cycle de vie des certificats.
• Crypto-agilité et préparation à l'ère post-quantique :la prise en charge des certificats hybrides et des algorithmes résistants à l'informatique quantique permet aux organisations d'adapter leur infrastructure d'autorité de certification (CA) à mesure que les normes cryptographiques évoluent.

Demandez une démonstrationpour découvrir comment Keyfactor moderniser vos opérations d'autorité de certification et préparer votre PKI l'avenir.