Lua-resty-auto-ssl: Grampeamento OCSP: a rede está inacessível

Você especificou o resolvedor?
resolver 8.8.8.8;

sim

isso parece um problema de infraestrutura, como se você não estivesse ouvindo na porta 80. você está usando o docker?

sim

você pode tentar minha própria imagem e ver se funciona: https://hub.docker.com/r/pushtospace/nginx/

Vou tentar se tiver tempo.
Minha:

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 : Parece que está falhando quando seu servidor está tentando fazer uma solicitação de saída para o servidor OCSP da Let's Encrypt. A partir deste mesmo servidor onde você instalou o lua-resty-auto-ssl, você pode estabelecer manualmente uma conexão com o servidor padrão Let's Encrypt OCSP? Você pode testar isso com este comando:

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

Você deverá ver uma resposta com um status "200 OK". Se você não ver isso, você pode postar a saída? Ou há algo em sua rede que você possa pensar que esteja impedindo essa solicitação de saída?

Também vale a pena notar que, neste caso, você ainda deve ter um certificado SSL válido, apesar do erro no arquivo de log. Isso significa simplesmente que o grampeamento do OCSP falhou, portanto, cabe ao cliente realizar qualquer validação do OCSP.

Talvez tenha algo a ver com IPv6? Eu entendi isso

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

Depois de atualizar a página, uma vez que ela apareça com uma página https funcionando.

Mesmo aqui, alguma idéia do que está errado?

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

Estamos enfrentando o congelamento do Nginx/Openresty (a página nginx_status não está carregando, os logs estão vazios) a cada aprox. 10 horas. Isso está conectado? Alguma idéia de como consertar isso? Obrigado

PS Eu não reconheço esses endereços IPv6.

@GUI curl está funcionando, alguma outra ideia? Certs estão funcionando bem, porém meu log tem esse erro para cada carregamento de página. Obrigado

