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's Encrypt 的 OCSP 服务器发出出站请求时，这似乎失败了。 从您安装了 lua-resty-auto-ssl 的同一台服务器上，您是否能够手动建立与默认 Let's Encrypt OCSP 服务器的连接？ 您可以使用以下命令进行测试：

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

您应该会看到状态为“200 OK”的响应。 如果你没有看到，你可以发布输出吗？ 或者您的网络上是否有任何东西可以阻止此出站请求？

还值得注意的是，在这种情况下，尽管日志文件中有错误，您仍然应该拥有有效的 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

我们每个 aprox 都遇到 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设置？ 您是否将 Google 的 DNS 与resolver 8.8.8.8一起使用？ 同样，您的系统默认使用哪些 DNS 服务器？ 在 linux 系统上，您应该能够通过cat /etc/resolv.conf找到这些（查找nameserver条目）。

我怀疑发生的事情是您在 nginx 和默认系统服务器之间使用了不同的 DNS 服务器。 不幸的是，nginx 没有选择默认的系统 DNS 服务器，所以这就是我们的 README 使用 Google DNS 条目作为示例的原因。 通常这没关系，但我认为可能发生的情况是 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;

（可以通过运行cat /etc/resolv.conf并查找nameserver值来找到此 IP）

@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 /部署挑战 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 返回“未经授权”（ #1 、 #2 ）的其他几个案例中，看起来这是 Let's Encrypt 结束时的临时服务器问题。

如果您仍然在日志中看到相同的错误，那么当您从服务器运行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 地址，尽管解析器指令包括ipv6=off ，并且由于它在没有 ipv6 网络的 docker conatiner 中运行，它失败（导致99: Address not available )。

我已经尝试了所有我能立即想到的东西，但我可能错过了一些明显的选择，因为现在在澳大利亚这里是清晨。

在这种情况下，是否有人对可能导致它解析 IPv6 地址的原因有任何建议？ 以及我可能需要更改哪些配置，无论是在 nginx 配置中，还是在 docker 映像及其相关堆栈中，以防止出现此问题？

感谢您提供的任何帮助。

好的，新的早晨，大脑实际工作，做了我应该尝试的第一件事，并删除了存储目录中的违规证书。 颁发新证书没有问题。 所以从好的方面来说，现在一切都已解决。

我仍然很好奇导致这个问题的原因是什么？ 无论是为了我自己的理解，还是为了以后再次出现这种情况，因此仍将不胜感激。