☰

¿Por qué falla el grapado OCSP en NGINX para certificados DV "buypass" sin una declaración raíz explícita?

tag-icon • tag-icon nginx lets-encrypt certbot x509
¿Por qué falla el grapado OCSP en NGINX para certificados DV "buypass" sin una declaración raíz explícita?

tl; dr

Para los certificados Buypass DV obtenidos por certbot, necesito decirle explícitamente a NGINX que confíe en el certificado raíz de Buypass para habilitar el grapado OCSP. Este no es el caso de los certificados Let's Encrypt y no puedo entender por qué. He encontrado una manera (ver más abajo) que parece más una solución alternativa que una solución sólida. Entonces me pregunto si estoy haciendo algo mal aquí.

Detalles

He notado que para los certificados DV de buypass.com (IR SSL) obtenido a través del protocolo ACME (porrobot certificado) NGINX no proporciona OCSP listo para usar, incluso si dicha configuración funciona perfectamente con los certificados Let's Encrypt:

ssl_stapling on;
ssl_stapling_verify on;
ssl_certificate /etc/letsencrypt/live/example.com/fullchain.pem; # managed by Certbot
ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem; # managed by Certbot

Necesito generar una nueva cadena que incluya el certificado raíz ( Buypass_Class_2_Root_CA.pem):

cp /etc/letsencrypt/live/example.com/
cat /etc/ssl/certs/Buypass_Class_2_Root_CA.pem fullchain.pem > ocsp-chain.pem

y ordenar explícitamente a NGINX que confíe en esta cadena:

ssl_trusted_certificate /etc/letsencrypt/live/example.com/ocsp-chain.pem;

Lo que es más que confuso para mí es que no tengo que hacer esto para los certificados Let's Encrypt y NGINX logra proporcionar OCSP grapado.sintener que generar un extra ocsp-chain.pem.

Más detalles (actualización)

Sólo algunas aclaraciones sobre las cadenas de confianza generadas por certbot:

Para Buypass:

/--------- fullchain.pem ---------\    /--- /etc/ssl/certs --\
example.com -> Buypass_Class_2_CA_5 -> Buypass_Class_2_Root_CA
               \---- chain.pem ---/

Para Cifrar:

/--------- fullchain.pem --------\    / /etc/ssl/certs \
example.com -> Lets_Encrypt_R3.pem -> DST_Root_CA_X3.pem
               \---- chain.pem ---/

Si ejecuto lo siguiente:

cd /etc/letsencrypt/live/example.com
# $OSCP_URL is:
#   * Let's Encrypt: http://r3.o.lencr.org
#   * Buypass:       http://ocsp.buypass.com
openssl ocsp -issuer chain.pem -cert fullchain.pem -url "${OCSP_URL}"

Yo obtengo Response verify OK. De todos modos, aunquenginx usosopenssldebajo del capó que confía en todos los anclajes debajo /etc/ssl/certs(en mi caso /usr/lib/ssl/certs -> /etc/ssl/certs), no puede verificar OCSP sin la solución alternativa antes mencionada:

2611#2611: OCSP_basic_verify() failed (SSL: error:27069065:OCSP routines:OCSP_basic_verify:certificate verify error:Verify error:unable to get issuer certificate) while requesting certificate status, responder: ocsp.buypass.com, peer: 23.55.161.57:80, certificate: "/etc/letsencrypt/live/example.com/fullchain.pem"

Respuesta1

Actualizar

Resulta que OpenSSL no maneja correctamente las respuestas OCSP firmadas por una autoridad designada (no el emisor). A pesar de RFC 6960indica explícitamente que una respuesta OCSP debe verificarse utilizando solo el certificado del emisor (que también certifica a la autoridad designada), OpenSSL no cumple con esto y requiere que usted incluya explícitamente el certificado raíz. Si usa la CLI, esto sucede automáticamente (¡use una combinación de -CAfiley -noCApathpara verificar esto!).

Respuesta original

Me llevó bastante tiemporesolver esto! El problema no es NGINX sino OpenSSL. He descubierto que si el OCSP está firmado por un respondedor designado (verRFC 6960), cuyo certificado se incluye en la respuesta OCSP, OpenSSL no tiene en cuenta este certificado adicional al verificar la respuesta. No puedo decir exactamente por qué este problema no surge cuando se utiliza la CLI OCSP de OpenSSL (es decir, openssl ocsp -issuer x -cert y -url z).

información relacionada