Lua-resty-auto-ssl: Grapado OCSP: no se puede acceder a la red

¿Especificaste el resolutor?
resolver 8.8.8.8;

sí

esto parece un problema de infraestructura, como si no estuvieras escuchando en el puerto 80. ¿Estás usando Docker?

sí

podría probar mi propia imagen y ver si funciona: https://hub.docker.com/r/pushtospace/nginx/

Lo intentaré si tengo tiempo.
Mío:

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á fallando cuando su servidor intenta realizar una solicitud saliente al servidor OCSP de Let's Encrypt. Desde este mismo servidor donde tiene instalado lua-resty-auto-ssl, ¿puede establecer manualmente una conexión con el servidor OCSP predeterminado de Let's Encrypt? Puedes probar eso con este comando:

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

Debería ver una respuesta con un estado "200 OK". Si no ves eso, ¿puedes publicar el resultado? ¿O hay algo en su red que se le ocurra que estaría impidiendo esta solicitud saliente?

También vale la pena señalar que, en este caso, aún debe tener un certificado SSL válido, a pesar del error en el archivo de registro. Esto simplemente significa que el grapado de OCSP ha fallado, por lo que depende del cliente realizar cualquier validación de OCSP.

¿Tal vez tiene algo que ver con IPv6? entiendo esto

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

Después de actualizar la página, aparece una página https que funciona.

Lo mismo aquí, ¿alguna idea de lo que está mal?

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 experimentando congelamiento de Nginx/Openresty (la página nginx_status no se carga, los registros están vacíos) cada aprox. 10 horas. ¿Esto está conectado? ¿Alguna de idea de cómo arreglarlo? Gracias

PD: no reconozco esas direcciones IPv6.

@GUI curl está funcionando, ¿alguna otra idea? Los certificados funcionan bien, sin embargo, mi registro tiene este error cada vez que se carga una página. Gracias

