Jeg bruger denne kommando:
openssl s_client -connect example.com:443 -CAfile /etc/ssl/certs/GTE_CyberTrust_Global_Root.pem Det virker. Hvis jeg ikke angiver, at CAfile får jeg en kode 20. Certifikatet er i /etc/ssl/certs og /usr/lib/ssl/certs -> /etc/ssl/certs Det er også inkluderet i ca-certificates.crt
Hvad der styrer, om openssl kan finde mit certifikat eller ej, og hvordan kan jeg få det til at acceptere dette cert uden eksplicit at specificere det?
Kommentarer
Svar
Der er en kendt OpenSSL-fejl, hvor s_client ikke kontrollerer standardcertifikatlageret, når du ikke videregiver -CApath eller -CAfile argument. OpenSSL på Ubuntu 14.04 lider af denne fejl, da jeg demonstrerer:
Version:
ubuntu@puppetmaster:/etc/ssl$ openssl version OpenSSL 1.0.1f 6 Jan 2014 Bruger ikke standardbutikken, når jeg ikke passere `-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 videregiver jeg nul som -CApath og det fungerer:
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 Desværre tror jeg ikke, at der findes en liste over berørte OpenSSL-versioner. Den eneste måde at vide er at teste den.
Kommentarer
- Tak. Jeg brugte den version. OpenSSL 1.1.0 ser ikke ud til at have løst problemet. Jeg ' m ser ikke problemet opført her: github.com/openssl/openssl/issues Kan du henvise til problemet?
- Det ' s i gamle RT-tracker . Der er en patch der, den ' s bag et login (gæst: gæst) Det ' s nummer # 3697, markeret løst. rt.openssl.org/Ti cket / Display.html? id = 3697
- Ok, jeg bekræftede, at dette er rettet i 1.1, i det mindste i richsalz-gaffelen. Da jeg opgraderede, bemærkede jeg oprindeligt ikke, at basismappen blev skiftet til
/usr/local/ssl, hvor en certs-mappe ikke var tilknyttet/etc/ssl/certs. - Jeg kan verificere, at fejlen findes i CentOS 6.8 (OpenSSL 1.0.1e-fips 11. feb. 2013).
- Også
openssl version -dgiver dig basiskonfigurationsmappen …
Svar
"How to get openssl to use a cert without specifying it via -CAfile". Jeg havde det samme krav. Jeg ville bruge en mappe med CAer, som jeg " betroede " lokalt. Jeg ønskede ikke nogen standard Trust store forurenende resultater.
c_rehash
Før du kalder kommandoen verify, hjalp siden: man verify mig til at bruge c_rehash:
rehash scanner mapper og beregner en hash-værdi for hver " .pem ", " .crt ", " .cer " eller " .crl " -fil i filen specificeret katalogliste og opretter symbolske links til hver fil
export CERTS=/Users/{path_to_your_certs} [path to openssl]/openssl/bin/c_rehash ${CERTS} Bekræft et bladcertifikat
openssl verify -CApath ${CERTS} local_leaf.pem local_leaf.pem: OK Du indlæser root CA og IntCA inde i kataloget CERTS.Hvis jeg ikke foretog genopvaskningstrinnet, ville det give mig fejl 20 unable to get local issuer certificate.
GTE_CyberTrust_Global_Root.pemet mellemliggende CA? I så fald kan det være, at din webserver ikke leverer det mellemliggende CA-certifikat sammen med dit webstedscert. Denne mangel fra din webserver kan forårsage kompatibilitetsproblemer med nogle computere. På den anden side, hvisGTE_CyberTrust_Global_Root.pemer et topcertifikat på øverste niveau, skal det fungere som standard.opensslikke konfigureret med nogen root-certs på øverste niveau? Har du prøvetgoogle.com:443?