[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, interessante. Parece que o curl está resolvendo o domínio usando IPv4, mas a conexão dentro do nginx está tentando usar IPv6 (e falhando). Qual configuração resolver você configurou no nginx? Você está usando o DNS do Google com resolver 8.8.8.8 ? E da mesma forma, quais servidores DNS seu sistema está usando por padrão? Em um sistema linux, você deve ser capaz de encontrá-los por cat /etc/resolv.conf (procure as entradas nameserver ).

Suspeito que o que está acontecendo é que você está usando diferentes servidores DNS entre o nginx e os do sistema padrão. Infelizmente, o nginx não pega os servidores DNS padrão do sistema, então é por isso que nosso README usa as entradas DNS do Google como exemplo. Normalmente, isso é bom, mas acho que o que pode estar acontecendo é que o DNS do Google está retornando endereços IPv6 para o nginx, mas você pode estar em uma rede que não é totalmente compatível com IPv6. Então, depois que o nginx recebe os endereços IPv6 e tenta se conectar a ele, a conexão falha.

Se é isso que está acontecendo, acho que isso provavelmente deve ser resolvido se você fizer a configuração nginx resolver corresponder a qualquer servidor que seu sistema use por padrão (o que presumivelmente não retornará nenhum endereço IPv6).

Como você observou, os certificados SSL ainda funcionarão quando esse aspecto falhar, é apenas que os certificados não serão retornados com o grampeamento OCSP (e o nginx continuará tentando solicitar as solicitações de grampeamento, em vez de armazenar em cache o sucesso).

Encontrei uma resolução para resolver apenas o endereço IPv4 configurando o Nginx com o sinalizador ipv6=off :

resolver 8.8.8.8 ipv6=off;

pode ajudar a resolver isso. Eu executo isso na AWS e o IP do resolvedor que deve ser usado é diferente:

resolver 172.16.0.23 ipv6=off;

(Este IP pode ser encontrado executando cat /etc/resolv.conf e procurando o nameserver )

@GUI @berzniz Obrigado pelas soluções! Habilitamos o IPv6 em nossos VPSs Digital Ocean e o erro desapareceu.

Obrigado por toda a investigação e depuração, todos!

Como esse problema parece resultar do ambiente de rede do seu servidor (se é compatível com IPv6) e das escolhas do servidor DNS (se eles retornam resultados IPv6), não parece que haja muito que possamos fazer de uma perspectiva de codificação para lidar com isso. Mas adicionei alguns comentários ao exemplo do README para esclarecer e explicar isso: https://github.com/GUI/lua-resty-auto-ssl/commit/856f52fb096c29f950dda83b3201faa5557a239b problema, mas dê um grito se alguém ainda tiver problemas ou tiver outras sugestões.

Estou vendo "Resposta OCSP não bem-sucedida (6: não autorizado)", suspeito que possa estar relacionado a esse problema e quero verificar novamente antes de criar um novo.

127.0.0.1 - - [03/Jan/2017:19:18:19 +0000] "POST/implantar-desafio 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 (compatível; servidor de validação 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 [erro] 16#16: 3 [lua] ssl_certificate.

por que recebo a resposta não autorizada?

obrigado

@faguirre1 : Este erro "não autorizado" parece um problema um pouco diferente do erro anterior "rede inacessível" neste tópico. Mas, de qualquer forma, se você fizer outra solicitação ao seu domínio, receberá o mesmo erro OCSP nos logs do nginx? Em alguns outros casos em que o Let's Encrypt OCSP estava retornando "não autorizado" ( #1 , #2 ), parece que esse foi um problema temporário do servidor no final do Let's Encrypt.

Se você ainda estiver vendo o mesmo erro em seus logs, qual saída você obtém quando executa curl -v "http://ocsp.int-x3.letsencrypt.org/" no servidor?

(E apenas para esclarecer, apesar desse erro, seu certificado SSL deve ser completamente válido como está, é apenas que o grampeamento OCSP não está funcionando, o que é uma otimização para que os clientes possam pular as pesquisas OCSP.)

Oi,

obrigado pela resposta, recebi o mesmo erro em todas as solicitações. mas depois de verificar hoje o problema desapareceu. parece que você estava certo sobre isso foi um problema em vamos criptografar o fim.

obrigado novamente

Adicionar ipv6=off resolveu esse problema para mim também. Primeiro tentei usar os servidores DNS listados em resolv.conf mas isso não teve efeito.

BTW @GUI , estou adorando o quão fácil lua-resty-auto-ssl é fazer o processo SSL! Bem feito! Você tem uma facilidade para aceitar doações?

Acabei de passar pelo mesmo problema. Parece que ipv6=off resolveu também.

Não tenho certeza de quão intimamente relacionado isso pode ser, então postarei aqui antes de criar um novo problema.

Atualizei para a versão mais recente ontem, antes da expiração de nossos certificados, pois ela não conseguiu reemitir (mesmo problema do #192) e hoje ainda não conseguiu emitir novos certificados.

Olhando para os logs eu encontro:

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

Isso é interessante, pois parece estar tentando alcançar um endereço IPv6, apesar da instrução do resolvedor incluindo ipv6=off , e como isso está sendo executado em um docker conatiner sem rede ipv6, ele falha (resultando no 99: Address not available ).

Eu tentei todas as coisas que eu poderia pensar imediatamente, mas eu provavelmente perdi algumas opções óbvias, já que agora é de manhã cedo aqui na Austrália.

Alguém tem alguma sugestão sobre o que pode estar fazendo com que ele resolva um endereço IPv6 neste caso? e qual configuração posso precisar alterar, seja na configuração do nginx ou na imagem do docker e sua pilha associada para evitar esse problema?

Obrigado por qualquer ajuda que você possa fornecer.

OK, novo dia, cérebro realmente funcionando, fiz a primeira coisa que eu deveria ter tentado e removido os certificados incorretos no diretório de armazenamento. Não houve problema na emissão de novos certificados. então, no lado positivo, tudo está corrigido por enquanto.

Ainda estou curioso para saber o que estaria causando esse problema? tanto para meu próprio entendimento quanto no caso de isso surgir novamente mais tarde, então a contribuição ainda seria apreciada.