Lua-resty-auto-ssl: Agrafage OCSP : le réseau est inaccessible

As-tu précisé le résolveur ?
resolver 8.8.8.8;

Oui

cela ressemble à un problème d'infrastructure, comme si vous n'écoutiez pas sur le port 80. utilisez-vous docker ?

Oui

vous pouvez essayer ma propre image et voir si cela fonctionne : https://hub.docker.com/r/pushtospace/nginx/

Je vais essayer si j'ai le temps.
Mien:

FROM openresty/openresty:latest-xenial
RUN /usr/local/openresty/luajit/bin/luarocks install lua-resty-auto-ssl
RUN openssl req -new -newkey rsa:2048 -days 3650 -nodes -x509 \
      -subj '/CN=sni-support-required-for-valid-ssl' \
      -keyout /etc/ssl/resty-auto-ssl-fallback.key \
      -out /etc/ssl/resty-auto-ssl-fallback.crt
ADD nginx.conf /usr/local/openresty/nginx/conf/nginx.conf
RUN mkdir -p /etc/resty-auto-ssl/storage/file/
VOLUME ["/etc/resty-auto-ssl/storage/file/"]

@serathius : Cela semble échouer lorsque votre serveur essaie de faire une demande sortante au serveur OCSP de Let's Encrypt. À partir de ce même serveur sur lequel vous avez installé lua-resty-auto-ssl, pouvez-vous établir manuellement une connexion au serveur OCSP Let's Encrypt par défaut ? Vous pouvez tester cela avec cette commande :

curl -v "http://ocsp.int-x3.letsencrypt.org/"

Vous devriez voir une réponse avec un statut "200 OK". Si vous ne voyez pas cela, pouvez-vous poster le résultat ? Ou y a-t-il quelque chose sur votre réseau auquel vous pouvez penser qui empêcherait cette demande sortante ?

Il convient également de noter que dans ce cas, vous devez toujours disposer d'un certificat SSL valide, malgré l'erreur dans le fichier journal. Cela signifie simplement que l' agrafage OCSP a échoué, c'est donc au client d'effectuer toute validation OCSP.

Peut-être que cela a quelque chose à voir avec IPv6 ? j'ai compris

2016/08/31 04:58:27 [error] 31119#0: unexpected response for ocsp.int-x3.letsencrypt.org
2016/08/31 04:58:28 [error] 31119#0: connect() to [2001:428:4402:108::419e:2f9a]:80 failed (101: Network is unreachable), context: ssl_certificate_by_lua*, client: 50.4.134.47, server: 0.0.0.0:443
2016/08/31 04:58:28 [error] 31119#0: [lua] ssl_certificate.lua:203: set_cert(): auto-ssl: failed to set ocsp stapling for staging.example.com - continuing anyway - failed to get ocsp response: OCSP responder query failed (http://ocsp.int-x3.letsencrypt.org/): network is unreachable, context: ssl_certificate_by_lua*, client: snip, server: 0.0.0.0:443

Après avoir actualisé la page une fois qu'elle apparaît avec une page https fonctionnelle.

Pareil ici, une idée de ce qui ne va pas ?

2016/10/18 18:38:30 [error] 18084#18084: *24710 [lua] ssl_certificate.lua:203: set_cert(): auto-ssl: failed to set ocsp stapling for www.franklpharma.cz - continuing anyway - failed to get ocsp response: OCSP responder query failed (http://ocsp.int-x3.letsencrypt.org/): network is unreachable, context: ssl_certificate_by_lua*, client: 10.135.30.111, server: 0.0.0.0:443
2016/10/18 18:38:54 [error] 18084#18084: *24729 connect() to [2a02:26f0:122::215:f618]:80 failed (101: Network is unreachable), context: ssl_certificate_by_lua*, client: 10.135.30.111, server: 0.0.0.0:443

Nous subissons un gel Nginx/Openresty (la page nginx_status ne se charge pas, les journaux sont vides) tous les aprox. 10 heures. Est-ce lié? Toute idée de comment résoudre ce problème? Merci

PS Je ne reconnais pas ces adresses IPv6.

@GUI curl fonctionne, une autre idée ? Les certificats fonctionnent bien, mais mon journal contient cette erreur pour chaque chargement de page. Merci

