tl; dr
Для сертификатов buypass DV, полученных с помощью certbot, мне нужно явно указать NGINX доверять корневому сертификату buypass, чтобы включить сшивание OCSP. Это не относится к сертификатам Let's Encrypt, и я не могу понять, почему. Я нашел способ (см. Ниже), который больше похож на обходной путь, чем на твердое решение. Мне интересно, не делаю ли я здесь что-нибудь не так?
Подробности
Я заметил, что для сертификатов DV buypass.com ( GO 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}"
Я получаю Ответ подтвердите ОК
. Тем не менее, хотя 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"
Мне потребовалось довольно много времени, чтобы понять это ! Проблема не в NGINX, а в OpenSSL. Я обнаружил, что если OCSP подписан назначенным респондентом (см. RFC 6960 ), чей сертификат включен в ответ OCSP, OpenSSL не учитывает этот дополнительный сертификат при проверке ответа. Я не могу точно сказать, почему эта проблема не возникает при использовании OpenSSL OCSP CLI (т.е. openssl ocsp -issuer x -cert y -url z
).