CRL ou OCSP pour révoquer un certificat

La révocation répond à une question brutale : un certificat encore valide cryptographiquement doit-il être refusé avant son expiration ? Les CRL (Certificate Revocation List) et OCSP (Online Certificate Status Protocol) apportent deux réponses historiques, mais ne paient pas la disponibilité, la confidentialité et la fraîcheur de la même manière.

→ Lire l’explication complète de la marmotte

CRL et OCSP : le compromis entre fraîcheur et autonomie

Une CRL est un document signé par une autorité de certification, ou AC, qui énumère les numéros de série des certificats révoqués. Le client télécharge cette liste depuis un point de distribution indiqué dans le certificat, la vérifie avec la clé publique de l’émetteur, puis recherche le numéro de série présenté. Le document contient thisUpdate, date de publication, et nextUpdate, date attendue de la prochaine version.

OCSP interroge un répondeur pour un certificat précis. La requête contient notamment l’identité de l’émetteur et le numéro de série ; la réponse signée retourne good, revoked ou unknown. Le répondeur peut être l’AC elle-même ou un service délégué, doté d’un certificat dont l’usage étendu autorise la signature de réponses OCSP.

Le compromis central est net : la CRL échange de la bande passante et une fraîcheur bornée contre une validation locale et cacheable ; OCSP échange une dépendance réseau et une fuite de confidentialité potentielle contre un statut plus récent et un téléchargement ciblé. Il ne faut pas prétendre que l’un est le successeur universel de l’autre. Ce serait le genre de simplification qui tient très bien sur une slide et très mal au premier incident DNS.

Pour du TLS (Transport Layer Security) public, une CRL n’est plus un mécanisme primaire crédible côté navigateur. Ses listes peuvent devenir volumineuses, leur diffusion par HTTP (Hypertext Transfer Protocol) dépend de caches externes, et une révocation attend parfois jusqu’à la prochaine publication. Le choix raisonnable reste le certificat de courte durée, OCSP stapling côté serveur quand les clients le prennent en charge, et les mécanismes propres aux navigateurs. Le fonctionnement général d’une chaîne de confiance est détaillé dans l’explication de la PKI.

Pour une PKI (Public Key Infrastructure) interne, la décision dépend surtout de la topologie. Une CRL reste souvent préférable pour des clients isolés, des équipements industriels, des VPN (Virtual Private Network) ou des validateurs sans accès direct au réseau de l’AC. OCSP devient justifié lorsque l’exigence de retrait est inférieure à l’intervalle de publication des CRL et qu’un service de statut hautement disponible existe réellement. Un répondeur unique derrière un nom DNS ne devient pas hautement disponible par incantation.

Validation de révocation et limites protocolaires

Le client ne doit accepter une CRL que si la signature remonte à l’AC attendue, si la période de validité est acceptable et si l’extension de point de distribution correspond à la politique locale. Une CRL correctement signée mais expirée n’est pas une source de vérité, c’est une archive avec une belle signature.

Les CRL delta réduisent le coût de distribution : une CRL complète sert de base et les listes delta publient les changements depuis cette base. Elles introduisent toutefois une dépendance supplémentaire. Le validateur doit posséder la bonne CRL de base, interpréter les numéros de CRL et appliquer la delta correspondante. Sur des bibliothèques partielles ou des équipements réseau minimalistes, cette sophistication produit des faux sentiments de couverture. La CRL complète reste le choix robuste lorsque l’interopérabilité prime sur quelques mégaoctets.

OCSP évite ce téléchargement massif, mais le comportement en cas d’échec est décisif. En mode soft fail, un délai réseau, une panne du répondeur ou un filtrage sortant laisse passer le certificat. En mode hard fail, le même incident bloque le service. Pour un poste de travail sur Internet, le soft fail a longtemps dominé afin de ne pas transformer l’indisponibilité d’une AC en panne globale. Pour une authentification d’administration ou un accès mTLS (mutual TLS) sensible, ce choix peut être inacceptable : il faut alors prévoir une disponibilité du répondeur cohérente avec celle de l’application, pas une promesse de disponibilité écrite à côté de la machine à café.

Une réponse OCSP est cacheable jusqu’à nextUpdate, ou selon une durée locale bornée si ce champ manque. Réutiliser une réponse good ancienne après une révocation est une attaque par rejeu. La politique de validation doit borner l’âge maximal de thisUpdate, vérifier producedAt et refuser les réponses hors fenêtre temporelle. Les horloges des clients comptent ici : une dérive de temps est capable de ressusciter des statuts périmés avec une régularité presque artistique.

La révocation ne coupe pas les sessions déjà établies. Une session TLS négociée avant la révocation peut continuer jusqu’à sa fermeture ou son expiration, selon les paramètres de session et de reprise. Révoquer un certificat client ne révoque pas non plus automatiquement le compte, le jeton d’accès ou les autorisations applicatives associés. Pour les architectures mTLS, il faut combiner cycle de vie du certificat, invalidation de session et contrôle d’identité côté application, comme décrit dans la page mTLS et authentification mutuelle.

