Jag använder det här kommandot:
openssl s_client -connect example.com:443 -CAfile /etc/ssl/certs/GTE_CyberTrust_Global_Root.pem Det fungerar. Om jag inte anger att CAfile får jag en kod 20. Certifikatet finns i /etc/ssl/certs och /usr/lib/ssl/certs -> /etc/ssl/certs Det ingår också i ca-certificates.crt
Vad styr om openssl kan hitta mitt cert eller inte och hur kan jag få det att acceptera detta cert utan att det uttryckligen anges?
Kommentarer
Svar
Det finns ett känt OpenSSL-fel där s_client inte kontrollerar standardcertifikatlagret när du inte skickar -CApath eller -CAfile argument. OpenSSL på Ubuntu 14.04 lider av detta fel när jag kommer att visa:
Version:
ubuntu@puppetmaster:/etc/ssl$ openssl version OpenSSL 1.0.1f 6 Jan 2014 Det går inte att använda standardbutiken när jag skicka inte `-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 Nu skickar jag null som -CApath och det fungerar:
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 Tyvärr tror jag inte att det finns en lista över berörda OpenSSL-versioner. Enda sättet att veta är att testa det.
Kommentarer
- Tack. Jag använde den versionen. OpenSSL 1.1.0 verkar inte ha löst problemet. Jag ' m ser inte problemet som anges här: github.com/openssl/openssl/issues Kan du referera till problemet?
- Det ' s i gamla RT-spårare . Det finns en patch där, den ' s bakom en inloggning (gäst: gäst) Det ' s nummer # 3697, markerat löst. rt.openssl.org/Ti cket / Display.html? id = 3697
- Ok, jag bekräftade att detta är fixat i 1.1, åtminstone i richsalz-gaffeln. När jag uppgraderade märkte jag till en början inte att baskatalogen flyttades till
/usr/local/ssldär en certs-katalog inte var mappad till/etc/ssl/certs. - Jag kan verifiera att felet finns i CentOS 6.8 (OpenSSL 1.0.1e-fips 11 feb 2013).
- Även
openssl version -dger dig baskonfigurationskatalogen …
Svar
"How to get openssl to use a cert without specifying it via -CAfile". Jag hade samma krav. Jag ville använda en katalog med CA som jag " betrodde " lokalt. Jag ville inte ha något Trust store förorenande resultat.
c_rehash
Innan du ringer till kommandot verify, hjälpte hjälpsidan: man verify mig att använda c_rehash:
rehash genomsöker kataloger och beräknar ett hashvärde för varje " .pem ", " .crt ", " .cer " eller " .crl " i filen specificerad kataloglista och skapar symboliska länkar för varje fil
export CERTS=/Users/{path_to_your_certs} [path to openssl]/openssl/bin/c_rehash ${CERTS} Verifiera ett lövcert
openssl verify -CApath ${CERTS} local_leaf.pem local_leaf.pem: OK Du laddar Root CA och IntCA inuti katalogen CERTS.Om jag inte gjorde omstegningssteget skulle det ge mig fel 20 unable to get local issuer certificate.
GTE_CyberTrust_Global_Root.pemen mellanliggande CA? I så fall kan det hända att din webbserver inte levererar det mellanliggande CA-certifikatet tillsammans med ditt webbplatscert. Denna brist från din webbserver kan orsaka kompatibilitetsproblem med vissa datorer. Å andra sidan, omGTE_CyberTrust_Global_Root.pemär ett toppcertifikat på toppnivå, ska det fungera som standard.opensslinte konfigurerad med några rotcertifikat på toppnivå? Har du provatgoogle.com:443?