Lua-resty-auto-ssl: OCSP-Heften: Netzwerk ist nicht erreichbar

Hast du den Resolver angegeben?
resolver 8.8.8.8;

Jawohl

Das sieht nach einem Infrastrukturproblem aus, als ob Sie Port 80 nicht abhören. Verwenden Sie Docker?

Jawohl

Sie könnten mein eigenes Image ausprobieren und sehen, ob es funktioniert: https://hub.docker.com/r/pushtospace/nginx/

Ich werde es versuchen, wenn ich Zeit habe.
Bergwerk:

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 : Dies sieht so aus, als ob es fehlschlägt, wenn Ihr Server versucht, eine ausgehende Anfrage an den OCSP-Server von Let's Encrypt zu senden. Können Sie von demselben Server, auf dem Sie lua-resty-auto-ssl installiert haben, manuell eine Verbindung zum Standard-OCSP-Server von Let's Encrypt herstellen? Das kannst du mit diesem Befehl testen:

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

Sie sollten eine Antwort mit dem Status „200 OK“ sehen. Wenn du das nicht siehst, kannst du die Ausgabe posten? Oder fällt Ihnen irgendetwas in Ihrem Netzwerk ein, das diese ausgehende Anfrage verhindern könnte?

Beachten Sie auch, dass Sie in diesem Fall trotz des Fehlers in der Protokolldatei immer noch über ein gültiges SSL-Zertifikat verfügen sollten. Dies bedeutet einfach, dass das OCSP-Heften fehlgeschlagen ist, sodass es Sache des Clients ist, eine OCSP-Validierung durchzuführen.

Vielleicht hat es etwas mit IPv6 zu tun? Ich verstehe das

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

Nachdem ich die Seite aktualisiert habe, erscheint eine funktionierende https-Seite.

Auch hier, hast du eine Ahnung, was falsch ist?

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

Wir erleben das Einfrieren von Nginx/Openresty (nginx_status-Seite wird nicht geladen, Protokolle sind leer) alle ca. 10 Stunden. Ist das verbunden? Irgendeine Idee, wie man es repariert? Danke

PS Ich erkenne diese IPv6-Adressen nicht.

@GUI Curl funktioniert, hast du eine andere Idee? Zertifikate funktionieren einwandfrei, aber mein Protokoll enthält diesen Fehler bei jedem Laden der Seite. Danke

