Qu'est-ce qu'un certificat « SSL » ?

Chaque fois que vous saisissez un mot de passe, que vous envoyez un formulaire ou que vous effectuez un paiement par carte bancaire, vous partez du principe que la connexion entre votre navigateur et le site web est sécurisée. C'est le certificat « SSL » qui rend cette confiance possible. Il s'agit de l'une des technologies de sécurité les plus répandues sur Internet, mais elle est souvent mal comprise, en partie parce que le secteur continue de l'appeler «SSL», alors que le protocole sous-jacent a changé il y a plusieurs années.

Qu'est-ce qu'un certificat « SSL » ?

Un certificat « SSL » est un identifiant numérique qui lie l’identité d’un site web à une clé publique. Le chiffrement proprement dit est assuré par le protocole TLS , qui utilise cette clé publique lors de la négociation pour authentifier le serveur et établir les clés de session. Le rôle du certificat est plus restreint, mais tout aussi important : il donne au client une raison de croire que la clé appartient bien au site qu’il pense visiter, et non à un attaquant qui se serait interposé. Il instaure la confiance.

Le terme «SSL» relève quelque peu de l’héritage historique. Comme mentionné précédemment, le protocole associé est TLS. « SSL » signifie « Secure Sockets Layer », le protocole cryptographique d’origine destiné à l’authentification et au chiffrement des communications sur un réseau. Ce protocole a été remplacé il y a quelque temps par son successeur, plus avancé et plus sécurisé : le protocole TLS (Transport Layer Security). Malgré cela, l’expression « certificatSSL » reste l’abréviation couramment utilisée dans le secteur, et la plupart des gens parlent encore de SSL alors qu’ils font techniquement référence à TLS. Tout au long de ce guide, les expressions « certificatSSL » ou «SSL/TLS» désignent les certificats qui sécurisent aujourd’hui les connexions TLS .

Pour les organisations, un certificat SSL/TLS est bien plus qu'un simple outil de chiffrement. Il garantit l'intégrité des données, permet l'authentification et sécurise les transactions en ligne, ce qui en fait un pilier fondamental de la confiance numérique. C'est grâce à lui que les utilisateurs, les partenaires et les systèmes peuvent interagir en toute sécurité sur Internet.

Il convient également de clarifier un point qui prête souvent à confusion : tous les certificats SSL/TLS respectent lanorme de certificat X.509, c’est-à-dire le format qui définit la structure des champs et des informations d’identité du certificat. X.509 est la spécification générale, et SSL/TLS n’est qu’un exemple parmi tant d’autres de son utilisation. En d’autres termes, tous les certificats SSL sont des certificats X.509, mais les certificats X.509 sont également utilisés pour la signature d’e-mails, la signature de code, les VPN, l’identité des appareils, etc.

Une brève histoire d'SSL , et TLS

SSL a été développé par Netscape dans les années 1990 afin de chiffrer et de sécuriser les communications sur Internet. La version 1.0 d’ SSL n’a jamais été commercialisée en raison de failles de sécurité ; la version 2.0 d’ SSL , sortie en 1995, présentait quant à elle d’importantes faiblesses ; enfin, la version 3.0 d’ SSL , lancée en 1996, a apporté les améliorations majeures qui ont façonné les communications sécurisées sur le Web. En 2015, SSL v3.0 et les versions antérieures avaient été dépréciées, et en 2020, SSL a été définitivement retiré.

Alors que Netscape perfectionnait le protocole SSL, l’Internet Engineering Task Force a développé le protocole TLS pour lui succéder. Le protocole TLS est essentiellement une version plus récente et plus sécurisée du protocole SSL: la version TLS 1.0 a vu le jour en 1999 (basée sur la version 3.0 du protocole SSL ), suivie par la version TLS 1.1 en 2006, puis par la version TLS 1.2 en 2008, qui a longtemps été utilisée. Le nom «SSL» s’est tout simplement imposé dans l’usage courant, ce qui explique pourquoi on parle encore de « certificatSSL » alors que la connexion s’effectue en réalité sur TLS.

La norme actuellement en vigueur est la version 1.3 de l'TLS , finalisée en 2018 et qui sécurise désormais la plupart des connexions modernes. Elle est aujourd'hui plus rapide et plus sûre que jamais. Pour une comparaison plus complète des deux protocoles, consultez nos articles complémentaires sur SSL et TLS.

