Qu'est-ce qu'une liste de révocation de certificats (CRL) ?

Pourquoi la révocation des certificats est-elle importante ?

Les certificats numériques servent à instaurer un climat de confiance dans les transactions en ligne. Ce n’est qu’une fois la confiance établie et l’identité de l’autre partie confirmée qu’il est possible de créer un canal de communication authentifié et chiffré. Ensemble, ces propriétés constituent le fondement de l’infrastructure à clé publique (PKI) qui sous-tend pratiquement toutes les interactions numériques sécurisées.

Chaque certificat est émis avec une durée de validité limitée, allant de quelques heures à plusieurs années selon la politique de l’autorité de certification émettrice. Il convient toutefois de noter que la durée de validité maximale d’un certificat numérique de confiance publique ne sera plus que de 47 jours à compter de mars 2029. Un certificat perd immédiatement toute valeur dès lors qu’il est établi que sa clé privée a été compromise, quelle que soit la durée restante de sa validité. La durée de validité perd toute pertinence dès lors que la base de confiance n’est plus assurée.

Une clé privée peut être compromise à la suite d'une faille de sécurité ou d'une mauvaise configuration. Un employé disposant d'un certificat client peut quitter l'entreprise. Une autorité de certification (CA) peut elle-même être amenée à retirer la confiance accordée aux certificats qu'elle a émis. En l'absence d'un mécanisme fiable permettant d'invalider les certificats avant leur date d'expiration normale, les entreprises restent exposées à des attaques exploitant des identifiants que l'infrastructure PKI considère plus comme fiables.

La révocation de certificats est ce mécanisme, et la liste de révocation de certificats (CRL) en est la mise en œuvre la plus ancienne et la plus répandue.

Qu'est-ce que la révocation d'un certificat ?

La révocation d'un certificat consiste à invalider un certificat numérique avant sa date d'expiration prévue. Il s'agit d'une opération fondamentale au sein PKI, qui garantit que les certificats qui ne sont plus considérés comme fiables ne puissent plus être utilisés pour authentifier des identités ou chiffrer des communications.

Pendant la durée de validité d’un certificat, le titulaire du certificat ou l’autorité de certification (CA) qui l’a émis peut estimer qu’il ne doit plus être considéré comme fiable. Dans ce cas, le certificat non fiable doit être révoqué et les parties qui s’y fient (navigateurs, serveurs, applications, etc.) doivent en être informées. Le principal mécanisme permettant de communiquer ce statut de révocation est la liste de révocation des certificats.

Dans une PKI bien gérée, la possibilité de révoquer la confiance est fondamentale. C'est ce mécanisme de contrôle qui garantit l'intégrité de la chaîne de confiance lorsque les conditions réelles évoluent plus rapidement que ne le permettent les durées de validité des certificats.

Qu'est-ce qu'une liste de révocation de certificats ?

Une liste de révocation de certificats peut être définie à plusieurs niveaux de précision :

Dans sa forme la plus simple, une liste CRL est une liste des numéros de série des certificats révoqués, publiée par une autorité de certification.

Le Conseil de sécurité de CA le définit comme « un fichier signé numériquement contenant une liste des certificats qui ont été révoqués et dont la validité n'a pas encore expiré ».

La RFC 5280, la norme Internet qui régit PKI X.509, en donne la définition officielle : une CRL est « une structure de données horodatée et signée qu'une autorité de certification (CA) ou un émetteur de CRL publie périodiquement afin de communiquer le statut de révocation des certificats numériques concernés ».

Le format CRL est défini dans la norme X.509 et décrit en détail dans la RFC 5280. Chaque entrée d'une liste CRL comprend le numéro de série du certificat révoqué et la date de révocation. Les entrées peuvent également inclure, à titre facultatif, une durée de validité de la révocation ainsi qu'un code de motif expliquant pourquoi le certificat a été révoqué.

