La Fibre

Télécom => Réseau => reseau Protocoles réseaux sécurisés (https) => Discussion démarrée par: vivien le 18 janvier 2018 à 13:32:11

Titre: Pb OCSP Stapling chez Let's Encrypt
Posté par: vivien le 18 janvier 2018 à 13:32:11
Les serveurs ocsp sont opérationnels (cf https://letsencrypt.status.io/), pourtant j'ai l'erreur suivante sur un de mes noms de domaines :

(https://lafibre.info/images/ssl/201801_letsencrypt_SEC_ERROR_OCSP_TRY_SERVER_LATER.png)

Un restart de Apache permet de résoudre le problème.

Pas moyen de demander à Apache de ré-essayer en cas d'erreur ?
Titre: OCSP Stapling Let's Encrypt
Posté par: alain_p le 18 janvier 2018 à 14:11:21
Une petite recherche sur Internet m'a conduit à cette recommandation, ajouter ces deux lignes dans la configuration d'apache.

SSLUseStapling on
SSLStaplingCache shmcb:/tmp/stapling_cache(128000)
qui permettrait, selon la documentation Apache de faciliter la communication entre le client et le serveur sur la vérification de la révocation des certificats.

Voir :
https://www.ndchost.com/wiki/apache/fix-error-ocsp-try-server-later-in-firefox

Selon la doc apache, ces deux lignes seraient dans la configuration par défaut, mais commentées à partir de la version 2.4.11. Il suffirait de les décommenter (dans conf/extra/httpd-ssl.conf ?). Par contre la valeur par défaut du cache serait de 32768. Dans l'exemple donné ci-dessus, elle aurait été augmentée à 128000.

https://wiki.apache.org/httpd/OCSPStapling
Titre: OCSP Stapling Let's Encrypt
Posté par: vivien le 18 janvier 2018 à 18:45:29
Merci Alain,

J'avais bien ces deux lignes dans mon Apache 2.4.18 :
        SSLUseStapling on
        SSLStaplingCache shmcb:${APACHE_RUN_DIR}/stapling_cache(150000)

Cela reste un mystère...
Titre: OCSP Stapling Let's Encrypt
Posté par: vivien le 19 janvier 2018 à 13:31:26
Coté log Apache, cela donne ceci :

[Thu Jan 18 13:14:06.321673 2018] [ssl:error] [pid 27445] AH01941: stapling_renew_response: responder error
[Fri Jan 19 13:18:53.277487 2018] [ssl:error] [pid 20704] AH01941: stapling_renew_response: responder error

Le serveur héberge 5 certificats Let's Encrypt et seul le nom de domaine presque inutilisé est impacté.

Je me demande si la taille de stapling_cache n'est pas trop petite, si c'est mutualisé avec les différents nom de domaines.

Je viens de passer de
SSLStaplingCache shmcb:${APACHE_RUN_DIR}/stapling_cache(150000)
à :
SSLStaplingCache shmcb:${APACHE_RUN_DIR}/stapling_cache(512000)J'ai donc maintenant 512 Ko pour OCSP
Titre: OCSP Stapling Let's Encrypt
Posté par: jack le 19 janvier 2018 à 13:34:14
Le support dans apache est naze : si le serveur en face ne fonctionne pas, tes clients se font défoncer

ocsp stapling fonctionne bien mieux chez nginx (si tu ne reload pas ton démon tout les 10sec) et, apparement, chez haproxy
Titre: Pb OCSP Stapling chez Let's Encrypt
Posté par: alain_p le 19 janvier 2018 à 14:52:47
Il faut peut-être au contraire désactiver ocsp stapling (donc le commenter). Je suis tombé sur ce post sur le forum Let's Encrypt :

Citer
However, with OCSP stapling problems that used to definitely be with the OCSP server, now might be trouble on your web server. Apache is definitely capable of fetching a “try later” response and then stapling that to certificates and sending those over, which is, -ugh- I don’t know how they thought that option was helpful.

If you definitely have, or think you might have, OCSP stapling enabled, then short of disabling it, which may not be possible from cpanel, you could try restarting the Apache server itself if that’s possible and then try the site a couple of time, leaving a few seconds between each try ? I think that when it’s restarted it will fetch a fresh OCSP response and so it might get a good response this time.

https://community.letsencrypt.org/t/ocsp-error-is-taking-down-my-site-in-firefox/19496

C'est peut-être pour cela qu'il est commenté par défaut ?