
tl;dr
certbot이 가져온 buypass DV 인증서의 경우 OCSP 스테이플링을 활성화하려면 buypass 루트 인증서를 신뢰하도록 NGINX에 명시적으로 지시해야 합니다. 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가 스테이플된 OCSP를 제공한다는 것입니다.없이추가로 생성해야 합니다 ocsp-chain.pem
.
자세한 내용(업데이트)
생성된 신뢰 체인에 대한 몇 가지 설명은 다음과 같습니다 certbot
.
바이패스의 경우:
/--------- 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 6960OCSP 응답은 발급자 인증서(지정된 기관도 인증함)만 사용하여 확인해야 함을 명시적으로 나타내지만 OpenSSL은 이를 준수하지 않으며 루트 인증서를 명시적으로 포함해야 합니다. CLI를 사용하면 이 작업이 자동으로 수행됩니다( 이를 확인하려면 -CAfile
및 조합을 사용하십시오 -noCApath
!).
원래 답변
만드는데 꽤 오랜 시간이 걸렸어요이것을 알아내다! 문제는 NGINX가 아니라 OpenSSL입니다. 나는 OCSP가 지정된 응답자가 서명한 경우(참조RFC 6960)의 인증서가 OCSP 응답에 포함되어 있으면 OpenSSL은 응답을 확인할 때 이 추가 인증서를 고려하지 않습니다. OpenSSL OCSP CLI(예: openssl ocsp -issuer x -cert y -url z
)를 사용할 때 왜 이 문제가 발생하지 않는지 정확히 알 수 없습니다.