Les autorités de certification publient régulièrement des listes de certificats révoqués (CRL) (toutes les heures, tous les jours ou toutes les semaines, selon la politique en vigueur et le niveau de tolérance au risque). Un certificat révoqué peut présenter l'un des deux statuts suivants dans une CRL :

• Révoqué : la révocation est définitive et irréversible. Le certificat ne sera plus jamais considéré comme fiable.
• En attente : la révocation est temporaire. La confiance accordée au certificat est suspendue, mais elle pourra être rétablie si les circonstances évoluent.

Fonctionnement des listes de révocation de certificats

Le rôle de l'autorité de certification

Les listes CRL sont émises et mises à jour par l'autorité de certification qui a initialement délivré les certificats. L'autorité de certification signe numériquement chaque liste CRL qu'elle publie, et cette signature est essentielle : elle garantit l'authenticité du fichier et empêche toute altération.

Toute partie de confiance qui télécharge une CRL peut vérifier la signature de l'autorité de certification afin de s'assurer que la liste n'a pas été altérée pendant son transfert. Dans la plupart des déploiements, la CRL est signée par la même entité qui a émis les certificats. Cependant, dans certains cas, une autorité de certification peut désigner un autre signataire autorisé pour émettre des CRL en son nom, une configuration prise en charge par la norme X.509 mais rarement utilisée dans la pratique.

Structure et contenu du CRL

Conformément à la RFC 5280, une liste CRL contient les champs clés suivants :

• Nom de l'émetteur : nom distinctif de l'autorité de certification (CA) qui a émis la liste CRL
• Dans cette mise à jour : la date et l'heure de publication de la CRL
• Prochaine mise à jour : date et heure auxquelles la prochaine liste CRL sera publiée (c'est-à-dire la date d'expiration de la liste CRL)
• Liste des certificats révoqués : une séquence d'entrées, chacune contenant :
  • Le numéro de série du certificat révoqué
  • La date de révocation
  • Extensions facultatives, y compris les codes de motif de révocation
• Signature numérique de CA : authentifie l'intégralité de la liste CRL

Conformément à la RFC 5280, les certificats arrivés à expiration sont normalement supprimés de la liste CRL une fois leur période de validité initiale écoulée, car ils ne seraient plus acceptés, quel que soit leur statut de révocation. Toutefois, ce comportement peut être configuré par l'autorité de certification.

Entrées de la liste CRL et codes de motif de révocation

La norme X.509 définit plusieurs codes de motif qu'une autorité de certification (CA) peut associer à une entrée de liste de révocation de certificats (CRL). Ces codes fournissent des informations sur les raisons de la révocation d'un certificat, ce qui peut s'avérer important pour l'analyse judiciaire et pour déterminer si le contenu signé avant la date de révocation doit toujours être considéré comme fiable.

Les codes de motif standard sont les suivants :

• Compromission de la clé : la clé privée du certificat a été compromise. Il ne faut pas se fier aux contenus précédemment signés avec cette clé.
• Compromission de l'autorité de certification : la clé privée de l'autorité de certification émettrice a été compromise, ce qui remet en cause la validité de tous les certificats qu'elle a émis.
• Changement d'affiliation : l'affiliation organisationnelle du titulaire du certificat a changé (par exemple, une filiale a été cédée).
• Remplacé : ce certificat a été remplacé par un certificat plus récent.
• Cessation d'activité : L'entité a cessé ses activités, ou le domaine ou le serveur associé au certificat n'appartient plus au titulaire du certificat.
• Privilège retiré : l'autorisation du titulaire du certificat a changé (par exemple, un salarié a quitté l'organisation). Les signatures antérieures à la révocation peuvent toujours être considérées comme valides, puisque le titulaire était autorisé au moment de la signature.
• Suspension du certificat : le certificat est temporairement suspendu. Il peut être réactivé grâce à une entrée « removeFromCRL » figurant dans une liste CRL delta ultérieure.

Les certificats peuvent également être révoqués s’ils ont été délivrés de manière irrégulière, obtenus par fraude ou délivrés en violation de la déclaration de pratiques de certification de l’autorité de certification.

