
tl;dr
Für Buypass-DV-Zertifikate, die von Certbot abgerufen werden, muss ich NGINX ausdrücklich anweisen, dem Buypass-Stammzertifikat zu vertrauen, um OCSP-Stapling zu aktivieren. Dies ist bei Let’s Encrypt-Zertifikaten nicht der Fall, und ich kann nicht herausfinden, warum. Ich habe einen Weg gefunden (siehe unten), der eher wie ein Workaround als eine solide Lösung aussieht. Ich frage mich also, ob ich hier etwas falsch mache?
Einzelheiten
Mir ist aufgefallen, dass für buypass.com DV-Zertifikate (Gehen Sie auf SSL) abgerufen über das ACME-Protokoll (durchZertifikatbot) NGINX bietet standardmäßig kein OCSP, auch wenn eine solche Konfiguration mit Let’s Encrypt-Zertifikaten einwandfrei funktioniert:
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
Ich muss eine neue Kette generieren, die das Stammzertifikat ( Buypass_Class_2_Root_CA.pem
) enthält:
cp /etc/letsencrypt/live/example.com/
cat /etc/ssl/certs/Buypass_Class_2_Root_CA.pem fullchain.pem > ocsp-chain.pem
und weisen Sie NGINX ausdrücklich an, dieser Kette zu vertrauen:
ssl_trusted_certificate /etc/letsencrypt/live/example.com/ocsp-chain.pem;
was für mich mehr als verwirrend ist, ist, dass ich dies für Let's Encrypt-Zertifikate nicht tun muss und NGINX es schafft, geheftetes OCSP bereitzustellenohneohne dass ein zusätzliches generiert werden muss ocsp-chain.pem
.
Weitere Details (Update)
Nur einige Klarstellungen zu den generierten Vertrauensketten von certbot
:
Für Buypass:
/--------- fullchain.pem ---------\ /--- /etc/ssl/certs --\
example.com -> Buypass_Class_2_CA_5 -> Buypass_Class_2_Root_CA
\---- chain.pem ---/
Für Let’s Encrypt:
/--------- fullchain.pem --------\ / /etc/ssl/certs \
example.com -> Lets_Encrypt_R3.pem -> DST_Root_CA_X3.pem
\---- chain.pem ---/
Wenn ich Folgendes ausführe:
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}"
Ich verstehe Response verify OK
. Trotzdem, obwohlnginx
Verwendetopenssl
unter der Haube, die allen Ankern darunter vertraut /etc/ssl/certs
(in meinem Fall /usr/lib/ssl/certs -> /etc/ssl/certs
), kann OCSP ohne die oben genannte Problemumgehung nicht überprüft werden:
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"
Antwort1
Aktualisieren
Es stellt sich heraus, dass OpenSSL OCSP-Antworten, die von einer benannten Behörde (nicht dem Aussteller) signiert wurden, nicht korrekt verarbeitet. Obwohl RFC 6960gibt ausdrücklich an, dass eine OCSP-Antwort nur mit dem Ausstellerzertifikat (das auch die benannte Stelle zertifiziert) überprüft werden soll. OpenSSL hält sich nicht daran und verlangt, dass Sie das Stammzertifikat ausdrücklich einschließen. Wenn Sie die CLI verwenden, geschieht dies automatisch (verwenden Sie eine Kombination aus -CAfile
und , -noCApath
um dies zu überprüfen!).
Ursprüngliche Antwort
Es dauerte ziemlich lange, bis ichfinde es heraus! Das Problem ist nicht NGINX, sondern OpenSSL. Ich habe herausgefunden, dass, wenn das OCSP von einem designierten Responder signiert ist (sieheRFC 6960), dessen Zertifikat in der OCSP-Antwort enthalten ist, berücksichtigt OpenSSL dieses zusätzliche Zertifikat bei der Überprüfung der Antwort nicht. Ich kann nicht genau sagen, warum dieses Problem bei Verwendung der OpenSSL OCSP CLI (also openssl ocsp -issuer x -cert y -url z
) nicht auftritt.