Cum se obține openssl pentru a utiliza un certificat fără a-l specifica prin -CAfile

I „m folosind această comandă:

openssl s_client -connect example.com:443 -CAfile /etc/ssl/certs/GTE_CyberTrust_Global_Root.pem 

Funcționează. Dacă nu specific că CAfile primesc un cod 20. Cert este în /etc/ssl/certs și /usr/lib/ssl/certs -> /etc/ssl/certs Este, de asemenea, inclus în ca-certificates.crt

Ce reglementează dacă openssl îmi poate găsi sau nu certificatul și cum pot să-l accept acest certificat fără a-l specifica în mod explicit?

Comentarii

  • Este GTE_CyberTrust_Global_Root.pem o CA intermediară? Dacă da, este posibil ca serverul dvs. web să nu furnizeze acel certificat CA intermediar împreună cu certificatul site-ului dvs. Această neajuns din partea serverului dvs. web ar putea cauza probleme de compatibilitate cu unele computere. Pe de altă parte, dacă GTE_CyberTrust_Global_Root.pem este un certificat rădăcină de nivel superior, atunci ar trebui să funcționeze implicit.
  • @GeorgeBailey Mulțumesc. Este intermediar. Niciun motiv real pentru a nu împărtăși locația: bigfishgames-a.akamaihd.net:443 Dacă ' le cer oamenilor de internet să remedieze acest lucru, ce aș întreba? Simțiți-vă liber să faceți răspunsul dvs. un răspuns (adică " Nimic nu puteți face pe client, serverul trebuie să facă X ").
  • Acest lucru este ' ciudat. M-aș fi așteptat să funcționeze odată inclus în / etc / ssl / certs și ca-certificate.crt
  • Ei bine, ' nu este încă evident dacă serverul este problema. Se pare că serverul servește o CA intermediară și că SSLLabs tratează CyberTrust ca o rădăcină de nivel superior. S-ar putea să vă înșelați în privința faptului că CyberTrust este intermediar, dar poate aveți dreptate. Nu ' nu sunt sigur. Verificați lanțul / calea certificatului în browserul preferat și / sau pe SSLLabs . Poate că openssl nu este configurat cu niciun certificat root de nivel superior? Ați încercat google.com:443?
  • Același comportament pentru google.com

Răspuns

Există un bug OpenSSL cunoscut în care s_client nu verifică depozitul de certificate implicit atunci când nu treceți -CApath sau -CAfile argument. OpenSSL pe Ubuntu 14.04 suferă de această eroare, așa cum voi demonstra:

Versiune:

ubuntu@puppetmaster:/etc/ssl$ openssl version OpenSSL 1.0.1f 6 Jan 2014 

Nu reușește să folosesc magazinul implicit când nu „treceți` -ca:

ubuntu@puppetmaster:/etc/ssl$ openssl s_client -quiet -connect gmail.com:443 depth=2 C = US, O = GeoTrust Inc., CN = GeoTrust Global CA verify error:num=20:unable to get local issuer certificate verify return:0 

Acum trec nul ca -CApath și funcționează:

ubuntu@puppetmaster:/etc/ssl$ openssl s_client -quiet -connect gmail.com:443 -CApath /dev/null depth=3 C = US, O = Equifax, OU = Equifax Secure Certificate Authority verify return:1 depth=2 C = US, O = GeoTrust Inc., CN = GeoTrust Global CA verify return:1 depth=1 C = US, O = Google Inc, CN = Google Internet Authority G2 verify return:1 depth=0 C = US, ST = California, L = Mountain View, O = Google Inc, CN = mail.google.com verify return:1 

Din păcate, nu cred că există o listă de versiuni OpenSSL afectate. Singura modalitate de a ști este să o testați.

Comentarii

  • Mulțumesc. Foloseam acea versiune. OpenSSL 1.1.0 nu pare să fi remediat problema. I ' m nu se vede problema listată aici: github.com/openssl/openssl/issues Puteți face referire la problemă?
  • Este s în vechiul tracker de probleme . Există un patch acolo, este ' s în spatele unei date de conectare (guest: guest) Este ' problema # 3697, marcată rezolvată. rt.openssl.org/Ti cket / Display.html? id = 3697
  • Ok, am confirmat că acest lucru este fixat în 1.1, cel puțin în furculița richsalz a acestuia. Când am făcut upgrade, inițial nu am observat că directorul de bază sa mutat la /usr/local/ssl care avea un director certs care nu era mapat la /etc/ssl/certs.
  • Pot verifica dacă bug-ul există în CentOS 6.8 (OpenSSL 1.0.1e-fips 11 februarie 2013).
  • De asemenea, openssl version -d vă oferă directorul de configurare de bază …

Răspuns

"How to get openssl to use a cert without specifying it via -CAfile". 

Am avut același lucru cerinţă. Am vrut să folosesc un director de CA-uri în care am " de încredere " local. Nu am dorit rezultate poluante implicite Trust store.

c_rehash

Înainte de a apela comanda verify, pagina de ajutor: man verify m-a îndrumat să folosesc c_rehash:

rehash scanează directoare și calculează o valoare hash a fiecărui " .pem ", " .crt ", " .cer " sau " .crl " din fișierul listă de directoare specificată și creează legături simbolice pentru fiecare fișier

export CERTS=/Users/{path_to_your_certs} [path to openssl]/openssl/bin/c_rehash ${CERTS} 

Verificați un certificat frunză

openssl verify -CApath ${CERTS} local_leaf.pem local_leaf.pem: OK 

Încărcați CA Root și IntCA în directorul CERTS.Dacă nu aș face pasul de rehash, mi-ar da o eroare 20 unable to get local issuer certificate.

Lasă un răspuns

Adresa ta de email nu va fi publicată. Câmpurile obligatorii sunt marcate cu *