Fonctionnement des certificats « SSL » / «TLS »

Un certificat « SSL » / «TLS » sécurise les communications en combinant deux types de cryptographie et deux protocoles distincts. C'est en comprenant ces deux éléments que l'on peut saisir pourquoi cette technologie est si efficace.

À un niveau général, le protocole SSL ( TLS ) établit une connexion sécurisée au niveau de la couche de transport entre deux points d'extrémité : un serveur et un client. Cette connexion s'établit généralement entre le serveur d'un site web et un navigateur, ou entre un serveur de messagerie et une application de messagerie telle qu'Outlook. Pour fonctionner, le protocole SSL ( TLS ) s'appuie sur deux protocoles distincts :

• Le protocole de poignée de mainauthentifie le serveur (et, éventuellement, le client), négocie les méthodes cryptographiques à utiliser et génère une clé partagée.
• Le protocole d'enregistrementisole chaque connexion et utilise cette clé partagée pour sécuriser les communications pendant le reste de la session.

La poignée de main : le moment où la confiance s'instaure

La négociation HTTPS ( TLS ) est un processus cryptographique asymétrique qui établit un canal sécurisé entre le serveur et le client. Toute connexion HTTPS commence par cette négociation. Au cours de celle-ci, le serveur détient une clé privée tandis que le client reçoit la clé publique correspondante dans le certificat SSL/TLS , qu’il utilise ensuite pour authentifier le serveur et confirmer son identité. Outre le fait que le client puisse authentifier le serveur, les deux parties établissent également des clés de session lors de la négociation, qu’elles utilisent pour chiffrer la communication par la suite.

Une négociation de connexion réussie s'effectue instantanément et automatiquement en arrière-plan, sans perturber l'expérience utilisateur. En revanche, une négociation de connexion qui échoue met fin à la connexion et déclenche généralement l'affichage d'un message d'avertissement dans le navigateur.

Lorsque la procédure d'établissement de la connexion aboutit, elle offre trois avantages en matière de sécurité :

• Authentification :l'identité du serveur est vérifiée tant que la connexion est valide.
• Confidentialité :les données sont chiffrées et ne sont visibles que par le serveur et le client.
• Intégrité :les signatures numériques garantissent que les données n'ont pas été altérées pendant leur transfert.

Une fois que la procédure d'établissement de connexion a permis de définir une clé de session partagée, la cryptographie asymétrique a rempli sa fonction. C'est alors que le protocole de transmission prend le relais, en utilisant un chiffrement symétrique plus rapide pour protéger le flux de données pendant le reste de la session.

Le certificat lui-même contient les informations d'identification dont un navigateur a besoin pour vérifier votre identité, ainsi que la clé publique, une date d'expiration et d'autres informations importantes. Si vous souhaitez examiner ces éléments concrètement, notre guide surla vérification d'un certificat SSL vous explique en détail la signification de chaque élément et comment les consulter dans votre navigateur.

Infrastructure à clé publique et SSL

SSL/ Les certificatsTLS ne fonctionnent pas de manière isolée. Ils s’inscrivent dans un cadre plus large appelé « infrastructure à clé publique » (PKI), qui assure la sécurité grâce au chiffrement et gère les certificats numériques tout au long de leur cycle de vie. Lorsque vous recevez un certificat SSL/TLS d’une autorité de certification (CA), vous l’installez sur votre serveur, généralement en même temps qu’un certificat intermédiaire qui relie votre certificat à la racine de confiance de l’autorité. Tous ces éléments et procédures relèvent de l’ PKI.

La meilleure façon de se représenter l'PKI , c'est de la considérer comme un « Service des immatriculations » numérique. Ce service vérifie votre identité avant de délivrer un permis, et le permis qu'il vous remet est bien plus qu'une simple attestation de votre nom. Il comporte votre photo, ce qui en fait un document utile : n'importe qui peut ainsi vérifier que la personne qui présente le permis est bien celle à qui il a été délivré.

Un certificat « SSL » / «TLS » fonctionne de manière similaire. Une autorité de certification vérifie l’identité d’un site web et délivre un certificat contenant la clé publique du site, qui équivaut à la photo sur le certificat. N’importe qui peut vérifier que le serveur présentant le certificat détient bien la clé privée correspondante. Et tout comme un permis, un certificat mentionne le nom de son titulaire, comporte une date d’expiration et peut être révoqué avant cette date en cas de problème.

