Lua-resty-auto-ssl: OCSPステープリング：ネットワークに到達できません

リゾルバーを指定しましたか？
resolver 8.8.8.8;

はい

これは、ポート80でリッスンしていないなど、インフラストラクチャの問題のように見えます。dockerを使用していますか？

はい

私自身の画像を試して、それが機能するかどうかを確認できます： https ：//hub.docker.com/r/pushtospace/nginx/

時間があればやってみます。
私の：

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 ：これは、サーバーがLet'sEncryptのOCSPサーバーにアウトバウンド要求を行おうとしているときに失敗しているようです。 lua-resty-auto-sslがインストールされているこの同じサーバーから、デフォルトのLet's Encrypt OCSPサーバーへの接続を手動で確立できますか？ 次のコマンドでテストできます。

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

「200OK」ステータスの応答が表示されます。 それが表示されない場合は、出力を投稿できますか？ または、このアウトバウンド要求を妨げていると考えられるネットワーク上の何かがありますか？

この場合、ログファイルにエラーがあるにもかかわらず、有効なSSL証明書が残っている必要があることにも注意してください。 これは単にOCSPステープリングが失敗したことを意味するため、OCSP検証を実行するのはクライアントの責任です。

多分それはIPv6と関係がありますか？ 私はこれを手に入れます

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

動作するhttpsページが表示されたら、ページを更新します。

ここでも同じですが、何が問題なのですか？

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

ほぼすべてのNginx / Openrestyフリーズ（nginx_statusページがロードされていない、ログが空）が発生しています。 10時間。 これは接続されていますか？ それを修正する方法はありますか？ ありがとう

PS私はそれらのIPv6アドレスを認識していません。

@GUI curlが機能しています、他のアイデアはありますか？ 証明書は正常に機能していますが、ページが読み込まれるたびにログにこのエラーが発生します。 ありがとう