[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, interessant. Es sieht so aus, als würde curl die Domäne mit IPv4 auflösen, aber die Verbindung in nginx versucht, IPv6 zu verwenden (und schlägt fehl). Welche resolver Einstellung hast du in nginx konfiguriert? Verwenden Sie das DNS von Google mit resolver 8.8.8.8 ? Und ähnlich, welche DNS-Server verwendet Ihr System standardmäßig? Auf einem Linux-System sollten Sie diese anhand von cat /etc/resolv.conf finden können (suchen Sie nach den nameserver -Einträgen).

Ich vermute, dass Sie verschiedene DNS-Server zwischen nginx und den Standardsystemservern verwenden. Leider nimmt nginx die Standard-DNS-Server des Systems nicht auf, deshalb verwendet unsere README die Google-DNS-Einträge als Beispiel. Normalerweise ist das in Ordnung, aber ich denke, was passieren könnte, ist, dass Googles DNS IPv6-Adressen an nginx zurückgibt, aber Sie befinden sich möglicherweise in einem Netzwerk, das nicht vollständig IPv6-kompatibel ist. Nachdem nginx also die IPv6-Adressen erhalten und versucht hat, sich damit zu verbinden, schlägt die Verbindung fehl.

Wenn dies der Fall ist, sollte dies wahrscheinlich lösbar sein, wenn Sie die Einstellung von nginx resolver mit den Servern übereinstimmen, die Ihr System standardmäßig verwendet (die vermutlich keine IPv6-Adressen zurückgeben).

Wie Sie angemerkt haben, funktionieren die SSL-Zertifikate immer noch, wenn dieser Aspekt fehlschlägt, es ist nur so, dass die Zertifikate nicht mit OCSP -Stapling zurückgegeben werden (und nginx versucht weiterhin, die Stapling-Anforderungen anzufordern, anstatt den Erfolg zwischenzuspeichern).

Ich habe eine Lösung gefunden, um nur die IPv4-Adresse aufzulösen, indem ich Nginx mit dem Flag ipv6=off konfiguriert habe:

resolver 8.8.8.8 ipv6=off;

kann helfen, dies zu lösen. Ich führe dies auf AWS aus und die Resolver-IP, die verwendet werden sollte, ist anders:

resolver 172.16.0.23 ipv6=off;

(Diese IP kann gefunden werden, indem Sie cat /etc/resolv.conf und nach dem nameserver suchen)

@GUI @berzniz Vielen Dank für die Lösungen! Wir haben IPv6 auf unseren Digital Ocean VPSs aktiviert und der Fehler ist verschwunden.

Vielen Dank für all die Detektivarbeit und das Debuggen, alle!

Da dieses Problem anscheinend von der Netzwerkumgebung Ihres Servers (ob IPv6-kompatibel) und der Wahl des DNS-Servers (ob sie IPv6-Ergebnisse zurückgeben) herrührt, scheint es nicht so, als könnten wir aus Codierungsperspektive viel tun, um damit umzugehen. Aber ich habe dem README-Beispiel einige Kommentare hinzugefügt, um dies hoffentlich zu verdeutlichen und zu erklären: https://github.com/GUI/lua-resty-auto-ssl/commit/856f52fb096c29f950dda83b3201faa5557a239b Also werde ich fortfahren und dies schließen Problem, aber rufen Sie an, wenn jemand immer noch auf Probleme stößt oder andere Vorschläge hat.

Ich sehe „OCSP-Antwort nicht erfolgreich (6: nicht autorisiert)“, ich vermute, dass es mit diesem Problem zusammenhängt, und ich möchte es noch einmal überprüfen, bevor ich eine neue erstelle.

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 (kompatibel; Let's Encrypt Validierungsserver; +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 [Fehler] 16#16: 3 [lua] ssl_certificate.

Warum erhalte ich die nicht autorisierte Antwort?

Danke

@faguirre1 : Dieser "nicht autorisierte" Fehler sieht aus wie ein etwas anderes Problem als der frühere Fehler "Netzwerk nicht erreichbar" in diesem Thread. Aber in jedem Fall, wenn Sie eine weitere Anfrage an Ihre Domain stellen, erhalten Sie denselben OCSP-Fehler in Ihren nginx-Protokollen? In einigen anderen Fällen, in denen Let’s Encrypt OCSP „nicht autorisiert“ zurückgab ( #1 , #2 ), sieht es so aus, als wäre dies ein vorübergehendes Serverproblem auf Seiten von Let’s Encrypt.

Wenn Sie immer noch denselben Fehler in Ihren Protokollen sehen, welche Ausgabe erhalten Sie, wenn Sie curl -v "http://ocsp.int-x3.letsencrypt.org/" vom Server ausführen?

(Und nur zur Verdeutlichung: Trotz dieses Fehlers sollte Ihr SSL-Zertifikat so wie es ist vollständig gültig sein, es ist nur so, dass OCSP-Stapling nicht funktioniert, was eine Optimierung ist, damit Clients OCSP-Suchen selbst überspringen können.)

Hallo,

danke für die Antwort, ich habe bei allen Anfragen den gleichen Fehler bekommen. aber nach heutiger Überprüfung ist das Problem weg. Scheint, als hätten Sie Recht damit, dass es sich um ein Problem bei Let's Encrypt End handelt.

Danke noch einmal

Das Hinzufügen ipv6=off löste dieses Problem auch für mich. Ich habe zuerst versucht, die in resolv.conf aufgelisteten DNS-Server zu verwenden, aber das hatte keine Wirkung.

Übrigens @GUI , ich finde es toll, wie einfach lua-resty-auto-ssl den SSL-Prozess macht! Gut gemacht! Haben Sie eine Möglichkeit, Spenden anzunehmen?

Bin gerade auf das gleiche Problem gestoßen. Scheint, als hätte ipv6=off es auch gelöst.

Ich bin mir nicht sicher, wie eng dies zusammenhängt, also poste ich hier, bevor ich ein neues Problem erstelle.

Ich habe gestern auf die neueste Version aktualisiert, bevor unsere Zertifikate ablaufen, da sie nicht neu ausgestellt werden konnte (gleiches Problem wie Nr. 192) und heute immer noch keine neuen Zertifikate ausstellen konnte.

Wenn ich in die Protokolle schaue, finde ich:

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

Dies ist interessant, da es anscheinend versucht, eine IPv6-Adresse zu erreichen, trotz der Resolver-Anweisung einschließlich ipv6=off , und da dies in einem Docker-Conatiner ohne IPv6-Netzwerk ausgeführt wird, schlägt dies fehl (was zu 99: Address not available ).

Ich habe alle Dinge ausprobiert, die mir sofort eingefallen sind, aber ich habe wahrscheinlich einige offensichtliche Optionen verpasst, da es jetzt früh am Morgen hier in Australien ist.

Hat jemand irgendwelche Vorschläge, was dazu führen kann, dass es in diesem Fall eine IPv6-Adresse auflöst? und welche Konfiguration muss ich möglicherweise ändern, entweder in der nginx-Konfiguration oder im Docker-Image und dem zugehörigen Stack, um dieses Problem zu vermeiden?

Vielen Dank für jede Hilfe, die Sie leisten können.

OK, neuer Morgen, Gehirn funktioniert tatsächlich, habe das erste getan, was ich hätte versuchen sollen, und die anstößigen Zertifikate im Speicherverzeichnis entfernt. Es gab keine Probleme beim Ausstellen neuer Zertifikate. Auf der Oberseite ist also vorerst alles behoben.

Ich bin immer noch neugierig, was dieses Problem verursacht haben könnte? sowohl für mein eigenes Verständnis als auch für den Fall, dass dies später wieder auftaucht, so dass Input immer noch geschätzt wird.