OCSP stapling pour vérifier la révocation TLS

OCSP (Online Certificate Status Protocol) stapling déplace la vérification de révocation du client vers le serveur TLS (Transport Layer Security). Le compromis central est net : moins de latence et moins de fuite de confidentialité côté client, contre une responsabilité opérationnelle supplémentaire côté serveur. Cette responsabilité doit être acceptée, surveillée et testée, pas déposée dans une configuration copiée d’un blog fossilisé.

→ Lire l’explication complète de la marmotte

OCSP stapling : le compromis à accepter

Un certificat X.509 lie une clé publique à une identité, pour une période donnée. Sa date d’expiration borne sa validité, mais ne permet pas de retirer rapidement un certificat compromis, émis par erreur ou associé à une clé privée divulguée. La révocation répond à ce besoin, avec une efficacité qui dépend entièrement de la façon dont le statut est distribué.

Sans stapling, le client extrait l’URL du répondeur OCSP depuis l’extension Authority Information Access du certificat, puis demande si son numéro de série est good, revoked ou unknown. Cette requête ajoute une dépendance réseau sur le chemin de connexion. Elle révèle aussi au répondeur de l’autorité de certification quel nom de service le client consulte, à quel moment, et souvent depuis quelle adresse réseau. La confidentialité offerte par TLS s’arrête alors poliment devant la porte du répondeur de révocation.

Avec OCSP stapling, le serveur récupère périodiquement une réponse OCSP signée par l’autorité de certification, la conserve en cache et la joint à la poignée de main TLS. Le client vérifie localement la signature, le numéro de série, le statut, ainsi que les bornes temporelles thisUpdate et nextUpdate. Aucun aller-retour supplémentaire n’est nécessaire côté client.

La recommandation est de déployer OCSP stapling pour les services HTTPS (Hypertext Transfer Protocol Secure) publics dès lors que le frontal TLS peut actualiser et contrôler son cache. Ce mécanisme doit être considéré comme une optimisation de disponibilité et de confidentialité, pas comme une preuve absolue de non-compromission. Pour le socle de validation TLS, voir le fonctionnement de TLS et les fondations PKI.

Le gain n’est pas cosmétique. Les navigateurs ont historiquement adopté des politiques variées face aux échecs OCSP, souvent dites soft fail : si le répondeur est injoignable, certains continuent la connexion. Ce choix évite qu’une panne d’autorité de certification devienne une panne mondiale, mais il affaiblit la révocation au moment exact où elle serait attendue. Stapler une réponse valide réduit cette zone grise. Il ne la fait pas disparaître.

Réponses OCSP, fraîcheur et chaîne de confiance

Une réponse staplée est un objet signé. Le serveur ne peut pas fabriquer arbitrairement un statut good, sauf à disposer de la clé de signature autorisée par l’émetteur du certificat. Le client doit valider cette signature contre le certificat de l’autorité de certification, ou contre un certificat délégué à la signature OCSP portant l’usage étendu OCSPSigning.

La réponse couvre un certificat précis, identifié notamment par son numéro de série et son émetteur. Réutiliser une réponse entre certificats est donc inutile, sauf pour produire des erreurs de diagnostic assez artistiques. Le cache doit être partitionné au minimum par certificat de feuille et par émetteur.

La fraîcheur est le vrai paramètre d’architecture. thisUpdate indique le début de validité annoncé de la réponse, nextUpdate sa fin. Une réponse expirée doit être rejetée. Lorsqu’une autorité n’émet pas nextUpdate, les clients appliquent leurs propres limites de fraîcheur ; cela rend le comportement moins prédictible et doit être vérifié sur les clients effectivement supportés.

Le frontal doit rafraîchir la réponse avant son expiration, avec une marge qui absorbe les erreurs DNS (Domain Name System), les indisponibilités transitoires du répondeur et les redémarrages. Attendre nextUpdate pour commencer le renouvellement est une stratégie de disponibilité comparable à commander un extincteur après avoir senti la fumée.

La chaîne de certificats envoyée par le serveur compte aussi. Le frontal doit connaître le certificat intermédiaire émetteur afin de vérifier la réponse reçue. Un fichier ne contenant que le certificat de feuille peut suffire à établir certaines connexions TLS, mais échouer à rafraîchir OCSP. Cette dissociation est un piège classique : la poignée de main reste verte, le stapling se vide, puis la supervision découvre le problème avec l’enthousiasme d’une alarme incendie sans piles.