Pourquoi les CRL déclinent sans disparaître

Les CRL ont décliné sur le Web pour des raisons physiques, pas parce qu’elles seraient cryptographiquement faibles. Une liste complète grossit avec le nombre de révocations et doit être téléchargée même lorsqu’un seul certificat intéresse le client. Réduire son intervalle de publication améliore la fraîcheur, mais augmente les signatures, les transferts, la pression sur les points de distribution et le risque de cache incohérent.

OCSP réduit ce volume, mais introduit un problème de confidentialité : une requête directe peut révéler au répondeur quel certificat, donc potentiellement quel site ou quel service, est consulté. Le stapling limite cette fuite : le serveur joint une réponse OCSP récente pendant la négociation TLS, sans requête directe du client. Ce sujet mérite un traitement séparé, car il déplace la responsabilité opérationnelle vers le serveur et son cache.

Les navigateurs ont aussi réduit leur dépendance aux consultations OCSP directes. Certains maintiennent des listes de révocation distribuées avec les mises à jour, ou des structures compactes dérivées de listes d’AC. Ces mécanismes sont spécifiques aux éditeurs et ne constituent pas une primitive portable pour une PKI interne. Les importer dans une architecture d’entreprise comme argument d’autorité reviendrait à prendre la météo d’un autre continent pour planifier une intervention locale.

La CRL conserve trois avantages difficiles à remplacer : validation hors ligne, audit facile d’un objet signé et distribution par réplication statique. Dans un environnement fermé, une CRL publiée fréquemment sur des dépôts redondés reste plus prévisible qu’un protocole transactionnel. La bonne question n’est donc pas « CRL ou OCSP ? », mais « quelle latence de révocation est exigée, et quelle dépendance réseau peut être imposée au validateur ? ».

Surface d’attaque de la révocation

Le blocage réseau est l’attaque la plus banale. Empêcher l’accès au point de distribution CRL ou au répondeur OCSP force un comportement de dégradation. La contre-mesure n’est pas technique seulement : documenter explicitement soft fail ou hard fail par flux, tester la perte de connectivité et superviser les erreurs de validation. Un statut non vérifié ne doit jamais être confondu avec un statut positif.

Une CRL ou une réponse OCSP falsifiée échoue si la signature est vérifiée contre le bon émetteur. En revanche, le vol de la clé de signature de l’AC, ou d’une clé de signature OCSP déléguée, permet de publier de faux statuts. La clé d’AC doit rester protégée, idéalement dans un HSM (Hardware Security Module), et la clé du répondeur délégué doit être limitée à l’usage OCSP, surveillée et remplaçable sans reconstruire la hiérarchie.

Le rejeu d’objets signés valides exige une vérification stricte des dates et une durée de cache bornée. Le cache HTTP ne doit pas servir une CRL au-delà de nextUpdate, même si ses en-têtes indiquent une durée plus longue. Inversement, une CRL publiée avec un nextUpdate trop proche déclenche des pannes lors d’une indisponibilité brève de l’AC. La marge doit couvrir la réplication, les caches, les dérives d’horloge et la fenêtre de détection, pas l’optimisme du comité de pilotage.

Enfin, l’extension Must-Staple, présente dans certains certificats TLS, ne garantit pas qu’un serveur fournit une réponse fraîche dans toutes les piles clientes. Elle impose seulement aux clients compatibles d’exiger une preuve agrafée. Cette extension ne répare ni une AC compromise, ni une autorisation applicative excessive, ni une clé privée déjà exfiltrée.

Exploitation : publication, rotation et reprise

Une CRL exige une chaîne opérationnelle complète : base de certificats émis, motif et date de révocation, génération signée, publication redondée, contrôle de disponibilité depuis les réseaux clients et alerte avant nextUpdate. Sauvegarder uniquement la clé de l’AC ne suffit pas. Sans la base d’émission et les numéros de série, la reconstruction de l’état de révocation devient un exercice de divination réglementaire.

L’AC racine devrait rarement signer des CRL opérationnelles volumineuses. Une AC intermédiaire dédiée à un périmètre limite le rayon d’explosion, permet une fréquence adaptée et simplifie le remplacement. La clé de signature des CRL doit suivre une cérémonie de rotation documentée ; son certificat d’AC doit rester disponible dans les magasins de confiance durant toute la transition.

Pour OCSP, le répondeur doit accéder à une source d’état cohérente et répliquée. La réplication asynchrone crée une fenêtre où un certificat révoqué reçoit encore good. Cette fenêtre doit être mesurée et inférieure à l’objectif de révocation annoncé. Pré-générer et mettre en cache les réponses réduit la charge, mais augmente le délai entre une révocation et le statut négatif : le cache est un choix de sécurité, pas un détail de performance.

