☰

明示的なルート宣言がないと、NGINX での「buypass」DV 証明書の OCSP ステープルが失敗するのはなぜですか?

tag-icon • tag-icon nginx lets-encrypt certbot x509
明示的なルート宣言がないと、NGINX での「buypass」DV 証明書の OCSP ステープルが失敗するのはなぜですか?

要約

certbot によって取得された buypass DV 証明書の場合、OCSP ステープルを有効にするには、NGINX に buypass ルート証明書を信頼するように明示的に指示する必要があります。Let's Encrypt 証明書の場合はそうではなく、その理由がわかりません。確実な解決策というよりは回避策のような方法を見つけました (下記を参照)。ここで何か間違っているのではないかと思っています。

詳細

buypass.comのDV証明書（SSL へ）ACMEプロトコルを通じて取得（証明書ボット) NGINX は、Let's Encrypt 証明書でこのような構成が問題なく動作する場合でも、OCSP をそのまま提供できません。

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がstapled 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 (つまり、 )を使用するとこの問題が発生しない理由を正確に説明することはできません。

関連情報