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
Une CRL est une liste signée des certificats qu'une CA a révoqués avant leur date d'expiration. Voyez-la comme la liste des passeports annulés : les autorités la publient pour que toute personne contrôlant un passeport puisse vérifier qu'il n'a pas été invalidé. Ce guide explique le fonctionnement des CRL, leur comparaison avec OCSP et les bonnes pratiques pour les gérer.
Une Certificate Revocation List (CRL) est une structure de données signée numériquement, publiée par une autorité de certification (CA), qui liste les numéros de série des certificats ayant été révoqués avant leur date d'expiration naturelle.
Le format de la CRL est défini dans la RFC 5280, dans le cadre de la norme X.509. Chaque entrée de CRL contient le numéro de série du certificat, la date de révocation et, en option, un code de raison. L'ensemble de la liste est signé par la clé privée de la CA, ce qui permet aux clients d'en vérifier l'authenticité.
Voyez une CRL comme la liste des cartes bancaires annulées que recevaient autrefois les commerçants : un document mis à jour périodiquement qui indique « ces justificatifs ne sont plus valides, même s'ils ne sont pas encore expirés ». Les clients téléchargent la CRL et confrontent les certificats entrants à cette liste.
La CA génère périodiquement une nouvelle CRL contenant tous les certificats actuellement révoqués. La CRL est signée avec la clé privée de la CA et publiée à une URL appelée CRL Distribution Point (CDP). L'URL du CDP est intégrée dans chaque certificat émis par la CA.
Lorsqu'un client (navigateur, application ou serveur) a besoin de vérifier un certificat, il lit le CDP dans le certificat et télécharge la CRL. Il vérifie ensuite la signature de la CA sur la CRL pour s'assurer qu'elle n'a pas été altérée.
Le client recherche le numéro de série du certificat dans la CRL. S'il le trouve, le certificat est révoqué et la connexion est rejetée. S'il ne le trouve pas, le certificat passe le contrôle de révocation.
Chaque CRL comporte un champ `nextUpdate` qui indique quand une nouvelle CRL sera publiée. Les clients mettent la CRL en cache jusqu'à cette échéance pour éviter les téléchargements répétés. La contrepartie : pendant la durée du cache, les certificats nouvellement révoqués ne seront pas détectés.
Un nouveau certificat a été émis pour remplacer celui-ci. L'ancien est révoqué afin d'éviter que deux certificats valides ne coexistent pour la même identité.
Les CRL ne font que grossir : chaque certificat révoqué ajoute une entrée tant que la date d'expiration initiale du certificat n'est pas atteinte. Une CA active peut produire des CRL pesant plusieurs mégaoctets. Les clients doivent télécharger l'intégralité de la liste, même si une seule entrée a changé.
Les CRL volumineuses consomment une bande passante significative, en particulier lorsque de nombreux clients les téléchargent simultanément à l'expiration d'une fenêtre `nextUpdate`. Cela génère des pics de trafic sur l'infrastructure CDP et ajoute de la latence à la validation des certificats.
Entre deux publications de CRL, les certificats fraîchement révoqués sont invisibles pour les clients utilisant la CRL mise en cache. Si la CRL est publiée toutes les 24 heures, un certificat compromis peut rester de confiance jusqu'à 24 heures après sa révocation. C'est le compromis fondamental du modèle « par lots » des CRL.
Les CRL delta (RFC 5280) répondent au problème de taille en ne publiant que les changements intervenus depuis la dernière CRL complète. Elles ajoutent toutefois une complexité significative : les clients doivent suivre les numéros de CRL de base, gérer les références aux delta et assurer la cohérence du cache. De nombreuses implémentations ne les prennent pas en charge.
| CRL | OCSP | |
|---|---|---|
| Mécanisme | Téléchargement de la liste complète | Requête en temps réel par certificat |
| Fraîcheur | Périodique (heures à jours) | Quasi temps réel |
| Bande passante | Liste complète à chaque fois (potentiellement volumineuse) | Petite réponse par certificat |
| Confidentialité | Pas de suivi par requête | La CA voit quels certificats sont vérifiés |
| Mode hors-ligne | Fonctionne avec une CRL mise en cache | Nécessite un accès réseau |
| Norme | RFC 5280 | RFC 6960 |
# Télécharger une CRL depuis son point de distribution
curl -o ca.crl http://crl.example.com/ca.crl
# Analyser et afficher le contenu de la CRL (format DER)
openssl crl -in ca.crl -inform DER -noout -text
# Champs clés à examiner :
# Issuer : la CA qui a publié cette CRL
# Last Update : date de génération de cette CRL
# Next Update : date de publication de la prochaine CRL
# Revoked Certificates : liste des numéros de série + dates # Vérifier si un certificat spécifique figure dans la CRL
openssl crl -in ca.crl -inform DER -noout -text | \
grep "Serial Number: 0A1B2C3D"
# Vérifier la signature de la CRL avec le certificat de la CA
openssl crl -in ca.crl -inform DER -CAfile ca-cert.pem -noout CRL et OCSP automatisés — Evertrust PKI publie automatiquement les CRL selon des plannings configurables et fournit un répondeur OCSP intégré. Les deux sont gérés sans intervention manuelle, garantissant des informations de révocation toujours fraîches et disponibles.
Visibilité sur les révocations — Evertrust CLM suit le statut de révocation de chaque certificat découvert, sur l'ensemble de vos CA. Voyez quels certificats ont été révoqués, quand et pour quelle raison, depuis un tableau de bord unique.
Flux révocation + remplacement — Lorsque vous révoquez un certificat dans Evertrust, vous pouvez déclencher automatiquement l'émission et le déploiement d'un certificat de remplacement, minimisant le temps pendant lequel votre service fonctionne sans certificat valide.