Configuration Nginx et vérification reproductible

Nginx peut récupérer et mettre en cache les réponses OCSP si le certificat de feuille, la chaîne intermédiaire et un résolveur sont configurés. Le résolveur est requis parce que l’URL du répondeur peut contenir un nom à résoudre au moment du rafraîchissement.

server {
    listen 443 ssl;
    server_name service.example.net;

    # Certificat de feuille suivi des certificats intermédiaires.
    ssl_certificate     /etc/nginx/tls/service.fullchain.pem;
    ssl_certificate_key /etc/nginx/tls/service.key;

    # Chaîne utilisée par Nginx pour vérifier la réponse reçue du répondeur.
    ssl_trusted_certificate /etc/nginx/tls/issuer-chain.pem;

    # Active la récupération, le cache et l'envoi de la réponse signée.
    ssl_stapling on;
    ssl_stapling_verify on;

    # Résolveur joignable depuis le processus Nginx, avec délai borné.
    resolver 192.0.2.53 valid=300s;
    resolver_timeout 5s;
}

Après rechargement, vérifier d’abord la syntaxe, puis interroger le service avec OpenSSL (Open Secure Sockets Layer) :

# Le champ "OCSP Response Status: successful" atteste une réponse reçue.
# "Cert Status: good" atteste le statut du certificat présenté.
openssl s_client \
  -connect service.example.net:443 \
  -servername service.example.net \
  -status </dev/null 2>/dev/null | sed -n '/OCSP response:/,/---/p'

Cette commande ne valide pas toute la politique navigateur. Elle confirme que le serveur joint quelque chose et expose les dates de la réponse. Vérifier aussi les journaux Nginx au démarrage et lors du renouvellement : erreur de résolution, absence d’URL OCSP dans le certificat, chaîne de confiance incomplète, réponse rejetée ou délai expiré.

Un redémarrage à froid peut vider le cache selon le frontal utilisé. Tester ce cas explicitement. Un mécanisme qui ne marche qu’après plusieurs minutes de trafic n’est pas une protection, c’est une superstition avec métriques.

Surface d’attaque et limites de la révocation

OCSP stapling ne révoque rien. L’autorité de certification conserve la capacité de publier le statut, et le serveur ne fait que transporter une preuve signée. Si l’autorité tarde à publier la révocation, si le certificat intermédiaire est compromis, ou si le client n’applique pas la réponse, le stapling ne corrige aucun de ces défauts.

Une réponse good reste acceptable jusqu’à sa limite de fraîcheur. Après compromission d’une clé privée, un attaquant peut donc présenter le certificat avec une réponse précédemment capturée tant qu’elle demeure valide, selon la politique du client. Réduire les durées de validité des certificats limite l’exposition, mais augmente la cadence de renouvellement. La PKI (Public Key Infrastructure) n’offre pas de bouton magique, malgré les présentations où tout tient sur trois hexagones bleus.

Le mécanisme ne protège pas les sessions TLS déjà établies. La révocation d’un certificat ne se propage pas aux connexions existantes, ni aux jetons applicatifs émis sur cette base. La réponse doit venir des durées de session, de la réauthentification, de l’invalidation des jetons et de la rotation de secrets applicatifs. Pour l’authentification mutuelle, la question est encore plus sévère : consulter mTLS pour séparer l’identité serveur de l’identité cliente.

L’attaque de blocage reste possible. Un adversaire capable d’empêcher le frontal de joindre le répondeur peut provoquer l’expiration du cache. Selon la configuration, le serveur peut alors ne plus stapler, ou conserver une réponse périmée qui sera rejetée. La contre-mesure n’est pas de désactiver la vérification : prévoir une connectivité sortante contrôlée, plusieurs résolveurs, une alerte avant nextUpdate, et une procédure de renouvellement de certificat qui inclut la vérification du stapling.

Le mode Must-Staple, extension TLS Feature d’un certificat, demande aux clients compatibles de refuser le certificat si aucune réponse staplée valide n’est fournie. Son emploi impose une exploitation mature : supervision de fraîcheur, tests après renouvellement, disponibilité du répondeur et capacité à restaurer rapidement le frontal. Sans ces garanties, Must-Staple transforme une panne de dépendance externe en indisponibilité visible. Ce n’est pas du durcissement si le service tombe parce qu’un cache a éternué.

