La demande venait d’un audit de performance externe, qui pointait un délai anormal dans l’établissement de la connexion TLS sur un site WordPress à fort trafic international. En creusant les traces réseau, la cause est apparue clairement : à chaque nouvelle connexion, le navigateur du visiteur interrogeait séparément le répondeur OCSP de l’autorité de certification pour vérifier que le certificat n’avait pas été révoqué, ajoutant un aller-retour réseau complet avant même que la page ne commence à charger.
OCSP (Online Certificate Status Protocol) est le mécanisme qui permet de vérifier en temps réel si un certificat TLS a été révoqué par son autorité de certification, sans devoir télécharger une liste complète de révocation. Le problème n’est pas le mécanisme en lui-même, mais son exécution par défaut : chaque navigateur, pour chaque nouvelle connexion, doit contacter lui-même le répondeur OCSP de l’autorité, un serveur potentiellement éloigné géographiquement du visiteur, ce qui ajoute une latence variable et parfois significative.
Le principe du stapling : le serveur porte la vérification
Le stapling OCSP renverse cette logique. Plutôt que de laisser chaque navigateur interroger séparément le répondeur OCSP, c’est le serveur web lui-même qui interroge périodiquement ce répondeur, en cache la réponse signée, et la joint (« staple », agrafe en anglais) directement à la poignée de main TLS lors de chaque connexion. Le navigateur reçoit ainsi la preuve de non-révocation en même temps que le certificat, sans avoir à effectuer sa propre requête réseau vers l’autorité de certification.
Ce changement profite particulièrement aux visiteurs géographiquement éloignés du répondeur OCSP de l’autorité de certification utilisée : sans stapling, ces visiteurs subissent la latence complète de cette requête distante à chaque nouvelle connexion, un coût invisible mais bien réel sur le temps de chargement perçu.
Configuration nginx, avec le piège du resolver
Activer le stapling OCSP sous nginx demande une poignée de directives dans le bloc serveur HTTPS :
server {
listen 443 ssl;
server_name exemple.fr;
ssl_certificate /etc/letsencrypt/live/exemple.fr/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/exemple.fr/privkey.pem;
ssl_stapling on;
ssl_stapling_verify on;
ssl_trusted_certificate /etc/letsencrypt/live/exemple.fr/chain.pem;
resolver 1.1.1.1 8.8.8.8 valid=300s;
resolver_timeout 5s;
}La directive resolver est celle qui est le plus souvent oubliée, et qui explique la majorité des cas où le stapling ne fonctionne pas malgré une configuration en apparence correcte. nginx a besoin de résoudre lui-même le nom d’hôte du répondeur OCSP de l’autorité de certification pour pouvoir l’interroger périodiquement ; sans résolveur DNS explicitement déclaré, cette résolution échoue silencieusement, et nginx continue de servir le certificat normalement, mais sans jamais joindre la réponse OCSP attendue.
La directive ssl_trusted_certificate pointe vers la chaîne de certificats intermédiaires (hors certificat final), nécessaire à nginx pour vérifier lui-même la signature de la réponse OCSP reçue de l’autorité, avant de la transmettre au navigateur du visiteur.
Vérifier que le stapling fonctionne réellement
Une configuration qui ne remonte aucune erreur au démarrage de nginx n’est pas nécessairement une confirmation que le stapling fonctionne en pratique. La vérification se fait en interrogeant directement la connexion TLS établie :
echo | openssl s_client -connect exemple.fr:443 -status 2>/dev/null | grep -A 5 "OCSP Response"Une réponse contenant OCSP Response Status: successful confirme que le stapling fonctionne correctement. L’absence de cette mention, ou un message indiquant no response sent, signale généralement le problème de résolveur DNS décrit précédemment, ou plus rarement, un répondeur OCSP de l’autorité de certification temporairement indisponible.
- Vérifier les logs d’erreur nginx après un rechargement de configuration : une erreur de résolution DNS liée au stapling y apparaît explicitement si le resolver est mal configuré.
- Tester depuis un point de sortie réseau différent du serveur lui-même si possible, certains environnements réseau internes filtrant les résolveurs DNS publics utilisés dans l’exemple.
- Recharger la configuration nginx (
nginx -s reload) après toute modification de ces directives : un redémarrage complet n’est pas nécessaire pour ce changement.
Le stapling OCSP est l’une des optimisations TLS les plus simples à activer et les plus systématiquement oubliées sur les configurations nginx que nous reprenons chez de nouveaux clients, alors qu’elle ne demande que quelques lignes et aucun changement côté certificat lui-même.
En résumé
Le stapling OCSP sous nginx élimine un aller-retour réseau superflu à chaque connexion TLS, en laissant le serveur porter lui-même la vérification de non-révocation du certificat. La configuration reste simple, à condition de ne pas oublier la directive resolver, indispensable pour que nginx puisse effectivement interroger le répondeur OCSP de l’autorité de certification en amont. Ce réglage n’a aucun impact sur le choix de l’autorité de certification elle-même, qui reste un sujet distinct.