Comment les navigateurs et les applications vérifient les listes CRL

Lorsqu'un utilisateur se connecte à un site web ou à un service sécurisé par un certificat numérique, la partie de confiance (navigateur, application ou système d'exploitation) effectue une série d'étapes de validation. La vérification de la liste CRL constitue un élément central de ce processus :

1. Points de distribution des listes CRL : au moment de leur création, les certificats contiennent une extension « Points de distribution des listes CRL » (CDP) qui répertorie une ou plusieurs URL permettant de récupérer la liste CRL de l'autorité de certification émettrice chaque fois qu'il est nécessaire de valider ces certificats.
2. TLS : lors de l'établissement d'une TLS , le navigateur initie la connexion et reçoit le certificat du serveur.
3. Récupération et vérification de la CRL : le navigateur récupère la CRL à partir de l'URL indiquée dans l'extension CDP du certificat et vérifie si le numéro de série du certificat figure dans la liste.
4. Décision : si le certificat ne figure pas dans la liste CRL, la connexion est établie. S'il y figure, le navigateur avertit l'utilisateur que le certificat a été révoqué et qu'il ne faut pas se fier à cette connexion.

Cette validation constitue une étape essentielle dans toute transaction PKI. Elle soulève toutefois un problème pratique : si le navigateur ne dispose pas d’une copie récente de la liste CRL mise en cache localement, il doit récupérer l’intégralité de la liste CRL lors de la connexion initiale, ce qui augmente la latence. Pour pallier ce problème, les navigateurs mettent les listes CRL en cache, mais cette mise en cache crée une fenêtre temporelle pendant laquelle un certificat récemment révoqué sera encore accepté.

Types de listes de révocation de certificats

CRL complètes (combinées)

Une liste CRL complète, parfois appelée « liste CRL combinée », contient tous les certificats révoqués par l'autorité de certification émettrice qui n'ont pas encore expiré. Chaque fois que l'autorité de certification publie une liste CRL mise à jour, elle établit la liste complète à partir de zéro.

Les CRL complètes sont simples à mettre en œuvre et largement prises en charge par tous PKI . Leur format facilite l’audit. Chaque partie de confiance qui télécharge la CRL obtient une vue d’ensemble complète de l’état des révocations. Cependant, pour les autorités de certification ayant révoqué un grand nombre de certificats, les CRL complètes peuvent atteindre des tailles considérables, ce qui consomme une bande passante importante et allonge les temps de téléchargement. Elles conviennent donc mieux aux PKI de petite envergure, où le nombre total de certificats révoqués reste gérable.

Listes CRL partitionnées

Les CRL partitionnées répartissent les informations de révocation entre plusieurs fichiers CRL distincts. Cette option permet de répartir les numéros de série des certificats révoqués sur un nombre prédéterminé de partitions. Lors de leur émission, les certificats se voient attribuer un numéro de partition CRL généré de manière aléatoire. De cette manière, les parties de confiance peuvent identifier la partition appropriée via l'extension CDP, puis demander la partition correspondante.

L'avantage réside dans l'évolutivité. Au lieu de télécharger une seule liste CRL volumineuse, une partie de confiance ne télécharge que la partition correspondant au certificat qu'elle valide. Cette approche réduit la consommation de bande passante, accélère la génération des listes CRL du côté de l'autorité de certification et permet la mise en cache indépendante de chaque partition. Cependant, elle nécessite que tant la partie de confiance que les listes CRL partitionnées constituent l'approche standard pour les infrastructures PKI des grandes entreprises gérant des dizaines de milliers de certificats, voire plus.

CRL Delta

Une liste CRL « delta » ne contient que les modifications (ajouts et suppressions) intervenues depuis la publication de la dernière liste CRL complète (de base). Au lieu de télécharger à nouveau la liste dans son intégralité, une partie de confiance qui dispose déjà de la liste CRL de base n'a qu'à récupérer la liste « delta » pour mettre à jour ses données de révocation.

