☰

为什么在没有明确根声明的情况下，NGINX 上“buypass”DV 证书的 OCSP 绑定会失败？

tag-icon • tag-icon nginx lets-encrypt certbot x509
为什么在没有明确根声明的情况下，NGINX 上“buypass”DV 证书的 OCSP 绑定会失败？

总结

对于 certbot 获取的 buypass DV 证书，我需要明确告诉 NGINX 信任 buypass 根证书以启用 OCSP 装订。但 Let's Encrypt 证书并非如此，我不明白为什么。我找到了一种方法（见下文），它看起来更像是一种变通方法，而不是可靠的解决方案。所以我想知道我在这里做错了什么吗？

细节

我注意到 buypass.com DV 证书（转到 SSL）通过 ACME 协议获取（通过certbot）NGINX 无法提供开箱即用的 OCSP，即使这种配置与 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

我需要生成一个包含根证书的新链（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

并明确指示 NGINX 信任此链：

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

让我更困惑的是，我不需要为 Let's Encrypt 证书执行此操作，而且 NGINX 设法提供了绑定的 OCSP没有必须生成额外的ocsp-chain.pem。

更多详细信息（更新）

关于生成的信任链的一些澄清certbot：

对于 Buypass：

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

对于 Let's Encrypt：

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

如果我运行以下命令：

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

我明白了Response verify OK。尽管如此，尽管nginx 用途openssl在信任所有锚点的引擎盖下/etc/ssl/certs（在我的情况下/usr/lib/ssl/certs -> /etc/ssl/certs），如果没有上述解决方法，它将无法验证 OCSP：

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"

答案1

更新

事实证明，OpenSSL 无法正确处理由指定机构（而非发行者）签名的 OCSP 响应。尽管 RFC 6960明确表示应仅使用颁发者证书（也认证指定机构）来验证 OCSP 响应，但 OpenSSL 不遵守此规定，并要求您明确包含根证书。如果您使用 CLI，则会自动执行此操作（使用和的组合-CAfile来-noCApath验证这一点！）。

原始答案

我花了很长时间才想出解决办法！问题不是 NGINX，而是 OpenSSL。我发现，如果 OCSP 由指定响应者签名（请参阅RFC 6960openssl ocsp -issuer x -cert y -url z)，其证书包含在 OCSP 响应中，OpenSSL 在验证响应时未能考虑此附加证书。我无法确切地说出为什么在使用 OpenSSL OCSP CLI（即）时不会出现此问题。

相关内容