Почему сшивание OCSP на NGINX для сертификатов «buypass» DV не удается без явного объявления корневого каталога?

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"
1
задан 28 December 2020 в 21:26
1 ответ

Мне потребовалось довольно много времени, чтобы понять это ! Проблема не в NGINX, а в OpenSSL. Я обнаружил, что если OCSP подписан назначенным респондентом (см. RFC 6960 ), чей сертификат включен в ответ OCSP, OpenSSL не учитывает этот дополнительный сертификат при проверке ответа. Я не могу точно сказать, почему эта проблема не возникает при использовании OpenSSL OCSP CLI (т.е. openssl ocsp -issuer x -cert y -url z ).

0
ответ дан 3 January 2021 в 23:09

Теги

Похожие вопросы