La chaîne de confiance

Pour qu’un certificat SSL/TLS soit considéré comme fiable, il doit être issu d’une autorité de certification racine (CA) de confiance. Ce lien est appelé « chaîne de confiance ». Au cœur de chaque PKI se trouve l’autorité de certification racine, qui constitue la source de confiance garantissant l’intégrité de l’ensemble du système. Lorsqu’une autorité de certification racine signe un certificat, elle initie la chaîne. Si cette autorité de certification racine bénéficie d’une confiance publique, tout certificat valide qui lui est lié est automatiquement considéré comme fiable par les principaux navigateurs et systèmes d’exploitation.

Les navigateurs vérifient automatiquement cette chaîne. Votre navigateur connaît déjà les clés publiques d’une poignée d’autorités de certification (CA) de confiance. Lorsqu’il reçoit le certificat d’un site web, il utilise ces clés pour vérifier la signature du certificat, puis répète le processus pour chaque certificat de la chaîne jusqu’à ce qu’il atteigne une autorité de certification racine qu’il reconnaît. C’est exactement ce qui se passe derrière l’icône du cadenas dans votre barre d’adresse : une vérification rapide et récursive visant à s’assurer que le certificat sur lequel vous vous appuyez provient d’une source fiable. Pour mieux comprendrele fonctionnement des chaînes de confiance et des autorités de certificationau niveau des spécifications, consultez notre guide X.509.

Types de certificats « SSL »

L'un des aspects les plus mal compris des certificats SSL/TLS est le fait qu'il en existe différents types. Il est utile de préciser ce qui les distingue. Le type d'un certificat relève d'une distinction procédurale, et non cryptographique. Chaque certificat SSL/TLS , quel que soit son type, utilise le même chiffrement, la même chaîne de confiance et la même procédure d'authentification. Ce qui change d'un type à l'autre, ce sont les informations recueillies par l'autorité de certification avant la signature.

Il existe trois types, chacun étant défini par une condition et une vérification différentes :

• Validation par domaine (DV) :l'autorité de certification (CA) vérifie que le demandeur contrôle bien le domaine, généralement par le biais d'une simple vérification de l'enregistrement « DNS ». Il s'agit du type de certificat le plus rapide et le plus basique ; il est souvent délivré en quelques minutes et ne comporte aucune information sur l'organisation. Les certificats DV conviennent davantage aux sites personnels ou internes qu'aux sites web d'entreprise destinés au grand public. Pour en savoir plus sur la validation par domaine, consultez notrepage dédiée.
• Validation de l'organisation (OV) :l'autorité de certification (CA) vérifie le contrôle du domaine ainsi que l'existence légale de l'organisation, en recoupant son identité avec les registres administratifs et en exigeant des documents supplémentaires. Les informations relatives à l'organisation figurent sur le certificat, ce qui renforce la confiance des visiteurs. La validation OV convient particulièrement aux sites commerciaux qui collectent des données utilisateur. Consultez notre page consacrée àla validation de l'organisationsi ce sujet vous intéresse.
• Validation étendue (EV) :le type de certificat le plus rigoureux. L’autorité de certification (CA) procède à un examen approfondi de l’existence juridique, physique et opérationnelle de l’organisation, vérifie l’autorisation du demandeur et applique des contrôles de délivrance à deux personnes. La demande doit émaner de l’organisation elle-même. Les certificats EV sont régis par les directives EV du CA/Browser Forum, et les navigateurs peuvent afficher des indicateurs renforcés signalant ce niveau de confiance élevé. Pour en savoir plus, consultez notre analyse approfondie surla validation étendue.

Le type d'un certificat est également visible dans le certificat lui-même. Les informations relatives aux certificats OV et EV remplissent les champs « sujet » ; le certificat EV ajoute des attributs tels que le secteur d'activité de l'organisation, la juridiction de constitution et le numéro d'enregistrement, tandis qu'un identifiant de politique indique le type du certificat. Les parties de confiance reconnaissent les certificats EV en associant cet identifiant à une racine de confiance.

Le choix du type de certificat approprié dépend de l'objectif de votre site, de son profil de risque et du niveau de garantie d'identité dont vos utilisateurs ont besoin. Nous publierons prochainement un article détaillé consacré au choix et à la validation des certificats ; pour la plupart des organisations, la règle pratique est qu'un type de certificat plus rigoureux est synonyme d'une plus grande crédibilité, ce qui est particulièrement important lors du traitement de données sensibles ou de transactions financières. Pour en savoir plus sur la validation des certificats, consultez notrearticle de blog dédié.