Exploitation : rotation, supervision et reprise

La rotation d’un certificat invalide le cache associé à l’ancien numéro de série. Après chaque renouvellement, contrôler quatre faits : le nouveau certificat est servi, sa chaîne intermédiaire est complète, une réponse correspondant au nouveau numéro de série est staplée, et sa date nextUpdate est suffisamment éloignée. Contrôler seulement la date d’expiration du certificat laisse précisément le défaut le plus fréquent hors du tableau de bord.

La supervision doit distinguer l’absence de réponse, une réponse invalide et une réponse bientôt expirée. Exporter ou collecter les métriques du frontal quand elles existent, sinon exécuter une sonde externe avec openssl s_client -status. Déclencher une alerte avant l’expiration avec une marge supérieure à la période normale de rafraîchissement et au délai de correction réaliste. Une alerte à nextUpdate est un rapport d’autopsie déguisé.

Les clés privées de serveur ne participent pas à la signature OCSP. Leur protection reste néanmoins déterminante : stockage à accès minimal, permissions strictes, rotation documentée et, lorsque le niveau de risque le justifie, HSM (Hardware Security Module). La sauvegarde doit couvrir les configurations, certificats, chaînes intermédiaires et procédures de restauration, pas nécessairement la clé privée si une politique impose sa régénération. Restaurer un ancien certificat révoqué parce qu’il figurait dans une sauvegarde est une manière coûteuse de découvrir que les sauvegardes conservent aussi les mauvaises idées.

🐝 Ce qui arrive si on s’en passe

Sans stapling, la vérification de révocation repose sur une requête que le client émet lui-même, généralement en HTTP non chiffré : tout observateur du réseau lit alors le numéro de série interrogé et en déduit le service consulté, même si le DNS est chiffré et le nom de serveur masqué dans la poignée de main. Surtout, l’attaquant qui détient une clé privée volée doit se placer sur le chemin réseau pour l’exploiter ; depuis cette position, bloquer la requête OCSP ne lui coûte rien, et un client en soft fail accepte alors le certificat révoqué sans aucune trace côté serveur. L’option Must-Staple devient inutilisable, ce qui supprime le seul moyen de rendre ce refus obligatoire pour les clients compatibles.

🦫 Explication de la marmotte 🍫

Un site sécurisé présente un certificat, un document numérique qui prouve son identité et contient une clé publique. Ce document a une date de fin, mais il peut devoir être annulé avant cette date, par exemple si la clé privée associée a été volée. L’organisme qui a délivré le certificat publie alors son état : encore valable, annulé ou inconnu.

Sans mécanisme supplémentaire, le navigateur doit demander lui-même cet état à l’organisme émetteur. Cette demande prend du temps, peut échouer et indique à cet organisme quel site est visité. Avec le stapling, le serveur du site demande régulièrement cet état signé, le garde temporairement, puis le transmet pendant la connexion sécurisée.

Le navigateur vérifie que la réponse porte bien sur le certificat reçu, qu’elle a été signée par l’organisme autorisé et qu’elle est encore récente. Si ces contrôles passent, il évite une demande séparée. Si la réponse manque, est expirée ou ne correspond pas au certificat, le comportement dépend du navigateur et des règles imposées par le certificat : certains refusent la connexion, d’autres continuent.

Le serveur doit donc renouveler cette preuve avant son expiration, surveiller les erreurs et recommencer après un changement de certificat. Ce mécanisme ne coupe pas les connexions déjà ouvertes et ne remplace ni la protection de la clé privée ni la gestion des sessions applicatives.

Pages voisines

La citent

OCSP stapling pour vérifier la révocation TLS

Elle cite

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

OCSP stapling pour vérifier la révocation TLS

OCSP stapling pour vérifier la révocation TLS

OCSP stapling : le compromis à accepter

Réponses OCSP, fraîcheur et chaîne de confiance

Configuration Nginx et vérification reproductible

Surface d’attaque et limites de la révocation

Exploitation : rotation, supervision et reprise

🐝 Ce qui arrive si on s’en passe

🦫 Explication de la marmotte 🍫

À lire aussi

Pages voisines