Les CRL delta réduisent considérablement les besoins en bande passante, en particulier dans les environnements où les CRL de base sont volumineuses et où le nombre de révocations entre deux cycles de publication est relativement faible. Cependant, elles dépendent fortement de la CRL de base, et la vérification peut échouer même si la CRL delta est disponible.

Cycle de vie des certificats CRL : mises à jour, expiration et fréquence

Fréquence des mises à jour et champ « Prochaine mise à jour »

Chaque liste CRL comporte un horodatage « prochaine mise à jour » qui indique aux parties de confiance quand elles peuvent s'attendre à recevoir la prochaine version. Les autorités de certification publient de nouvelles listes CRL selon un calendrier défini dans leur déclaration de pratiques en matière de certificats :

• Listes CRL des autorités de certification racines : publiées tous les quelques mois, voire toutes les années. Les clés privées des autorités de certification racines étant stockées hors ligne, la génération des listes CRL nécessite un accès physique à la clé de signature.
• Publication des listes CRL des autorités de certification (subordonnées) : publiée toutes les quelques heures ou tous les quelques jours. Ces autorités de certification sont en ligne et peuvent automatiser plus facilement la génération des listes CRL.

La fréquence dépend fortement de la politique de l'autorité de certification. Une autorité de certification racine hors ligne (c'est-à-dire une autorité de certification maintenue hors ligne pour des raisons de sécurité) peut générer une nouvelle liste CRL chaque année, voire moins souvent. À l'inverse, une autorité de certification émettrice évoluant dans un environnement hautement sécurisé peut générer une nouvelle liste CRL toutes les heures, voire plus souvent.

Les administrateurs peuvent également déclencher la publication manuelle d'une liste CRL immédiatement après un événement de révocation de haute priorité, garantissant ainsi que la révocation soit propagée sans attendre la prochaine mise à jour programmée.

Que se passe-t-il lorsqu'une liste CRL arrive à expiration ?

Si une liste CRL atteint la date de sa « prochaine mise à jour » sans qu’une nouvelle version ait été publiée, ou si le point de terminaison de la liste CRL devient inaccessible, les conséquences sont graves : tous les certificats émis par cette autorité de certification deviennent immédiatement inutilisables. Les parties qui se fient à ces certificats et qui ne peuvent pas obtenir une liste CRL valide et à jour n’ont aucun moyen de vérifier si un certificat a été révoqué, et beaucoup d’entre elles rejetteront purement et simplement ce certificat.

Ce comportement (fail-closed) constitue le paramètre par défaut le plus sûr. Certaines implémentations proposent une option « fail-open » qui accepte les certificats même lorsqu’il est impossible de récupérer une liste CRL à jour, mais cette option privilégie la disponibilité au détriment de la sécurité et n’est pas recommandée dans les environnements de production.

L'expiration des listes CRL est l'une des causes les plus courantes de PKI imprévues PKI , ce qui fait de la surveillance des listes CRL une exigence opérationnelle essentielle.

Comment consulter une liste de révocation de certificats

Les certificats comportent une extension « CRL Distribution Points » (CDP) qui contient les URL à partir desquelles la liste CRL correspondante peut être téléchargée. Il existe plusieurs méthodes courantes pour vérifier une liste CRL :

• Windows : l'outil command certutil permet de télécharger, d'analyser et d'afficher le contenu des listes CRL.
• macOS et Linux : OpenSSL propose des commandes permettant de récupérer et de décoder des listes CRL à partir d'URL CDP.
• Navigateurs : les navigateurs modernes effectuent automatiquement une validation CRL (ou OCSP) lors TLS , et avertissent les utilisateurs si un certificat a été révoqué.

Un guide dédié à la vérification des listes de révocation (CRL) à l'aide d'outils et de commandes spécifiques est disponible dans le Centre Keyfactor .

Pourquoi les CRL sont-elles importantes ?

