Lorsqu'un certificat numérique n'est plus fiable, comment votre infrastructure s'en rend-elle compte ? La réponse dépend de votre utilisation des listes de révocation de certificats (CRL), du protocole OCSP (Online Certificate Status Protocol) ou des deux. Chaque mécanisme présente des avantages et des inconvénients spécifiques, et le choix approprié dépend de votre environnement, de vos exigences de conformité et de votre tolérance au risque.
Cet article explique en détail le fonctionnement des CRL et de l'OCSP, leurs limites respectives, et comment choisir l'approche la mieux adaptée à votre PKI .
Pourquoi la révocation des certificats est-elle importante ?
Les certificats constituent la colonne vertébrale de la PKI. Ils garantissent la confiance, permettant aux utilisateurs de s'authentifier sur les réseaux, les applications et les appareils, et de chiffrer les communications dans ces environnements. Chaque certificat a une durée de validité limitée, qui ne cesse de diminuer : de 13 mois (en septembre 2020) à 200 jours (en mars 2026), avec de nouvelles réductions prévues pour atteindre 100 jours d'ici mars 2027 et 47 jours d'ici mars 2028.
Mais les périodes de validité ne font que fixer les limites maximales. Au cours de cette période, une autorité de certification ou le titulaire d'un certificat peut être amené à déclarer un certificat non fiable bien avant son expiration. C'est là qu'intervient la révocation.
La révocation des certificats est une fonction importante, mais souvent négligée, de la gestion du cycle de vie des certificats. En l'absence d'un moyen fiable de révoquer les certificats et de signaler leur statut de révocation, les certificats compromis ou émis à tort continuent d'être considérés comme fiables, ce qui expose les systèmes à des risques.
Pour en savoir plus sur les principes fondamentaux, consultez nos guides consacrés à laliste de révocation de certificats(CRL) etau protocole de statut des certificats en ligne(OCSP). Une fois que vous aurez compris la différence entre la CRL et l'OCSP, découvrezcomment consulter et vérifier une CRL dans la pratique.
Qu'est-ce qu'une liste de révocation de certificats (CRL) ?
Une liste de révocation de certificats (CRL) est un fichier signé numériquement contenant une liste de numéros de série correspondant à des certificats qui ont été révoqués mais qui n'ont pas encore expiré. Définie dans la norme X.509 et la RFC 5280, 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.
La révocation d'un certificatconsiste à déclarer qu'un certificat numérique n'est plus fiable avant la date d'expiration prévue.
Comment les CRL sont structurés et publiés
Chaque entrée d'une liste CRL comprend le numéro de série du certificat, la date de révocation, une durée de validité facultative et un code de motif. Un certificat peut présenter l'un des deux statuts suivants :
- Révoqué: considéré comme non fiable de manière permanente
- En attente: temporairement suspendu, avec possibilité de réactivation
Les autorités de certification publient les listes CRL selon une fréquence (toutes les heures, tous les jours, toutes les semaines, etc.) qui dépend de leur politique. Entre deux publications, tout certificat nouvellement révoqué n'apparaîtra pas sur la liste avant la prochaine mise à jour.
Comment les navigateurs et les applications vérifient les listes CRL
Lorsqu'un navigateur établit une TLS , il valide le certificat du serveur et consulte la liste CRL associée afin de s'assurer que ce certificat n'a pas été révoqué. La consultation des listes CRL constitue une étape essentielle dans toute transaction PKI, car elle permet de vérifier l'identité du propriétaire du site et de déterminer si le certificat associé est fiable.
Le certificat lui-même contient une ou plusieurs URL CDP indiquant où la liste CRL peut être téléchargée.
Qu'est-ce qu'un point de distribution de listes de révocation (CDP) ?
Un CDP est l'emplacement, sur un serveur web, où une autorité de certification publie ses listes de révocation de certificats (CRL). Les CDP étaient traditionnellement déployés sur des serveurs LDAP, mais cette pratique est de moins en moins courante, au profit d'une plus grande simplicité. Le navigateur ou l'application télécharge la CRL depuis le CDP, la met en cache jusqu'à son expiration et l'analyse pour déterminer l'état de révocation.
Cela implique deux conditions indispensables pour garantir la fiabilité de la vérification de la révocation :
- Le CRL doit être valide (ne pas être périmé).
- Le CDP doit être accessible à tout moment. Si le CDP devient indisponible, les vérifications du statut de révocation échouent complètement.
Pour obtenir un guide détaillé sur la recherche et la vérification des CDP, consultez l'article «Comment consulter et vérifier une liste de révocation de certificats ».
Motifs courants de révocation d'un certificat
Les certificats sont révoqués pour diverses raisons opérationnelles et de sécurité, notamment :
- Émission non conforme: le certificat a été émis de manière incorrecte ou sans validation appropriée
- Certificat frauduleux: le certificat a été obtenu par tromperie
- Compromission de la clé privée: la clé privée du certificat a été divulguée ou volée
- Compromission d'une autorité de certification: l'autorité de certification émettrice elle-même a été compromise
- Changement de propriétaire du nom de domaine: l'entité propriétaire du nom de domaine a changé
- Fausse déclaration lors de la validation ou violation de l'accord: le titulaire du certificat a enfreint les conditions de délivrance ou a fourni de fausses informations lors de la validation
En l'absence de listes de révocation de certificats (CRL) opérationnelles ou d'un mécanisme de révocation équivalent, les organisations s'exposent à de graves risques de sécurité : fuites de données, usurpation d'identité, pertes financières et installation potentielle de logiciels malveillants via des certificats compromis.
Limites de l'utilisation exclusive des listes CRL
Si les CRL constituent un élément fondamental de PKI, elles présentent toutefois des limites notables :
- Taille des fichiers: les fichiers CRL peuvent atteindre des tailles considérables, ce qui les rend peu adaptés à une utilisation sur des appareils dotés d'une mémoire limitée, tels que les smartphones ou IoT .
- Surcoût lié à l'analyse: le navigateur doit télécharger et analyser la liste complète pour vérifier le statut d'un seul certificat, ce qui entraîne une latence et une baisse des performances.
- Fenêtre de péremption: les listes CRL étant publiées selon un calendrier précis, la mise en cache crée une fenêtre temporelle pendant laquelle un certificat révoqué pourrait être accepté comme valide.
- Disponibilité du CDP: si le point de distribution n'est plus disponible, les clients ne peuvent plus vérifier du tout l'état de révocation.
C'est précisément en raison de ces limites que le secteur a mis au point une solution alternative : le protocole OSCSP (Online Certificate Status Protocol).
Qu'est-ce que le protocole OCSP (Online Certificate Status Protocol) ?
Le protocole OCSP propose une approche radicalement différente de la vérification des révocations. Au lieu de télécharger la dernière liste CRL et de l'analyser pour vérifier si un certificat demandé figure dans cette liste, le navigateur interroge le serveur de révocation de l'autorité de certification émettrice afin de connaître le statut d'un certificat donné.
Le protocole OCSP (Online Certificate Status Protocol)est une méthode permettant de vérifier en temps réel le statut de révocation d'un certificat donné, sans avoir à télécharger l'intégralité de la liste CRL.
Fonctionnement de l'OCSP
Lorsqu'un client doit vérifier un certificat, il envoie une requête OCSP au serveur OCSP de l'autorité de certification. Ce dernier renvoie l'un des trois statuts suivants :
- Bon: le certificat est valide et n'a pas été révoqué
- Révoqué: le certificat a été révoqué
- Inconnu: le destinataire ne dispose d'aucune information concernant le certificat
Les réponses OCSP sont moins volumineuses que les fichiers CRL et conviennent aux appareils disposant d'une mémoire limitée. Le protocole est décrit dans la RFC 6960.
Limites de l'OCSP
L'OCSP résout les problèmes liés à la taille et à l'actualité des listes CRL, mais pose de nouveaux défis :
- Confidentialité: chaque requête OCSP révèle au répondeur de l'autorité de certification (CA) le site que l'utilisateur est en train de consulter, ce qui soulève un risque potentiel en matière de confidentialité.
- L'abandon progressif de l'OCSP par le secteur PKI Web: Let’s Encrypt, l'une des plus grandes autorités de certification (CA) au monde pour PKI Web, a annoncé en décembre 2024 qu'elle mettrait fin à la prise en charge de l'OCSP (à compter de mai 2025), invoquant des préoccupations liées à la confidentialité, à la complexité de l'infrastructure et aux coûts. D'autres autorités de certification ont également décidé de supprimer progressivement l'OCSP de leurs PKI Web, ce qui marque un retour généralisé à la vérification basée sur les listes CRL pour les certificats de confiance publique.
Qu'est-ce que l'« OCSP stapling » ?
La technique d'« OCSP stapling » remédie aux inconvénients de l'OCSP standard en matière de confidentialité et de performances. Avec l'OCSP stapling, le serveur web met en cache la réponse OCSP fournie par l'autorité de certification. Lorsqu'une TLS est lancée par le client, le serveur web « agrafe » la réponse OCSP au certificat qu'il envoie au navigateur, ce qui évite à ce dernier de devoir contacter directement l'autorité de certification.
Tel que défini dans la RFC 6066, l'OCSP stapling offre trois avantages majeurs :
- Amélioration des performances: le navigateur reçoit l'état de révocation dans le cadre de la TLS , ce qui évite un aller-retour supplémentaire vers le serveur OCSP.
- Sécurité renforcée: moins de faux positifs dus à des serveurs OCSP inaccessibles et réduction des vecteurs d'attaque, puisque le navigateur n'a plus besoin d'effectuer lui-même une requête externe.
- Renforcement de la confidentialité des utilisateurs: les autorités de certification (CA) ne reçoivent des requêtes OCSP que de la part des serveurs web, et non des utilisateurs individuels ; le comportement de navigation n'est donc plus divulgué.
CRL et OCSP : comparaison côte à côte
| Dimension | CRL | OCSP |
|---|---|---|
| Mécanisme | Télécharge la liste complète et signée des certificats révoqués | Interroge l'autorité de certification (CA) sur le statut d'un certificat donné |
| Actualité des données | Mises à jour périodiques (toutes les heures, tous les jours, toutes les semaines, etc.) | En temps quasi réel (vérification à chaque requête) |
| Bande passante et performances | Plus complet (téléchargement et analyse du fichier dans son intégralité) | Inférieur (réponse réduite par certificat) |
| Compatibilité des appareils | Moins adapté aux appareils aux ressources limitées (fichiers volumineux) | Particulièrement adapté à IoT aux appareils mobiles |
| Confidentialité | Pas de divulgation à l'autorité de certification pour chaque requête | Chaque requête indique le certificat qui fait l'objet de la vérification |
| Comportement en cas de défaillance | Toutes les vérifications de révocation échouent si le CDP est inaccessible. | Les vérifications individuelles échouent si le serveur OCSP n'est pas accessible |
Quand utiliser CRL, OCSP ou les deux ?
L'approche à adopter dépend de votre environnement, des exigences de votre politique et de votre tolérance au risque. Voici quelques conseils pratiques pour des scénarios courants :
- Environnements serveur: utilisez la liste CRL associée à l'OCSP Stapling. Le serveur se charge de la vérification des révocations et appose un « staple » à la réponse, offrant ainsi aux clients le meilleur des deux mondes.
- IoT appareils aux ressources limitées: l'OCSP est souvent la solution la plus adaptée, car les réponses de petite taille par certificat sont bien plus faciles à gérer que les téléchargements volumineux de listes CRL sur des appareils disposant d'une mémoire et d'une bande passante limitées.
- Environnements hautement sécurisés et soumis à des exigences de conformité: déployez à la fois les listes CRL et le protocole OCSP à des fins de redondance. Si l'un des deux mécanismes devient indisponible, l'autre sert de solution de secours, garantissant ainsi une couverture continue en matière de révocation.
Le choix dépend du cas d'utilisation. Dans les cas où la confidentialité de la requête est importante, la liste CRL est la meilleure option. Lorsqu'il est nécessaire de connaître l'état actuel de l'infrastructure PKI de savoir quels certificats ont été révoqués, le protocole OCSP est plus adapté. Ces deux méthodes peuvent être utilisées dès lors qu'une fiabilité maximale est requise.
L'utilisation conjointe des listes CRL et du protocole OCSP assure une redondance opérationnelle pour la vérification de la révocation des certificats. Si l'un des mécanismes de révocation devient indisponible ou subit une panne, l'autre peut continuer à fournir des informations sur l'état de révocation, ce qui améliore la fiabilité et la résilience de l'infrastructure PKI. En fin de compte, la décision de déployer l'un ou l'autre de ces mécanismes, ou les deux, dépend des politiques de sécurité et d'exploitation de l'organisation.
Pourquoi la surveillance des CRL et OCSP est essentielle
Quelle que soit la méthode choisie, il est essentiel de surveiller votre infrastructure de révocation. Pensez-y : si une autorité de certification (CA) est hors service, vous ne pourrez plus émettre de nouveaux certificats, mais si votre liste CRL est périmée ou inaccessible, tous vos certificats deviendront immédiatement inutilisables.
Cette distinction fait de la surveillance des révocations l'une des fonctions les plus critiques sur le plan opérationnel dans tout PKI .
Un suivi efficace devrait porter sur :
- Surveillance des listes CRL: réactivité des points de terminaison, avertissements d'expiration et alertes de listes CRL expirées
- Surveillance OCSP: réactivité des terminaux et validité des réponses
La surveillance en temps réel et en continu des révocations, assurée par des outilsd’automatisation du cycle de vie des certificatstels que Keyfactor Command éviter ce genre de situation. En surveillant de manière proactive l’état des listes CRL et OCSP, les équipes peuvent prévenir les défaillances silencieuses susceptibles d’entraîner des pannes à grande échelle.
Pour découvrir comment fonctionne la vérification de la liste de révocation des certificats (CRL) dans la pratique, consultez l'article «Comment afficher et vérifier une liste de révocation des certificats ».
Vous avez des questions sur la révocation des certificats ? Nous avons les réponses.
Quelle est la différence entre une CRL et l'OCSP ?
Une CRL est une liste complète des certificats révoqués publiée périodiquement par une autorité de certification, tandis que l'OCSP vérifie le statut d'un certificat donné en temps réel. Les CRL nécessitent le téléchargement et l'analyse de l'intégralité du fichier, alors que l'OCSP renvoie une réponse légère, spécifique à chaque certificat.
Puis-je utiliser simultanément CRL et OCSP ?
Oui, et de nombreuses organisations le font. L'utilisation conjointe de ces deux mécanismes offre une redondance : si l'un d'eux devient indisponible, l'autre sert de solution de secours. Cette pratique est particulièrement courante dans les environnements à haut niveau de sécurité et soumis à des exigences de conformité.
Pourquoi un certificat numérique serait-il révoqué ?
Parmi les raisons courantes, on peut citer la compromission de la clé privée, la compromission de l'autorité de certification (CA), une émission irrégulière, des certificats frauduleux, des changements de propriété du domaine, ainsi que des fausses déclarations lors de la validation ou des violations des conditions d'utilisation.
L'OCSP est-il plus sûr que la CRL ?
L'OCSP fournit des données de révocation plus récentes, mais il soulève un problème de confidentialité, car chaque requête révèle quel certificat l'utilisateur est en train de vérifier. Aucune de ces deux méthodes n'est intrinsèquement « plus sûre » ; chacune présente des atouts adaptés à différents cas d'utilisation et environnements.
À quelle fréquence les listes CRL sont-elles mises à jour ?
La fréquence de mise à jour des listes CRL varie en fonction de la politique de l'autorité de certification. Les intervalles les plus courants sont : toutes les heures, tous les jours et toutes les semaines. Des mises à jour plus fréquentes réduisent la période d'obsolescence, mais augmentent la charge sur l'infrastructure.