Avantages des certificats « SSL » / «TLS »

La mise en place d'un certificat « SSL » / «TLS » offre des avantages qui vont bien au-delà de la simple icône du cadenas. Les quatre principaux sont la protection des données, la vérification d'identité, une meilleure visibilité dans les moteurs de recherche et la conformité réglementaire.

Cryptage des données sensibles

Le principal avantage d’un certificat SSL/TLS réside dans le fait qu’il crypte les données sensibles en transit, ce qui permet d’empêcher les attaques de type « homme du milieu » (MitM). Lors d’une attaque MitM, un pirate intercepte des informations destinées à un destinataire légitime, parfois en mettant en place un faux site qui incite les visiteurs à divulguer leurs identifiants ou leurs informations de paiement. Prenons l’exemple d’une connexion à un service bancaire en ligne : si quelqu’un intercepte ce trafic non chiffré, vos identifiants pourraient être exposés, ouvrant la voie à une usurpation d’identité ou à des pertes financières. Le protocole TLS empêche cela en chiffrant les données, de sorte que le trafic intercepté n’apparaît que comme un charabia incompréhensible, et en vérifiant l’identité du propriétaire du domaine afin que les visiteurs accèdent bien au site authentique.

Vérification de la propriété du site web

Un certificat « SSL » / «TLS » atteste qu’un site appartient bien à celui qui le revendique. Étant donné qu’une autorité de certification ne délivre le certificat qu’après avoir vérifié l’identité du demandeur et sa propriété du domaine, un certificat signé se porte en quelque sorte garant de l’organisation. Les navigateurs faisant confiance à l’autorité de certification, ils étendent cette confiance à l’organisation vérifiée, ce qui donne aux visiteurs l’assurance qu’ils ont affaire à une entreprise légitime.

Assurer la conformité réglementaire

La plupart des réglementations régissant les données sensibles ne mentionnent pas explicitement le protocole « TLS ». Elles exigent que les données en transit soient protégées par un système de cryptographie robuste, et le protocole « TLS » est le mécanisme retenu par le secteur pour répondre à cette exigence. La norme PCI DSS est la plus explicite en la matière : elle impose l’utilisation d’une cryptographie robuste lors de la transmission sur des réseaux publics ouverts et déconseille formellement l’utilisation des premières versions d’ TLS . La loi HIPAA considère la sécurité de la transmission comme une spécification à prendre en compte, ce qui autorise en principe des alternatives mais vous oblige à justifier par écrit pourquoi le chiffrement n’était pas approprié. Le RGPD cite le chiffrement comme un exemple de mesure technique appropriée plutôt que de le rendre obligatoire, bien que ses règles de notification des violations lui confèrent une réelle force d’application : les données rendues incompréhensibles pour une partie non autorisée modifient ce que vous êtes tenu de divulguer. Ce ne sont là que quelques exemples tirés d’une très longue liste de lois et de cadres de sécurité.

Le coût de ne pas en avoir un

Le protocole HTTPS a cessé d'être un facteur de différenciation il y a quelques années pour devenir la norme. Google a intégré le HTTPS comme critère de référencement mineur en 2014, mais son adoption quasi universelle aujourd'hui ne permet pratiquement plus de se démarquer. La situation s'est désormais inversée. Les navigateurs signalent les sites utilisant le protocole HTTP standard comme « non sécurisés », et un nombre croissant de fonctionnalités des plateformes web sont réservées aux sources sécurisées. Un certificat ne vous apporte plus d'avantage ; son absence vous pénalise.

Cas d'utilisation courants des certificats « SSL » / «TLS »

Bien que les certificats SSL/TLS soient particulièrement visibles sur les sites web, leurs applications s'étendent aussi bien aux environnements d'entreprise exposés à Internet qu'aux environnements internes. Le même protocole sous-jacent sécurise un éventail étonnamment large de connexions.

Sécurisation des sites Web et des applications Web