Sans un système de révocation des certificats opérationnel, l PKI infr PKI sa capacité à s'adapter à l'évolution des conditions de confiance. Les risques liés à une exploitation sans gestion efficace des listes de révocation de certificats (CRL) sont considérables :

• Validation de la confiance : les listes CRL constituent le mécanisme permettant de confirmer qu’un certificat bénéficie toujours de la confiance de l’autorité de certification qui l’a émis. Sans elles, les parties qui s’appuient sur ces certificats n’ont aucun moyen de distinguer un certificat valide d’un certificat qui a été compromis.
• Révocation rétroactive : les entrées de la liste CRL indiquent la date de révocation, ce qui permet aux organisations de déterminer à quel moment la confiance a été retirée. Cet élément est essentiel dans le cadre d'enquêtes judiciaires, où le fait de connaître le moment exact auquel un certificat a cessé d'être considéré comme fiable a une incidence sur la validité de tous les éléments signés à l'aide de ce certificat.
• Fuites de données : un certificat compromis qui continue d'être considéré comme fiable permet des attaques de type « homme du milieu » (MITM). Les pirates peuvent ainsi intercepter le trafic chiffré contenant des numéros de Sécurité sociale, des identifiants de comptes bancaires, des données de cartes de crédit et des informations médicales protégées.
• Usurpation d'identité et usurpation d'identité : les certificats compromis qui n'ont pas été révoqués peuvent être utilisés dans le cadre de campagnes de vol d'identifiants et d'usurpation de messagerie d'entreprise (BEC), permettant ainsi aux attaquants de se faire passer pour des entités de confiance.
• Pertes financières : les identifiants bancaires, les données de cartes de paiement et les jetons d'authentification d'entreprise peuvent tous être dérobés via des connexions reposant sur des certificats qui auraient dû être révoqués.
• Diffusion de logiciels malveillants : TLS de signature de code ou TLS compromis peuvent être utilisés pour installer des enregistreurs de frappe, déployer des ransomwares ou recruter des appareils au sein de botnets DDoS, tout en apparaissant comme légitimes aux yeux des systèmes de la victime.

Obtenir une démonstration

Distribution et hébergement CRL

Points de distribution CRL (CDP)

Un point de distribution des listes de révocation (CRL) est l'emplacement (généralement une URL sur un serveur d'annuaire LDAP ou un serveur web) où une autorité de certification publie ses listes de révocation. L'URL du CDP est intégrée à chaque certificat émis par l'autorité de certification, via l'extension CDP, afin que les parties de confiance sachent où récupérer la liste de révocation.

Les CDP doivent être accessibles à tout moment. Si une partie utilisatrice ne parvient pas à contacter le CDP pour récupérer une liste CRL à jour, la validation du certificat échouera. C'est pourquoi les CDP basés sur LDAP ne sont pas recommandés pour PKI accessibles au public. Les CDP sur serveur Web (HTTP/HTTPS) constituent la norme pour la plupart des déploiements.

Stratégies d'hébergement

Les organisations disposent de plusieurs options pour héberger les points de terminaison CRL, chacune présentant des caractéristiques différentes en matière de disponibilité et d'évolutivité :

• Serveurs Web : l'approche la plus simple. Un serveur HTTP standard héberge les fichiers CRL, et les certificats indiquent son URL comme CDP. Convient aux infrastructures PKI de petite et moyenne taille.
• Réseaux de diffusion de contenu (CDN) : ils répartissent les fichiers CRL entre des nœuds périphériques répartis géographiquement, offrant ainsi une haute disponibilité et une faible latence pour les déploiements à l'échelle mondiale.
• Fermes de serveurs web : plusieurs serveurs web placés derrière un équilibreur de charge assurent la redondance et la tolérance aux pannes.
• Annuaires LDAP : traditionnellement utilisés dans les environnements Active Directory d'entreprise. Largement dépréciés pour les nouveaux déploiements, au profit d'une distribution basée sur HTTP.

Considérations relatives à la mise en cache