[root@realm0-ssl1 logs]# curl -v "http://ocsp.int-x3.letsencrypt.org/"
*   Trying 2.22.8.114...
* Connected to ocsp.int-x3.letsencrypt.org (2.22.8.114) port 80 (#0)
> GET / HTTP/1.1
> Host: ocsp.int-x3.letsencrypt.org
> User-Agent: curl/7.47.1
> Accept: */*
> 
< HTTP/1.1 200 OK
< Server: nginx
< Content-Type: text/plain; charset=utf-8
< Content-Length: 0
< Cache-Control: max-age=33645
< Expires: Fri, 28 Oct 2016 23:29:12 GMT
< Date: Fri, 28 Oct 2016 14:08:27 GMT
< Connection: keep-alive
< 
* Connection #0 to host ocsp.int-x3.letsencrypt.org left intact

@fibigerg : Ah, intéressant. Il semble que curl résout le domaine en utilisant IPv4, mais la connexion à l'intérieur de nginx essaie d'utiliser IPv6 (et échoue). Quel paramètre resolver avez-vous configuré dans nginx ? Utilisez-vous le DNS de Google avec resolver 8.8.8.8 ? Et de même, quels serveurs DNS votre système utilise-t-il par défaut ? Sur un système Linux, vous devriez pouvoir les trouver par cat /etc/resolv.conf (recherchez les entrées nameserver ).

Je suppose que ce qui se passe, c'est que vous utilisez différents serveurs DNS entre nginx et ceux du système par défaut. Malheureusement, nginx ne récupère pas les serveurs DNS du système par défaut, c'est pourquoi notre README utilise les entrées DNS de Google comme exemple. Habituellement, cela va bien, mais je pense que ce qui pourrait se passer, c'est que le DNS de Google renvoie des adresses IPv6 à nginx, mais vous pourriez être sur un réseau qui n'est pas entièrement compatible IPv6. Ainsi, une fois que nginx reçoit les adresses IPv6 et tente de s'y connecter, la connexion échoue.

Si c'est ce qui se passe, alors je pense que cela devrait probablement être résolu si vous faites en sorte que le paramètre nginx resolver corresponde aux serveurs que votre système utilise par défaut (qui ne renverra probablement aucune adresse IPv6).

Comme vous l'avez noté, les certificats SSL fonctionneront toujours lorsque cet aspect échouera, c'est juste que les certificats ne seront pas renvoyés avec l'agrafage OCSP (et nginx continuera d'essayer de demander les demandes d'agrafage, plutôt que de mettre en cache le succès).

J'ai trouvé une solution pour résoudre uniquement l'adresse IPv4 en configurant Nginx avec le drapeau ipv6=off :

resolver 8.8.8.8 ipv6=off;

peut aider à résoudre ce problème. Je lance ceci sur AWS et l'adresse IP du résolveur qui doit être utilisée est différente :

resolver 172.16.0.23 ipv6=off;

(Cette IP peut être trouvée en exécutant cat /etc/resolv.conf et en recherchant la nameserver )

@GUI @berzniz Merci pour les solutions ! Nous avons activé IPv6 sur nos VPS Digital Ocean et l'erreur a disparu.

Merci pour toutes les recherches et le débogage, tout le monde !

Étant donné que ce problème semble provenir de l'environnement réseau de votre serveur (qu'il soit compatible avec IPv6) et des choix de serveur DNS (qu'ils renvoient ou non des résultats IPv6), il ne semble pas que nous puissions faire grand-chose du point de vue du codage pour gérer cela. Mais j'ai ajouté quelques commentaires à l'exemple du README pour, espérons-le, clarifier et expliquer ceci: https://github.com/GUI/lua-resty-auto-ssl/commit/856f52fb096c29f950dda83b3201faa5557a239b Je vais donc continuer et fermer ceci problème, mais signalez-le si quelqu'un rencontre encore des problèmes ou a d'autres suggestions.

Je vois "Réponse OCSP non réussie (6 : non autorisé)", je soupçonne que cela pourrait être lié à ce problème et je veux vérifier avant d'en créer un nouveau.

127.0.0.1 - - [03/Jan/2017:19:18:19 +0000] "POST /deploy-challenge HTTP/1.1" 200 5 "-" "curl/7.47.0"
10.255.0.3 - - [03/Jan/2017:19:18:20 +0000] "GET /.well-known/acme-challenge/i64vxEpJN-wUE-OvK7tKh0M3o842VcXSSEoyxtCd7Wk HTTP/1.1" 200 99 "-" "Mozilla/5.0 (compatible ; serveur de validation Let's Encrypt ; +https://www.letsencrypt.org)"
127.0.0.1 - - [03/Jan/2017:19:18:22 +0000] "POST /clean-challenge HTTP/1.1" 200 5 "-" "curl/7.47.0"
127.0.0.1 - - [03/Jan/2017:19:18:25 +0000] "POST /deploy-cert HTTP/1.1" 200 30 "-" "curl/7.47.0"
03/01/2017 19:18:26 [erreur] 16#16 : 3 [lua] ssl_certificate.

pourquoi je reçois la réponse non autorisée?

Merci

@faguirre1 : Cette erreur "non autorisée" ressemble à un problème légèrement différent de l'erreur précédente "réseau inaccessible" dans ce fil. Mais dans tous les cas, si vous faites une autre requête à votre domaine, obtenez-vous la même erreur OCSP dans vos logs nginx ? Dans quelques autres cas où Let's Encrypt OCSP retournait "non autorisé" ( #1 , #2 ), il semble qu'il s'agissait d'un problème de serveur temporaire du côté de Let's Encrypt.

Si vous voyez toujours la même erreur dans vos journaux, quel résultat obtenez-vous lorsque vous exécutez curl -v "http://ocsp.int-x3.letsencrypt.org/" partir du serveur ?

(Et juste pour clarifier, malgré cette erreur, votre certificat SSL devrait être complètement valide tel quel, c'est juste que l'agrafage OCSP ne fonctionne pas, ce qui est une optimisation pour que les clients puissent ignorer eux-mêmes les recherches OCSP.)

Salut,

merci pour la réponse, j'ai eu la même erreur dans toutes les demandes. mais après vérification aujourd'hui, le problème a disparu. il semble que vous ayez raison de dire que c'était un problème sur la fin du chiffrement.

Merci encore

L'ajout ipv6=off a également résolu ce problème pour moi. J'ai d'abord essayé d'utiliser les serveurs DNS comme indiqué dans resolv.conf mais cela n'a eu aucun effet.

BTW @GUI , j'aime la facilité avec laquelle lua-resty-auto-ssl rend le processus SSL ! Bien joué! Avez-vous une installation pour accepter les dons?

Je viens de rencontrer le même problème. On dirait que ipv6=off l'a également résolu.

Je ne sais pas à quel point cela peut être étroitement lié, donc je posterai ici avant de créer un nouveau problème.

J'ai mis à niveau vers la version la plus récente hier, avant l'expiration de nos certificats, car il n'avait pas pu être réédité (même problème que # 192), et aujourd'hui, il n'a toujours pas réussi à émettre de nouveaux certificats.

En regardant dans les logs je trouve :

2019/11/24 12:50:45 [crit] 17#17: *3 connect() to [2600:1415:2000::17ce:f212]:80 failed (99: Address not available), context: ssl_certificate_by_lua*, client: 1.158.52.47, server: 0.0.0.0:443
2019/11/24 12:50:45 [error] 17#17: *3 [lua] ssl_certificate.lua:260: set_response_cert(): auto-ssl: failed to set ocsp stapling for <domain> - continuing anyway - failed to get ocsp response: OCSP responder query failed (http://ocsp.int-x3.letsencrypt.org): address not available, context: ssl_certificate_by_lua*, client: 1.158.52.47, server: 0.0.0.0:443

Ceci est intéressant car il semble tenter d'atteindre une adresse IPv6, malgré l'instruction de résolution comprenant ipv6=off , et comme cela s'exécute dans un docker conatiner sans réseau ipv6, il échoue (résultant en 99: Address not available ).

J'ai essayé toutes les choses auxquelles je pouvais penser immédiatement, mais j'ai probablement raté des options évidentes car il est maintenant tôt le matin ici en Australie.

Est-ce que n'importe qui a des suggestions quant à ce qui peut l'amener à résoudre une adresse IPv6 dans ce cas ? et quelle configuration dois-je modifier, soit dans la configuration nginx, soit dans l'image docker et sa pile associée pour éviter ce problème ?

Merci pour toute aide que vous pouvez fournir.

OK, nouveau matin, le cerveau fonctionne réellement, j'ai fait la première chose que j'aurais dû essayer et supprimé les certificats incriminés dans le répertoire de stockage. Il n'y a eu aucun problème pour délivrer de nouveaux certificats. donc à la hausse, tout est fixé pour l'instant.

Je suis toujours curieux de savoir ce qui aurait causé ce problème? à la fois pour ma propre compréhension et au cas où cela se reproduirait plus tard, donc les commentaires seraient toujours appréciés.