CRL et OCSP sont les deux moyens par lesquels une partie de confiance (relying party) apprend qu’un certificat a été révoqué avant son expiration. Une liste de révocation de certificats (RFC 5280 §5) est une liste signée de numéros de série révoqués que les clients téléchargent ; le protocole de vérification de certificat en ligne (Online Certificate Status Protocol, RFC 6960) répond à une requête portant sur un seul certificat. Pour la PKI publique du Web, la réponse a nettement changé depuis 2024 : les CRL sont devenues obligatoires, OCSP facultatif, et la plus grande autorité de certification (AC) a désactivé OCSP.
Vue d’ensemble
| CRL | OCSP | |
|---|---|---|
| Spécification | RFC 5280 §5 | RFC 6960 (nonce : RFC 8954) |
| Ce que reçoit le client | Liste signée de tous les numéros de série révoqués pour une portée donnée | Statut signé (bon, révoqué, inconnu) pour un seul numéro de série |
| Taille (mesurée le 20 octobre 2026) | Fragment de CRL Let’s Encrypt de 62 116 octets, avec 1591 entrées | Réponse OCSP DigiCert de 471 octets |
| Fraîcheur | De thisUpdate à nextUpdate (pour ce fragment : 9 jours) | Validité de la réponse (pour cette réponse : 7 jours) |
| Confidentialité | Le serveur apprend seulement qu’une CRL a été téléchargée | Le répondeur apprend quel site le client visite |
| Dépendance à la disponibilité | Peut être mise en cache, répliquée et préchargée | Dépendance en direct au répondeur, sauf agrafage |
| Règle de la PKI web (Baseline Requirements) | Obligatoire depuis le 15 mars 2024 ; nouvelle CRL au moins tous les 4 jours (7 si chaque certificat comporte une URL OCSP) et dans les 24 heures qui suivent une révocation | Facultatif depuis le 15 mars 2024 |
| Usage par les navigateurs | Agrégation : CRLite dans Firefox, CRLSets dans Chrome | Firefox a cessé les requêtes pour les certificats DV (version 142) ; Chrome n’en effectue pas pour la plupart des certificats |
| Transmission par le serveur | Sans objet | Agrafage OCSP (status_request, RFC 6066) |
Fonctionnement de chacun
Une CRL indique son émetteur, contient thisUpdate et nextUpdate, un numéro de CRL croissant de façon monotone et une entrée par certificat révoqué (numéro de série, date de révocation, motif facultatif), et elle est signée par l’AC. Les certificats indiquent leur CRL dans l’extension CRL Distribution Points ; les grandes AC partitionnent leurs CRL pour que chaque fichier garde une taille raisonnable, et les AC publiques déclarent l’ensemble complet de leurs URL de CRL dans la CCADB, pour que les agrégateurs puissent collecter toutes les révocations. Les clients qui consultent les CRL les téléchargent et les mettent en cache, et les CRL delta (RFC 5280 §5.2.4) peuvent réduire le trafic pour les listes volumineuses.
Un client OCSP envoie le condensat du nom de l’émetteur, le condensat de la clé de l’émetteur et le numéro de série à l’URL indiquée dans l’extension Authority Information Access du certificat ; le répondeur renvoie un statut signé, assorti de sa propre fenêtre de validité. Les réponses peuvent être mises en cache jusqu’à nextUpdate, et les serveurs peuvent agrafer une réponse récente au handshake TLS, pour que les clients n’aient pas à contacter l’AC.
Les mesures ci-dessus ont été relevées en conditions réelles : un certificat Let’s Encrypt émis en septembre 2026 pointe uniquement vers http://ye2.c.lencr.org/96.crl (sans URL OCSP), et ce fragment pesait 62 Ko ; un certificat DigiCert contient encore http://ocsp.digicert.com, dont la réponse faisait 471 octets.
Pourquoi OCSP s’est effacé sur le Web
Trois propriétés ont eu raison d’OCSP en direct dans les navigateurs. Confidentialité : chaque interrogation indique à l’AC quel site un utilisateur visite, et depuis quelle adresse IP. Disponibilité : un répondeur lent ou injoignable soit bloque le chargement des pages, soit, parce que les navigateurs ont choisi l’échec non bloquant (soft-fail), est ignoré en silence, ce qui signifie qu’un attaquant capable de bloquer le répondeur met la vérification en échec. Coût : les répondeurs doivent absorber chaque chargement de page sur Internet. L’agrafage a réglé les problèmes de confidentialité et de coût, mais il supposait que chaque serveur actualise ses réponses de manière fiable, et Must-Staple (RFC 7633), qui aurait permis d’imposer l’agrafage, n’était pris en charge que par Firefox.
Le CA/Browser Forum a réagi avec le vote SC-063 (en vigueur depuis le 15 mars 2024) : CRL obligatoires, OCSP facultatif. Let’s Encrypt a retiré les URL OCSP de ses nouveaux certificats et cessé d’accepter les commandes Must-Staple le 7 mai 2025, puis a arrêté ses répondeurs le 6 août 2025. Firefox a activé CRLite pour tous les utilisateurs sur ordinateur dans sa version 137 : un encodage local compact de toutes les révocations parmi les certificats inscrits dans les journaux CT, actualisé toutes les 12 heures, pour environ 300 Ko téléchargés par jour en moyenne. Firefox 142 a ensuite cessé les requêtes OCSP pour les certificats validés par domaine. Chrome s’appuie sur CRLSets, un ensemble sélectionné centré sur les révocations à fort impact, plutôt que sur des interrogations site par site.
La troisième option : les certificats de courte durée
Un certificat valable quelques jours n’a pas besoin de vérification de révocation : le temps qu’une révocation se propage, il a déjà expiré. Les Baseline Requirements autorisent les AC à omettre les informations de révocation dans les certificats de courte durée (7 jours au plus pour ceux émis depuis le 15 mars 2026), et Let’s Encrypt propose depuis janvier 2026 des certificats de 160 heures via son profil ACME shortlived. Avec la réduction générale de la durée de vie à 47 jours d’ici 2029 (vote SC-081v3), la révocation devient un filet de sécurité plutôt que le mécanisme de contrôle principal. Le calculateur de durée de vie des certificats indique les limites selon la date d’émission.
Quand choisir l’un ou l’autre
- Serveurs TLS publics : rien de particulier à faire ; assurez-vous que vos certificats proviennent d’une AC qui publie des CRL, et n’activez pas Must-Staple. Supprimez toute configuration d’agrafage qui échoue en l’absence d’URL OCSP.
- Logiciels clients qui vérifient des certificats publics : utilisez le vérificateur de la plateforme ; il applique les ensembles de révocations des éditeurs de navigateurs lorsqu’ils sont disponibles.
- PKI privée avec de nombreux clients, dont certains hors ligne : des CRL avec un
nextUpdatecourt, servies par un service HTTP hautement disponible. - PKI privée avec des certificats à forte valeur et des clients en ligne : OCSP, avec agrafage là où le protocole le permet, et des politiques d’échec bloquant (hard-fail) si le répondeur est sous votre contrôle.
- Identités de charges de travail et de services : des certificats de courte durée (de quelques heures à quelques jours) émis automatiquement, sans aucune infrastructure de révocation.
- Signature de code et de documents : la révocation reste importante pour les signatures de longue durée ; combinez les CRL ou OCSP avec des horodatages, pour que les vérificateurs puissent contrôler le statut au moment de la signature.
Notes de migration
- Recensez les dépendances à OCSP : configuration d’agrafage des serveurs, clients qui échouent en mode bloquant sans OCSP, surveillance qui interroge les répondeurs.
- Rendez l’agrafage facultatif : nginx et Apache ne doivent pas refuser de démarrer lorsqu’un certificat n’a pas d’URL OCSP.
- Pour les AC privées, publiez d’abord des CRL : ajoutez des points de distribution de CRL aux nouveaux certificats, partitionnez les listes volumineuses, réglez
nextUpdateen fonction de votre SLA de révocation, et servez les CRL en HTTP (pas en HTTPS, pour éviter les dépendances circulaires). - Raccourcissez les durées de vie là où l’automatisation le permet ; chaque étape réduit la charge qui repose sur la révocation.
- Testez la révocation de bout en bout : révoquez un certificat de test et confirmez que les clients le rejettent dans le délai attendu. Le décodeur de CRL et le décodeur OCSP montrent ce que les clients verront.