OCSP stapling expliqué (et pourquoi c’est optionnel)
Mis à jour le 2026-11-03 · 5 min de lecture
La vérification de révocation est le maillon faible de la chaîne de certificats : le navigateur doit demander à un tiers si un certificat est encore valide, et cette question divulgue le visiteur à l’AC. Le stapling déplace la réponse dans la poignée de main.
Le problème de l’OCSP simple
Quand un navigateur reçoit un certificat, il peut interroger le répondeur OCSP de l’AC pour vérifier si le certificat a été révoqué. Cette requête est une connexion séparée vers un tiers, ajoute de la latence et révèle quel site le visiteur consulte — avant même que la page ne soit chargée.
Si le répondeur est lent ou injoignable, les navigateurs soit laissent passer (ignorent la vérification), soit bloquent le site, selon le client. Ni l’un ni l’autre n’est bon.
Ce que le stapling change
Avec le stapling, le serveur récupère lui-même la réponse OCSP signée, la met en cache et l’attache à la poignée de main TLS. Le navigateur obtient la réponse de révocation sans contacter quiconque : pas d’aller-retour supplémentaire, pas de fuite.
Cela supprime aussi la dépendance à la joignabilité de l’AC depuis le réseau du visiteur, ce qui compte dans les régions où les répondeurs OCSP sont intermittemment bloqués.
L’activer et le vérifier
Sur nginx, le stapling nécessite un resolver et le fichier de chaîne, sinon il ne fait silencieusement rien. Sur Apache, la directive de cache doit être au niveau serveur. Après rechargement, vérifiez depuis l’extérieur — une ligne de configuration présente mais inactive est identique à une ligne absente.
# nginx
ssl_stapling on;
ssl_stapling_verify on;
ssl_trusted_certificate /etc/letsencrypt/live/example.com/chain.pem;
resolver 1.1.1.1 8.8.8.8 valid=300s;
# verify from outside — look for a stapled response, not just "OCSP response: none"
openssl s_client -connect example.com:443 -status -servername example.com </dev/null 2>/dev/null | grep -A3 "OCSP Response Status"
Pourquoi ce n’est pas exigé pour A+
Le stapling est une amélioration de confidentialité et de latence, pas de robustesse du protocole. Un serveur qui ne staple pas n’est pas moins sûr de la même façon qu’un serveur proposant TLS 1.0. CertH le traite comme un signal positif dans la section santé de la configuration, mais ne l’exige pas pour la meilleure note.
Cela dit, c’est l’un des gains les moins chers : deux lignes de configuration, aucun impact client, et un gain de confidentialité mesurable pour chaque visiteur.
FAQ
Le stapling casse-t-il si le répondeur de l’AC est indisponible ?
Le serveur continue de servir la dernière réponse en cache jusqu’à son expiration. Avec nginx, un rafraîchissement échoué retombe sur la copie en cache, d’où la nécessité d’un resolver et d’un fichier de chaîne valide pour un comportement fiable.
must-staple vaut-il la peine ?
Seulement si le stapling est parfaitement stable. L’extension must-staple fait rejeter la connexion aux clients quand aucune réponse staplée n’est présente : une panne de cache ou de resolver devient donc une panne de service.