☰

Por que o grampeamento OCSP no NGINX para certificados DV "buypass" falha sem declaração raiz explícita?

tag-icon • tag-icon nginx lets-encrypt certbot x509
Por que o grampeamento OCSP no NGINX para certificados DV "buypass" falha sem declaração raiz explícita?

dr.

Para certificados buypass DV obtidos pelo certbot, preciso dizer explicitamente ao NGINX para confiar no certificado raiz buypass para ativar o grampeamento OCSP. Este não é o caso dos certificados Let's Encrypt e não consigo entender o porquê. Eu encontrei uma maneira (veja abaixo) que parece mais uma solução alternativa do que uma solução sólida. Então, estou me perguntando se estou fazendo algo errado aqui?

Detalhes

Percebi que para certificados DV buypass.com (Vá SSL) obtido através do protocolo ACME (porcertificadobot) O NGINX não fornece OCSP pronto para uso, mesmo que essa configuração funcione perfeitamente com os 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

Preciso gerar uma nova cadeia que inclua o certificado raiz ( 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

e direcione explicitamente o NGINX para confiar nesta cadeia:

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

o que é mais do que confuso para mim é que não preciso fazer isso para certificados Let's Encrypt e o NGINX consegue fornecer OCSP grampeadosemtendo que gerar um arquivo ocsp-chain.pem.

Mais detalhes (atualização)

Apenas alguns esclarecimentos sobre cadeias de confiança geradas por certbot:

Para Buypass:

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

Para vamos criptografar:

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

Se eu executar o seguinte:

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}"

Eu recebo Response verify OK. No entanto, emboranginx usaopensslsob o capô que confia em todas as âncoras /etc/ssl/certs(no meu caso /usr/lib/ssl/certs -> /etc/ssl/certs), ele não consegue verificar o OCSP sem a solução alternativa mencionada acima:

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"

Responder1

Atualizar

Acontece que o OpenSSL não lida corretamente com as respostas OCSP assinadas por uma autoridade designada (não pelo emissor). Embora RFC 6960denota explicitamente que uma resposta OCSP deve ser verificada usando apenas o certificado do emissor (que também certifica a autoridade designada), o OpenSSL não obedece a isso e exige que você inclua explicitamente o certificado raiz. Se você usar a CLI, isso acontecerá automaticamente (use uma combinação de -CAfilee -noCApathpara verificar isso!).

Resposta original

Levei bastante tempo paradescobrir isso! O problema não é o NGINX, mas o OpenSSL. Eu descobri que se o OCSP for assinado por um respondente designado (vejaRFC 6960), cujo certificado está incluído na resposta OCSP, o OpenSSL não considera esse certificado adicional ao verificar a resposta. Não posso dizer exatamente por que esse problema não surge ao usar o OpenSSL OCSP CLI (ou seja, openssl ocsp -issuer x -cert y -url z).

informação relacionada