Puncte:0

openssl nu va verifica certificatele dincolo de CA intermediar, eroarea 20 chiar și atunci când se utilizează CApath sau CAfile

drapel in

În cele din urmă, încerc să configurez un server ocsp pe ubuntu 20.4, dar încă nu pot verifica niciun certificat emis de CA-ul meu intermediar.

Am configurat un ca-root numit ca-root.mydomain.org. De asemenea, am configurat un ca intermediar numit ca-sub.mydomain.org. În cele din urmă, există viitorul meu server ocsp, ocsp-server.mydomain.org.

În primul rând, fac un certificat auto-semnat ca_root_cert_file.Apoi am ca-root să semneze un certificat pentru ca-sub.mydomain.org, ca_sub_cert_file. Apoi creez un fișier pem de lanț cert „sub-chain.pem”. Conține certificatul sub-ca, apoi certificatul ca-rădăcină, în această ordine.

Apoi, copiez atât ca_root_cert_file, cât și ca_sub_cert_file într-un director „$CA_ROOTS_HASHES_DIR” și copiez toate certificatele rădăcină din /etc/ssl/certs si acolo. Rulez utilitarul openssl c_rehash -v „$CA_ROOTS_HASHES_DIR”. Mă aștept că acum pot folosi asta ca argument pentru -CApaths parametrul de verifica openssl.

Apoi, am semnarea ca-sub un certificat pentru ocsp-server.mydomain.org. Apoi creez un fișier pem de lanț cert „ocsp_signer_chain.pem”. Conține certificatul ocsp-server, certificatul sub-ca, apoi certificatul ca-root, în această ordine. Nu mă aștept să am nevoie de acest ocsp_signer_chain.pem, dar îl am.

Pot folosi openssl verify pentru a verifica ca_sub_cert_file:

`openssl verifica -verbose -show_chain -CApath "$CA_ROOTS_HASHES_DIR" "$ca_sub_cert_file"`
Bine
Lanţ:
adâncime=0: C = SUA, ST = California, L = Pacifica, O = Mydomain, CN = ca-sub.mydomain.org (neîncredere)
adâncime=1: C = SUA, ST = California, L = Pacifica, O = Mydomain, CN = ca-root.mydomain.org, emailAddress = [email protected]

Dar nu pot verifica ocsp-server_cert_file. Primesc mereu eroare 20 la căutarea profunzime 0: nu se poate obține certificatul de emitent local. Am încercat CAfile cu sub-chain.pem vs. ocsp_signer_chain.pem vs. -CAcale „$CA_ROOTS_HASHES_DIR”. Am incercat cu si fara -neîncredere „$ca_sub_cert_file”

openssl verifica -verbose -show_chain -CApath „$CA_ROOTS_HASHES_DIR” -neîncredere „$ca_sub_cert_file” „$ocsp-server_cert_file”`
C = SUA, ST = California, L = Pacifica, O = Mydomain, CN = ocsp-signer.mydomain.org
eroare 20 la căutarea profunzime 0: nu se poate obține certificatul de emitent local
eroare ocsp.mydomain.org_ocspserver_ocsp-signing.crt: verificarea eșuată

ce fac greșit? Am căutat de zile întregi, dar răspunsurile pe care le-am găsit se termină cu utilizarea CApath sau CAfile

Sunt surprins că, chiar și atunci când verific ca_sub_cert_file, openssl raportează „ca-sub.mydomain.org (untrusted)” mă așteptam ca având certificatul în CA_ROOTS_HASHES_DIR să fie de încredere. :/

Fișierele mele ca-conf funcționează pentru auto-semnare și semnare ca-sub, ceea ce mă face să cred că nu este o problemă de conf. Cu toate acestea, am învățat deja că este ușor să faci fișiere de conf care sunt greșite, fără avertisment de la openssl. Aici sunt fișierele mele de conf la GITHUB

Aici este secțiunea ca_extensions a ambelor fișiere ca.conf.

[ ca_extensions ]
basicConstraints = critic, CA:true
keyUsage = digitalSignature, keyEncipherment, keyCertSign, cRLSign
subjectKeyIdentifier = hash
authorityKeyIdentifier = keyid:always, emitent
extendedKeyUsage = serverAuth
crlDistributionPoints = URI:http://ca-root.mydomain.org/crl/mydomain.crl.pem
authorityInfoAccess = OCSP;URI:http://ca-root.mydomain.org:8083
dave_thompson_085 avatar
drapel jp
(1) Procesul pe care îl descrieți este unul corect, dacă detaliile pe care le-ați omis sunt corecte și **funcționează pentru mine** pe 18.04 (nu am încă 20.04 instalat). În special, aveți BasicConstraints și KeyUsage pe certificatele CA? (2) În `verify -show_chain`, liniile `(netrusted)` indică _porțiunea_ a lanțului care provine din surse nesigure, mai degrabă decât din truststore; atâta timp cât rezultatul este `fișier: OK` (și lanțul _se termină_ într-o rădăcină din truststore, sau altă ancoră cu `-partial_chain`), atunci verificarea (validarea) a reușit.

Postează un răspuns

Majoritatea oamenilor nu înțeleg că a pune multe întrebări deblochează învățarea și îmbunătățește legătura interpersonală. În studiile lui Alison, de exemplu, deși oamenii își puteau aminti cu exactitate câte întrebări au fost puse în conversațiile lor, ei nu au intuit legătura dintre întrebări și apreciere. În patru studii, în care participanții au fost implicați în conversații ei înșiși sau au citit transcrieri ale conversațiilor altora, oamenii au avut tendința să nu realizeze că întrebarea ar influența – sau ar fi influențat – nivelul de prietenie dintre conversatori.