OCSP face à une CRL : comment fonctionne réellement chaque contrôle de révocation

L’un de ces deux contrôles de révocation renvoie une réponse signée sur un seul certificat, et l’autre renvoie une liste signée que vous téléchargez en entier. Les deux doivent dire à un vérificateur si un justificatif est toujours digne de confiance, et les deux échouent de manières qui ne se ressemblent pas du tout. L’ordre ci-dessous suit ce qu’un opérateur rencontre réellement en production, en commençant par les octets sur le réseau et en finissant par une passerelle qui refuse une connexion. Sauter une étape est la façon dont un déploiement finit avec une politique de révocation qui n’existe que sur le papier.

Étape 1 : Ce que chaque contrôle renvoie et combien de temps il reste utilisable

Une CRL est publiée comme un unique objet signé couvrant chaque certificat qu’un émetteur a révoqué, si bien qu’un vérificateur la récupère une fois et la réutilise jusqu’à ce que le nextUpdate de la liste soit passé. Une réponse OCSP est plus étroite : elle répond exactement pour un certificat et porte thisUpdate, producedAt et généralement nextUpdate aussi. Cette différence commande tout le reste. Une CRL mise en cache vieillit en silence, car le fichier s’analyse encore et sa signature se vérifie encore, alors qu’une réponse OCSP expirée est manifestement sans valeur dès que vous lisez ses horodatages.

La mise en cache est donc la première chose à fixer : quel composant détient la copie, et quel plafond cette copie respecte. Sur une passerelle, le plafond doit être nextUpdate moins une marge de sécurité, jamais ce qu’un en-tête de cache HTTP suggère par hasard. openssl crl -in issuer.crl -noout -lastupdate -nextupdate affiche les deux dates, et une liste dont le nextUpdate est déjà dans le passé doit être traitée comme manquante et non simplement comme ancienne.

Étape 2 : Où le certificat envoie le client

Le certificat feuille porte généralement deux indices : une extension de point de distribution CRL et une entrée d’accès aux informations de l’autorité pour OCSP. openssl x509 -in client.pem -noout -ext crlDistributionPoints affiche le premier, et le second se trouve dans la section AIA de openssl x509 -in client.pem -noout -text. Chacune de ces extensions est un pointeur, pas une obligation. Un client qui n’implémente jamais le contrôle de révocation se connectera parfaitement bien à un certificat dont les extensions nomment un répondeur mort depuis un an.

Les points de distribution nomment souvent un hôte interne qui ne se résout qu’à l’intérieur d’un segment réseau, et certains clients plus anciens refusent carrément les URL ldap. Testez la joignabilité depuis l’hôte qui termine le tunnel, pas depuis votre propre portable, car c’est le seul point de vue dont l’échec compte vraiment.

Étape 3 : Choisissez fail-closed ou fail-open avant la panne

Un répondeur injoignable ou une liste expirée force une décision : refuser la connexion, ou l’accepter et consigner le manque. La sous-commande verify d’OpenSSL rend le choix strict explicite, car ajouter -crl_check transforme une CRL indisponible en unable to get certificate CRL et en une vérification échouée. Le soft-fail, dans la plupart des piles, n’est pas un drapeau du tout, c’est l’absence du contrôle, et c’est exactement pourquoi il arrive par accident.

Pour voir quel comportement un client a réellement, retirez le répondeur et reconnectez-vous. Si le tunnel monte encore, trouvez la ligne de journal qui a consigné le contrôle sauté, puis demandez-vous si quelqu’un lirait cette ligne pendant un incident. Un même fournisseur peut différer selon le protocole, avec un client IKEv2 et un client OpenVPN sur une machine qui lisent des réglages sans rapport.

Étape 4 : Prouvez que le contrôle s’exécute là où le trafic est admis

Trouvez le processus qui termine ou autorise la connexion, puis demandez-lui la ligne de configuration qui active le contrôle de révocation. Une passerelle qui valide la chaîne mais ne demande jamais rien sur la révocation applique une politique différente de celle de votre documentation, et aucune capture d’écran d’une chaîne de certificats ne prouve le contraire. OpenVPN écrit l’option comme crl-verify ; strongSwan garde les recherches CRL et OCSP dans la configuration de la CA, où crl_uris ou ocsp_uris sont définis. Si vous ne pouvez pointer vers ni l’une ni l’autre, supposez que le contrôle est absent.

Une réponse OCSP ne compte que lorsque la CA émettrice l’a signée, ou lorsqu’un répondeur détenant l’usage étendu de clé OCSPSigning délégué par cette CA l’a signée, si bien qu’une réponse d’un service sans rapport ne prouve rien. Si vous exploitiez vous-même le répondeur, surveillez-le comme une dépendance dure, car un seul service mort devient une panne pour chaque client fail-closed à la fois.

Étape 5 : Révoquez un certificat exprès

Prenez un certificat de test, révoquez-le par le même canal que celui utilisé en production, et interrogez directement le répondeur. openssl ocsp -issuer ca.pem -cert old.pem -url http://ocsp.example.net -resp_text devrait signaler Cert Status: revoked avec une heure de révocation, et une réponse good signifie que votre révocation n’a pas atteint le répondeur que vos clients interrogent. Exécutez ensuite openssl verify -crl_check -CRLfile issuer.crl -CAfile ca.pem old.pem pour voir la même décision par le chemin de la liste. Lisez la chaîne de raison plutôt que le code de sortie, car un rejet pour révocation et une erreur de chaîne finissent tous deux en échec.

L’étape qui compte vraiment est la dernière : reconnectez-vous avec l’ancien profil face au point d’application réel et confirmez que le refus vient de la révocation. Reconnectez-vous ensuite avec un certificat neuf et valide pour prouver que vous n’avez pas seulement cassé l’écouteur. Supprimer le profil sur le client ne prouve rien sur la décision du serveur, et une exécution réussie de openssl verify sur une machine qui ne termine jamais un tunnel non plus. RFC 6960 définit ce que contient une réponse OCSP conforme, y compris les valeurs de statut que ce test lit.