C'est le cas d'utilisation que la plupart des gens ont à l'esprit. Lorsqu'un certificat signé SSL/TLS sécurise un site web, cela prouve que l'organisation a authentifié son identité auprès d'un tiers de confiance, et le navigateur accorde alors sa confiance à cette organisation. Techniquement, le trafic web non sécurisé s'effectue via le protocole HTTP sur le port 80, un protocole en clair qu'un pirate peut relativement facilement intercepter et lire. Le protocole TLS utilise quant à lui le port 443, ce qui permet de chiffrer les échanges entre le navigateur et le serveur et d'authentifier la connexion. Lorsqu'une connexion sécurisée est requise, le navigateur bascule automatiquement vers cette connexion, à condition que le serveur dispose d'un certificat valide. En raison de la prolifération du phishing, les navigateurs tels que Chrome redirigent désormais vers le protocole HTTPS par défaut.

Applications d'entreprise et intranet

Les entreprises utilisent les certificats SSL/TLS bien au-delà de leurs sites Web publics. Parmi les cas d’utilisation internes courants, on peut citer les contrôles d’accès au réseau, l’authentification via un réseau privé virtuel (VPN) et les implémentations d’authentification unique (SSO). Dans chaque cas, une identité numérique remplace la complexité liée aux mots de passe longs et fréquemment renouvelés. L'association d'une identité numérique à un ordinateur de bureau, un serveur ou un point d'accès sans fil garantit que seuls les appareils autorisés peuvent se connecter aux ressources de l'entreprise, et les solutions d'authentification unique (SSO) s'appuient sur ce même modèle de confiance pour accorder l'accès à un portail ou à des services cloud.

Sécurité des appareils de l'Internet des objets (IoT)

SSL/ Les certificats «TLS » permettent également d’authentifier les appareils. Une identité numérique installée sur un appareil IoT garantit que seuls les appareils de confiance peuvent se connecter à un réseau, et authentifie les données que ces appareils échangent avec des applications autorisées. À mesure que le parc d’appareils connectés s’agrandit, cette identité basée sur des certificats devient essentielle pour empêcher toute hardware malveillante d’accéder au réseau.

Sécurité des e-mails et des communications

La même infrastructure PKI qui prend en charge TLS sert également de base à la sécurité des e-mails et des communications. Il convient de noter que les certificats de signature d'e-mails sont distincts des certificats SSL/TLS , car ils utilisent des fonctions d'utilisation de clé différentes, mais s'appuient sur la mê . Cela nous rappelle une fois de plus queles certificats X.509 et leurs cas d'utilisation courantsvont bien au-delà du navigateur Web.

Gestion à grande échelle des certificats « SSL » / «TLS »

Les définitions de base des certificats « SSL » / «TLS » évoquent rarement l’aspect le plus complexe : leur gestion. La plupart des organisations s’appuient sur des dizaines, voire des centaines de certificats répartis dans différents environnements, et veiller à ce qu’ils restent tous valides constitue un véritable défi opérationnel. Trois problèmes reviennent sans cesse, et le suivi manuel à l’aide de tableurs et de rappels de calendrier a tendance à devenir ingérable à mesure que le volume augmente.

Le problème lié à l'expiration des certificats

SSL/ Les certificats «TLS » n’ont pas une durée de validité illimitée, et leur date d’expiration arrive plus vite que jamais. Un seul renouvellement manqué entraîne des conséquences immédiates : les sites web et les applications peuvent cesser de fonctionner, les utilisateurs perdent confiance et votre niveau de sécurité s’en trouve compromis. Une solution de gestion des certificats assure le suivi des dates d’expiration de chaque certificat, ce qui permet aux équipes d’être prévenues bien à l’avance plutôt que de devoir se démener à la dernière minute. À mesure que la durée de validité des certificats diminue, cette fonctionnalité d’alerte précoce passe du statut de simple commodité à celui de nécessité.

Visibilité et étendue dans les différents environnements

À mesure que les inventaires de certificats s'étoffent, la visibilité s'amenuise. Les équipes sont souvent incapables de préciser combien de certificats elles gèrent, lesquels sont sur le point d'expirer ou où chacun d'entre eux est déployé. La prolifération aggrave le problème : les entreprises accumulent parfois plusieurs certificats sur un même domaine simplement pour éviter de le laisser sans protection pendant la période de renouvellement, ce qui ajoute un élément supplémentaire à gérer. En l'absence d'un inventaire clair, un seul certificat négligé peut provoquer une interruption de service.

Pourquoi l'automatisation est désormais indispensable

