Lua-resty-auto-ssl: OCSP 스테이플링: 네트워크에 연결할 수 없습니다.

리졸버를 지정했습니까?
resolver 8.8.8.8;

네

포트 80에서 수신 대기하지 않는 것과 같은 인프라 문제처럼 보입니다. 도커를 사용하고 있습니까?

네

내 자신의 이미지를 시도하고 작동하는지 확인할 수 있습니다. 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

우리는 매 년마다 Nginx/Openresty 정지(nginx_status 페이지가 로드되지 않고 로그가 비어 있음)를 경험하고 있습니다. 10 시간. 이거 연결되나요? 문제를 해결하는 방법에 대한 아이디어가 있습니까? 감사 해요

추신: 그 IPv6 주소를 인식하지 못합니다.

@GUI 컬이 작동 중입니다. 다른 아이디어가 있습니까? 인증서는 잘 작동하지만 내 로그에는 모든 페이지 로드에 대해 이 오류가 있습니다. 감사 해요

[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에서 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;

(이 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" (호환, 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"
2017/01/03 19:18:26 [오류] 16#16: 3 [루아] SSL_인증서.

승인되지 않은 응답을 받는 이유는 무엇입니까?

감사 해요

@faguirre1 : 이 "승인되지 않은" 오류는 이 스레드의 이전 "네트워크에 연결할 수 없음" 오류와 약간 다른 문제처럼 보입니다. 그러나 어쨌든 도메인에 다른 요청을 하면 nginx 로그에 동일한 OCSP 오류가 표시됩니까? Let's Encrypt OCSP가 "unauthorized"( #1 , #2 )를 반환하는 몇 가지 다른 경우에서 이것은 Let's Encrypt 측의 일시적인 서버 문제인 것 같습니다.

로그에 여전히 동일한 오류가 표시되는 경우 서버에서 curl -v "http://ocsp.int-x3.letsencrypt.org/" 를 실행할 때 어떤 결과를 얻습니까?

(그리고 명확히 하자면, 이 오류에도 불구하고 SSL 인증서는 있는 그대로 완전히 유효해야 합니다. OCSP 스테이플링이 작동하지 않는다는 것뿐입니다. 이는 클라이언트가 OCSP 조회를 건너뛸 수 있도록 최적화된 것입니다.)

안녕,

답변 감사합니다. 모든 요청에서 동일한 오류가 발생했습니다. 하지만 오늘 확인 후 문제가 사라졌습니다. Let's Encrypt end의 문제였다는 말씀이 옳았던 것 같습니다.

다시 한 번 감사합니다

ipv6=off 를 추가하면 이 문제도 해결되었습니다. 먼저 resolv.conf 에 나열된 DNS 서버를 사용해 보았지만 효과가 없었습니다.

BTW @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 를 포함하는 resolver 명령에도 불구하고 IPv6 주소에 도달하려고 시도하는 것처럼 보이고 이것이 ipv6 네트워크가 없는 도커 컨테이너 내에서 실행되기 때문에 실패합니다(결과적으로 99: Address not available ).

나는 즉시 생각할 수 있는 모든 것을 시도했지만, 여기 호주에서 지금 이른 아침으로 인해 몇 가지 분명한 옵션을 놓쳤을 가능성이 큽니다.

이 경우 IPv6 주소를 해결하는 원인에 대한 제안이 있는 사람이 있습니까? 이 문제를 방지하기 위해 nginx 구성이나 도커 이미지 및 관련 스택에서 어떤 구성을 변경해야 합니까?

도움을 주시면 감사하겠습니다.

좋아, 새로운 아침, 실제로 작동하는 두뇌, 내가 시도했어야 할 첫 번째 작업을 수행하고 저장소 디렉터리에서 문제가 되는 인증서를 제거했습니다. 새 인증서를 발급하는 데 문제가 없었습니다. 그래서 거꾸로, 모든 것이 지금은 고정되어 있습니다.

이 문제의 원인이 무엇인지 여전히 궁금합니다. 내 자신의 이해를 위해 그리고 나중에 다시 고개를 드는 경우를 대비하여 의견을 보내주시면 감사하겠습니다.