[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, interesante. Parece que curl está resolviendo el dominio usando IPv4, pero la conexión dentro de nginx está intentando usar IPv6 (y falla). ¿Qué configuración de resolver ha configurado en nginx? ¿Está utilizando el DNS de Google con resolver 8.8.8.8 ? Y de manera similar, ¿qué servidores DNS usa su sistema de manera predeterminada? En un sistema Linux, debería poder encontrarlos por cat /etc/resolv.conf (busque las entradas nameserver ).

Sospecho que lo que sucede es que está utilizando diferentes servidores DNS entre nginx y los del sistema predeterminado. Desafortunadamente, nginx no selecciona los servidores DNS del sistema predeterminados, por eso nuestro README usa las entradas de DNS de Google como ejemplo. Por lo general, esto está bien, pero creo que lo que podría estar sucediendo es que el DNS de Google está devolviendo direcciones IPv6 a nginx, pero es posible que esté en una red que no es totalmente compatible con IPv6. Entonces, después de que nginx recibe las direcciones IPv6 e intenta conectarse, la conexión falla.

Si eso es lo que está sucediendo, entonces creo que esto probablemente debería resolverse si hace que la configuración de nginx resolver coincida con los servidores que usa su sistema de forma predeterminada (lo que presumiblemente no devolverá ninguna dirección IPv6).

Como notó, los certificados SSL seguirán funcionando cuando este aspecto falle, solo que los certificados no se devolverán con el engrapado OCSP (y nginx seguirá intentando solicitar las solicitudes de engrapado, en lugar de almacenar en caché el éxito).

Encontré una resolución para resolver solo la dirección IPv4 configurando Nginx con el indicador ipv6=off :

resolver 8.8.8.8 ipv6=off;

puede ayudar a resolver esto. Ejecuto esto en AWS y la IP de resolución que se debe usar es diferente:

resolver 172.16.0.23 ipv6=off;

(Esta IP se puede encontrar ejecutando cat /etc/resolv.conf y buscando el nameserver )

@GUI @berzniz ¡ Gracias por las soluciones! Hemos habilitado IPv6 en nuestros VPS de Digital Ocean y el error desapareció.

¡Gracias por toda la investigación y la depuración, a todos!

Dado que este problema parece provenir del entorno de red de su servidor (si es compatible con IPv6) y las opciones del servidor DNS (si devuelven resultados de IPv6), no parece que haya mucho que podamos hacer desde una perspectiva de codificación para manejar esto. Pero agregué algunos comentarios al ejemplo de README para aclarar y explicar esto: https://github.com/GUI/lua-resty-auto-ssl/commit/856f52fb096c29f950dda83b3201faa5557a239b Así que seguiré adelante y cerraré esto problema, pero avisa si alguien todavía tiene problemas o tiene otras sugerencias.

Veo "Respuesta OCSP no exitosa (6: no autorizado)", sospecho que podría estar relacionado con este problema y quiero verificar dos veces antes de crear uno nuevo.

127.0.0.1 - - [03/ene/2017:19:18:19 +0000] "POST /deploy-challenge HTTP/1.1" 200 5 "-" "curl/7.47.0"
10.255.0.3 - - [03/ene/2017:19:18:20 +0000] "GET /.well-known/acme-challenge/i64vxEpJN-wUE-OvK7tKh0M3o842VcXSSEoyxtCd7Wk HTTP/1.1" 200 99 "-" "Mozilla/5.0 (compatible; servidor de validación Let's Encrypt; +https://www.letsencrypt.org)"
127.0.0.1 - - [03/ene/2017:19:18:22 +0000] "POST /clean-challenge HTTP/1.1" 200 5 "-" "curl/7.47.0"
127.0.0.1 - - [03/ene/2017:19:18:25 +0000] "POST /deploy-cert HTTP/1.1" 200 30 "-" "curl/7.47.0"
2017/01/03 19:18:26 [error] 16#16: 3 [lua] ssl_certificate.

¿Por qué recibo la respuesta no autorizada?

Gracias

@faguirre1 : este error "no autorizado" parece un problema ligeramente diferente al error anterior de "red inalcanzable" en este hilo. Pero en cualquier caso, si realiza otra solicitud a su dominio, ¿obtiene el mismo error OCSP en sus registros de nginx? En un par de otros casos en los que Let's Encrypt OCSP regresaba "no autorizado" ( n.º 1 , n.º 2 ), parece que se trataba de un problema temporal del servidor al final de Let's Encrypt.

Si sigue viendo el mismo error en sus registros, ¿qué resultado obtiene cuando ejecuta curl -v "http://ocsp.int-x3.letsencrypt.org/" desde el servidor?

(Y solo para aclarar, a pesar de este error, su certificado SSL debería ser completamente válido tal como está, es solo que el engrapado de OCSP no funciona, lo cual es una optimización para que los clientes puedan omitir las búsquedas de OCSP).

Hola,

gracias por la respuesta, tengo el mismo error en todas las solicitudes. pero después de verificar hoy, el problema desapareció. parece que tenías razón sobre que era un problema en let's encrypt end.

Gracias de nuevo

Agregar ipv6=off también resolvió este problema para mí. Primero intenté usar los servidores DNS que se enumeran en resolv.conf pero eso no tuvo ningún efecto.

Por cierto, @GUI , me encanta lo fácil que lua-resty-auto-ssl está haciendo el proceso SSL. ¡Bien hecho! ¿Tiene un lugar para aceptar donaciones?

Acabo de encontrarme con el mismo problema. Parece que ipv6=off también lo resolvió.

No estoy seguro de cuán estrechamente relacionado puede estar esto, así que lo publicaré aquí antes de crear un nuevo problema.

Ayer actualicé a la versión más nueva, antes de que caduquen nuestros certificados, ya que no se pudo volver a emitir (el mismo problema que el n.° 192) y, a día de hoy, aún no ha logrado emitir nuevos certificados.

Mirando en los registros encuentro:

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

Esto es interesante ya que parece estar intentando llegar a una dirección IPv6, a pesar de que la instrucción de resolución incluye ipv6=off , y como se ejecuta dentro de un contenedor docker sin red ipv6, falla (lo que resulta en 99: Address not available ).

Probé todas las cosas que se me ocurrieron de inmediato, pero probablemente me perdí algunas opciones obvias, ya que ahora es temprano en la mañana aquí en Australia.

¿Alguien tiene alguna sugerencia sobre qué puede estar causando que resuelva una dirección IPv6 en este caso? y ¿qué configuración debo cambiar, ya sea en la configuración de nginx o en la imagen de la ventana acoplable y su pila asociada para evitar este problema?

Gracias por cualquier asistencia que puedas ofrecer.

OK, nueva mañana, el cerebro realmente funciona, hice lo primero que debería haber intentado y eliminé los certificados ofensivos en el directorio de almacenamiento. No hubo problemas para emitir nuevos certificados. así que por el lado positivo, todo está arreglado por ahora.

Todavía tengo curiosidad por saber qué habría causado este problema. tanto para mi propio entendimiento como en el caso de que esto vuelva a asomar la cabeza más tarde, por lo que aún se agradecería la entrada.