Les solutions de gestion des certificats résolvent ces problèmes en automatisant la détection, le suivi des expirations et en simplifiant la maintenance. La détection automatisée permet de constituer un registre précis et continuellement mis à jour de tous les certificats de l’entreprise, de sorte que ceux-ci soient émis et renouvelés au bon moment, sans intervention manuelle. Il en résulte une réduction des erreurs manuelles, une diminution des coûts de main-d'œuvre et un risque nettement moindre de subir une interruption de service coûteuse et évitable. C'est là l'aspect pratique et quotidien de la gestion du cycle de vie des certificats, et c'est sur ce plan que la plupart des organisations ressentent en premier lieu la pression.

Le passage à des durées de validité plus courtes pour les certificats SSL/TLS

Le changement le plus important qui se profile à l'horizon pour les certificats SSL est une réduction spectaculaire de leur durée de validité. En avril 2025, le CA/Browser Forum, l'organisme chargé d'établir les normes mondiales en matière de certificats numériques, a approuvé le projet SC-081v3, qui raccourcit la durée de validité maximale des certificats SSL/TLS faisant l'objet d'une confiance publique selon un calendrier fixe.

Selon ce calendrier, la durée de validité maximale diminuera progressivement par rapport au niveau actuel pour atteindre une fraction de ce qu’elle était auparavant :

• 200 jours au maximumavant le 15 mars 2026
• 100 jours au maximum, au plus tard le 15 mars 2027
• 47 jours au maximumavant le 15 mars 2029

Les implications opérationnelles sont considérables. Avec une durée maximale de 47 jours, les organisations devront renouveler chaque certificat environ huit fois plus souvent qu’avec l’ancienne durée maximale de 398 jours. Cela marque, en effet, la fin de la gestion des certificats selon le principe « configurez-le et n’y pensez plus ». Une tâche qui était auparavant une corvée annuelle devient un processus opérationnel quasi continu.

Pour les équipes informatiques et de sécurité, la réponse concrète consiste à se préparer dès maintenant plutôt que de réagir plus tard. Cela implique de dresser un inventaire complet des certificats existants, d’identifier les cas où des renouvellements manuels sont encore effectués et d’adopter l’automatisation avant que les délais plus courts n’entrent en vigueur. Des protocoles tels que l’ACME (Automated Certificate Management Environment) peuvent gérer automatiquement l’émission, le renouvellement et la révocation des certificats, et ils sont désormais largement pris en charge par les autorités de certification. Les équipes qui considèrentla gestion du cycle de vie des certificatscomme une discipline fondamentale et continue, plutôt que comme un événement annuel ponctuel, s'adapteront à ce changement bien plus facilement que celles qui s'appuient sur un suivi manuel.

Comment Keyfactor vous aider

Les défis abordés tout au long de ce guide, qu'il s'agisse de l'expiration, de la prolifération ou de l'accélération du rythme des renouvellements, mènent tous à la même conclusion : la gestion des certificats doit être axée sur la rapidité, la flexibilité et l'agilité cryptographique. « Keyfactor » aide les organisations à atteindre précisément cet objectif dans trois domaines complémentaires.

• Infrastructure moderne d’ PKI .
  Pour les organisations qui souhaitent émettre des certificats à l’échelle de l’entreprise, la solution de Keyfactor EJBCA est une plateforme d’ open-source et de gestion des identités ( PKI ) de niveau entreprise qui établit la confiance et délivre des identités au sein d’environnements vastes et complexes.
• Automatisation du cycle de vie des certificats. 
  Keyfactor Command Elle offre une visibilité de bout en bout, une détection et un renouvellement automatisés, afin que les équipes sachent à tout moment combien de certificats elles possèdent, où ils sont déployés et quand ils expirent. Cela résout directement les problèmes d’expiration, de prolifération et de visibilité qui font de la gestion manuelle un frein.
• PKI « as a Service ».
  Pour les équipes qui ont besoin d’une infrastructure de certificats robuste sans avoir à supporter la charge opérationnelle liée à sa gestion en interne, PKI « as a Service» propose à la fois une gestion de l’ PKI et une automatisation des certificats.

Dans leur ensemble, ces fonctionnalités reflètentl’approche adoptée parKeyfactorpour gérer la confiance numérique à grande échelle: aider les organisations à anticiper l’évolution de la durée de vie des certificats (47 jours), à prévenir les interruptions de service et à assurer le suivi de chaque certificat à mesure que leurs environnements se développent.