Les parties de confiance mettent en cache les CRL localement jusqu'à l'expiration de l'horodatage de la « prochaine mise à jour ». Si la mise en cache réduit la charge sur les points de terminaison du CDP et améliore la latence de connexion, elle introduit toutefois une fenêtre pendant laquelle un certificat récemment révoqué peut encore être accepté par un client utilisant une CRL mise en cache (et désormais obsolète). Ce compromis entre l'actualité et les performances est inhérent à la révocation basée sur les CRL et doit être pris en compte dans les décisions relatives à la fréquence de publication des CRL.

Les téléchargements CRL volumineux augmentent également la latence lors de la connexion initiale, lorsqu'aucune copie en cache n'existe, ce qui peut nuire à l'expérience utilisateur et aux performances de l'application.

Suivi et gestion du CRL

Pourquoi la surveillance du CRL est-elle essentielle ?

Une mauvaise gestion peut avoir de graves conséquences. Si votre liste CRL est périmée ou inaccessible, tous vos certificats deviennent immédiatement inutilisables. Une seule publication manquée de la liste CRL ou un CDP inaccessible peut provoquer une panne généralisée affectant tous les services qui dépendent des certificats émis par cette autorité de certification.

Éléments à surveiller

Un suivi efficace des CRL devrait porter sur :

• Réactivité des terminaux : Vérifiez que toutes les URL CDP sont accessibles et renvoient des données CRL valides.
• Dates d'expiration à venir : alerte lorsqu'la date de « prochaine mise à jour » d'une liste CRL approche et qu'aucune liste de remplacement n'a été publiée.
• Listes CRL périmées : signalez immédiatement toute liste CRL dont la date de « prochaine mise à jour » est dépassée sans qu’elle ait été remplacée.

Génération et automatisation des CRL

La génération des CRL peut être manuelle (déclenchée à la demande par un administrateur) ou automatisée via plusieurs mécanismes :

• Services de mise à jour des listes CRL : processus d'arrière-plan qui génèrent et publient des listes CRL selon une fréquence configurée.
• Génération déclenchée par un événement : publication automatique de la liste CRL dès la révocation d'un certificat.
• Tâches cron sous Unix : tâches planifiées qui déclenchent la génération de listes CRL à intervalles réguliers.

Il est recommandé que les autorités de certification (CA) nouvellement créées publient une liste CRL vide dès leur création. Cela permet aux parties de confiance de valider les certificats de l'autorité de certification dès le premier jour, avant même que des révocations n'aient eu lieu.

Problèmes et limites courants liés aux listes CRL

Si les CRL restent un mécanisme de révocation fondamental dans PKI, elles posent toutefois des difficultés opérationnelles bien connues :

• Évolutivité : la taille des fichiers CRL augmente à chaque révocation. Pour les autorités de certification de grande envergure, il est possible que les CRL contiennent des millions d’entrées, ce qui rend leur téléchargement et leur analyse particulièrement gourmands en ressources. Cela pose un problème particulier pour les appareils aux capacités limitées, tels que les smartphones et IoT , dont la mémoire et la puissance de calcul sont restreintes.
• Latence : il faut télécharger et analyser l'intégralité de la liste CRL pour vérifier le statut d'un seul certificat. Contrairement au protocole OCSP, qui renvoie une réponse ciblée pour un certificat donné, les listes CRL ne permettent pas d'interroger des entrées individuelles.
• Surcoût lié à la connexion : si aucune copie récente de la CRL n'est mise en cache, la partie de confiance doit récupérer la CRL lors de la TLS initiale, ce qui ajoute une latence mesurable à l'établissement de la connexion.
• Fenêtres de mise en cache : l'intervalle entre les publications des listes CRL crée une fenêtre pendant laquelle un certificat révoqué peut encore être accepté par les parties de confiance utilisant une copie mise en cache. Des intervalles de publication plus courts réduisent cette fenêtre, mais augmentent la charge pesant sur l'autorité de certification et le réseau.

Bonnes pratiques en matière de CRL