[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 ：ああ、面白い。 curlがIPv4を使用してドメインを解決しているように見えますが、nginx内の接続がIPv6を使用しようとしています（失敗しています）。 nginxでどのresolver設定を構成しましたか？ resolver 8.8.8.8でGoogleのDNSを使用していますか？ 同様に、システムがデフォルトで使用しているDNSサーバーは何ですか？ Linuxシステムでは、これらをcat /etc/resolv.confで見つけることができるはずです（ nameserverエントリを探してください）。

何が起こっているのかというと、nginxとデフォルトのシステムサーバーの間で異なるDNSサーバーを使用しているのではないかと思います。 残念ながら、nginxはデフォルトのシステムDNSサーバーを取得しないため、READMEでは例としてGoogleDNSエントリを使用しています。 通常、これは問題ありませんが、GoogleのDNSがIPv6アドレスをnginxに返している可能性がありますが、IPv6と完全に互換性のないネットワークを使用している可能性があります。 したがって、nginxがIPv6アドレスを受信して​​接続を試みた後、接続は失敗します。

それが起こっているのであれば、nginx resolver設定をシステムがデフォルトで使用するサーバーと一致させると、おそらくこれは解決できるはずです（おそらくIPv6アドレスは返されません）。

お気づきのとおり、SSL証明書は、この側面が失敗しても機能します。証明書がOCSPステープリングで返されないだけです（nginxは、成功をキャッシュするのではなく、ステープリング要求を要求し続けます）。

ipv6=offフラグを使用してNginxを構成することにより、IPv4アドレスのみを解決する解決策を見つけました。

resolver 8.8.8.8 ipv6=off;

これを解決するのに役立ちます。 これをAWSで実行しましたが、使用するリゾルバーIPが異なります。

resolver 172.16.0.23 ipv6=off;

（このIPは、 cat /etc/resolv.confを実行し、 nameserverの値を探すことで見つけることができます）

@GUI @berzniz解決策をありがとう！ Digital Ocean VPSでIPv6を有効にしましたが、エラーはなくなりました。

みなさん、すべての調査とデバッグに感謝します！

この問題は、サーバーのネットワーク環境（IPv6互換かどうか）とDNSサーバーの選択（IPv6の結果を返すかどうか）に起因するように思われるため、コーディングの観点からこれを処理するためにできることはあまりないようです。 しかし、これを明確にして説明するために、READMEの例にいくつかのコメントを追加しました： https ：//github.com/GUI/lua-resty-auto-ssl/commit/856f52fb096c29f950dda83b3201faa5557a239bでは、先に進んでこれを閉じます問題が発生しますが、まだ問題が発生している場合や他の提案がある場合は、大声で言ってください。

「OCSP応答が成功しません（6：許可されていません）」と表示されます。この問題に関連している可能性があるため、新しい問題を作成する前に再確認したいと思います。

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 （互換性;検証サーバーを暗号化しましょう; + 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"
2017/01/03 19:18:26 [エラー] 16＃16： 3 [lua] ssl_certificate。

なぜ私は不正な応答を受け取るのですか？

ありがとう

@ faguirre1 ：この「無許可」エラーは、このスレッドの以前の「ネットワーク到達不能」エラーとは少し異なる問題のように見えます。 しかし、いずれにせよ、ドメインに別のリクエストを行うと、nginxログで同じOCSPエラーが発生しますか？ Let's Encrypt OCSPが「unauthorized」（ ＃1 、 ＃2 ）を返していた他のいくつかのケースでは、これはLet'sEncrypt側の一時的なサーバーの問題であったようです。

それでもログに同じエラーが表示される場合は、サーバーからcurl -v "http://ocsp.int-x3.letsencrypt.org/"を実行すると、どのような出力が得られますか？

（明確にするために、このエラーにもかかわらず、SSL証明書はそのままで完全に有効である必要があります。これは、OCSPステープリングが機能していないことだけです。これは、クライアントがOCSPルックアップをスキップできるようにするための最適化です。）

やあ、

回答ありがとうございます。すべてのリクエストで同じエラーが発生しました。 しかし、今日チェックした後、問題はなくなりました。 あなたはそれが暗号化の終わりの問題であったことについて正しかったようです。

再度、感謝します

ipv6=offを追加すると、この問題も解決しました。 resolv.confにリストされているDNSサーバーを最初に使用しようとしましたが、効果がありませんでした。

ところで@GUI 、私はlua-resty-auto-sslがSSLプロセスをいかに簡単にするかが大好きです！ 素晴らしい！ 寄付を受け入れる施設はありますか？

同じ問題が発生しました。 ipv6 = offもそれを解決したようです。

これがどれほど密接に関連しているかわからないので、新しい問題を作成する前にここに投稿します。

昨日、証明書の有効期限が切れる前に最新バージョンにアップグレードしました。再発行できなかったため（＃192と同じ問題）、今日でも新しい証明書を発行できていません。

私が見つけたログを調べます：

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

これは、 ipv6=offを含むリゾルバー命令にもかかわらず、IPv6アドレスに到達しようとしているように見え、ipv6ネットワークのないdocker conatiner内で実行されているため、失敗します（結果として99: Address not availableになります）。

私はすぐに思いつくすべてのことを試しましたが、オーストラリアでは早朝になっているため、いくつかの明らかな選択肢を見逃している可能性があります。

この場合、IPv6アドレスを解決する原因について誰かが何か提案がありますか？ この問題を防ぐために、nginx構成、またはDockerイメージとそれに関連するスタックのいずれかで変更する必要がある構成は何ですか？

あなたが提供できるどんな援助にも感謝します。

OK、新しい朝、脳は実際に機能していて、最初に試したはずのことを実行し、ストレージディレクトリ内の問題のある証明書を削除しました。 新しい証明書の発行に問題はありませんでした。 逆に、今のところすべてが修正されています。

何がこの問題を引き起こしていたのか、私はまだ興味がありますか？ 私自身の理解と、これが後で再び頭をもたげた場合の両方のために、それでも入力をいただければ幸いです。