La supervision doit suivre le nombre de certificats révoqués, l’âge de la dernière CRL, les erreurs de signature, les réponses unknown, la latence OCSP et le taux de validation dégradée. Une hausse de unknown révèle souvent une désynchronisation entre émetteur et répondeur. Ce signal mérite plus d’attention qu’un tableau de bord vert décoratif.

Exemple de vérification CRL et OCSP avec OpenSSL

L’exemple suivant suppose une AC déjà initialisée par OpenSSL, avec une base index.txt, un fichier crlnumber et une section CA_default dans openssl.cnf. La révocation met à jour la base de l’AC : générer une CRL sans cette étape publie une liste parfaitement signée, parfaitement inutile.

# Marquer le certificat comme compromis dans la base de l'autorité de certification.
openssl ca -config openssl.cnf \
  -revoke client.pem \
  -crl_reason keyCompromise

# Générer puis inspecter la liste de révocation signée par l'AC émettrice.
openssl ca -config openssl.cnf -gencrl -out issuer.crl.pem
openssl crl -in issuer.crl.pem -noout -text

# Vérifier localement le certificat contre la chaîne et la CRL.
openssl verify -CAfile issuer-chain.pem \
  -CRLfile issuer.crl.pem \
  -crl_check client.pem

# Interroger un répondeur OCSP sans nonce afin de tester le comportement cacheable.
openssl ocsp -issuer issuer-ca.pem -cert client.pem \
  -url http://ocsp.example.invalid \
  -CAfile issuer-chain.pem -no_nonce

Le dernier appel doit retourner revoked après propagation de l’état au répondeur. Un retour good juste après la révocation ne prouve pas qu’OCSP est défaillant : il peut révéler un cache, une réplication retardée ou une interrogation du mauvais émetteur. Ces trois causes doivent être distinguées avant de modifier une politique de sécurité.

🐝 Ce qui arrive si on s’en passe

Sans mécanisme de révocation vérifié, un certificat volé ou compromis reste accepté jusqu’à son expiration, même si sa clé privée circule déjà. Le validateur continue d’établir des sessions de confiance avec un porteur qui ne devrait plus rien ouvrir. Un contrôle mal réglé aggrave le problème : en soft fail, un simple blocage réseau du point de distribution CRL ou du répondeur OCSP laisse passer le certificat comme si de rien n’était, et un statut non vérifié est traité comme un statut positif. Une réponse ancienne rejouée après une révocation ressuscite un certificat retiré si les dates ne sont pas bornées, une dérive d’horloge suffisant à rouvrir la fenêtre. Sans base d’émission conservée avec les numéros de série et les motifs, reconstruire l’état de révocation après incident devient impossible, et la traçabilité des retraits disparaît.

🦫 Explication de la marmotte 🍫

Un certificat est un document numérique qui permet de prouver l’identité d’un serveur, d’une application ou d’une personne. Il possède une date de fin, mais il peut devoir être retiré avant cette date, par exemple si sa clé secrète a été volée.

Une première méthode publie régulièrement une liste signée des certificats retirés. L’appareil qui vérifie un certificat télécharge cette liste, contrôle qu’elle vient bien de l’organisme qui a émis le certificat, puis cherche son numéro dans la liste. Cette méthode continue à fonctionner sans contact permanent avec l’organisme émetteur, mais la liste peut être ancienne jusqu’à sa prochaine publication.

Une seconde méthode demande l’état d’un seul certificat à un service en ligne. Ce service répond qu’il est encore accepté, retiré, ou inconnu. La réponse peut être plus récente, mais la vérification dépend alors du réseau et de la disponibilité du service. Si le service est inaccessible, il faut décider à l’avance si l’accès est refusé ou accepté malgré l’absence de réponse.

Dans les deux cas, vérifier la signature, les dates et l’identité de l’émetteur est obligatoire. Une ancienne réponse ne doit pas être réutilisée trop longtemps. Retirer un certificat n’interrompt pas forcément une connexion déjà ouverte, et ne désactive pas automatiquement un compte ou un droit d’accès. Ces éléments doivent être gérés séparément.

Pages voisines

La citent

CRL ou OCSP pour révoquer un certificat

Elle cite

: les deux pages se citent l’une l’autre.

CRL ou OCSP pour révoquer un certificat

CRL ou OCSP pour révoquer un certificat

CRL et OCSP : le compromis entre fraîcheur et autonomie

Validation de révocation et limites protocolaires

Pourquoi les CRL déclinent sans disparaître

Surface d’attaque de la révocation

Exploitation : publication, rotation et reprise

Exemple de vérification CRL et OCSP avec OpenSSL

🐝 Ce qui arrive si on s’en passe

🦫 Explication de la marmotte 🍫

À lire aussi

Pages voisines