Une gestion efficace des CRL nécessite une planification minutieuse et une discipline opérationnelle. Les pratiques suivantes permettent de remédier aux modes de défaillance les plus courants :

1. Définissez les fréquences de mise à jour en fonction du niveau de risque. Les listes CRL des autorités de certification (CA) doivent être publiées toutes les 24 à 72 heures. Les listes CRL des autorités de certification racines (CA), dont les clés de signature sont conservées hors ligne, peuvent être publiées tous les 3 à 12 mois. Adaptez la fréquence au niveau de sensibilité des certificats émis.
2. Surveillez de manière proactive les points de terminaison des listes CRL. N’attendez pas qu’une panne survienne pour vous rendre compte qu’un CDP est inaccessible ou qu’une liste CRL a expiré. Mettez en place une surveillance automatisée qui vérifie la disponibilité des points de terminaison et vous alerte lorsque les dates d’expiration approchent.
3. Automatisez la génération des listes CRL. La publication manuelle des listes CRL est source d'erreurs et n'est pas évolutive. Utilisez des tâches planifiées, des service workers ou des automatisations déclenchées par des événements pour garantir une publication fiable et ponctuelle des listes CRL.
4. Prévoyez une haute disponibilité. Les points de terminaison CRL constituent une infrastructure critique. Utilisez des réseaux de diffusion de contenu (CDN), des fermes de serveurs Web ou des serveurs Web à équilibrage de charge pour garantir que les URL CDP restent accessibles même en cas de panne de serveur ou de pics de trafic.
5. Utilisez des listes CRL partitionnées à grande échelle. Si votre PKI un grand nombre de certificats, utilisez des listes CRL partitionnées afin que la taille de chaque fichier CRL reste raisonnable.
6. Aligner la politique relative aux listes CRL sur les exigences de sécurité. Le compromis entre l'actualité des listes CRL et la charge opérationnelle doit faire l'objet d'une décision stratégique explicite, fondée sur la tolérance au risque de l'organisation et le niveau de sensibilité des systèmes protégés par l'infrastructure PKI.
7. Tenez compte du comportement de mise en cache. Sachez que les parties de confiance mettront les listes CRL en cache jusqu’à l’horodatage de la « prochaine mise à jour ». Intégrez cette période de mise en cache dans les plans d’intervention en cas d’incident et dans les décisions relatives à l’urgence de la révocation.

Comment Keyfactor vous aider

La gestion des listes de révocation de certificats (CRL) et de la révocation des certificats à grande échelle nécessite à la fois une PKI performante et une visibilité centralisée sur l'état de révocation dans l'ensemble de l'environnement.

EJBCA Keyfactor est une plateforme d’autorité de certification (CA) complète et de niveau entreprise qui offre un contrôle total sur la génération et la distribution des listes de révocation de certificats (CRL). EJBCA la publication manuelle et automatisée des CRL, les CRL partitionnées et la génération de CRL delta, ainsi que des paramètres configurables pour les points de distribution de CRL (CDP) et des fréquences de publication flexibles. En tant que plateforme d'autorité de certification chargée de l'émission et de la révocation des certificats, EJBCA PKI un contrôle direct sur le cycle de vie de la révocation, depuis l'émission jusqu'à la publication des CRL.

Keyfactor Command offre une couche centralisée de visibilité et d’automatisation qui s’applique à toutes les autorités de certification (CA) de l’environnement. Command les points de terminaison CRL et OCSP, envoie des alertes par e-mail configurables lorsque les CRL approchent de leur date d’expiration et assure une surveillance en temps réel de l’état de révocation sur l’ensemble du parc de certificats. Pour les organisations gérant des certificats provenant de plusieurs autorités de certification, Command les données de révocation de chaque CA dans un tableau de bord de surveillance unifié, éliminant ainsi le risque qu’une CRL expirée ou inaccessible passe inaperçue.

Ensemble, EJBCA Keyfactor Command la gestion de bout en bout du cycle de vie des certificats : identification, surveillance, émission, renouvellement et révocation, le tout via une plateforme unifiée.