Jeg bruker denne kommandoen:
openssl s_client -connect example.com:443 -CAfile /etc/ssl/certs/GTE_CyberTrust_Global_Root.pem
Det fungerer. Hvis jeg ikke spesifiserer at CAfile får jeg en kode 20. Certet er i /etc/ssl/certs
og /usr/lib/ssl/certs -> /etc/ssl/certs
Det er også inkludert i ca-certificates.crt
Hva styrer om openssl kan finne sertifikatet mitt eller ikke, og hvordan kan jeg få det til å godta dette sertifikatet uten å spesifisere det?
Kommentarer
Svar
Det er en kjent OpenSSL-feil der s_client ikke sjekker standard sertifikatlager når du ikke passerer -CApath
eller -CAfile
argument. OpenSSL på Ubuntu 14.04 lider av denne feilen da jeg demonstrerer:
Versjon:
ubuntu@puppetmaster:/etc/ssl$ openssl version OpenSSL 1.0.1f 6 Jan 2014
Klarer ikke å bruke 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
Nå sender jeg null 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
Dessverre tror jeg ikke det finnes en liste over berørte OpenSSL-versjoner. Den eneste måten å vite er å teste den.
Kommentarer
- Takk. Jeg brukte den versjonen. Det ser ikke ut til at OpenSSL 1.1.0 har løst problemet. Jeg ' m ser ikke problemet oppført her: github.com/openssl/openssl/issues Kan du referere til problemet?
- Det ' s i gammel RT-utgavespor . Det er en oppdatering der, den ' s bak en pålogging (gjest: gjest) Det ' s nummer # 3697, merket løst. rt.openssl.org/Ti cket / Display.html? id = 3697
- Ok, jeg bekreftet at dette er løst i 1.1, i det minste i richsalz-gaffelen. Da jeg oppgraderte la jeg ikke merke til at basiskatalogen ble skiftet til
/usr/local/ssl
som hadde en certs-katalog som ikke var kartlagt til/etc/ssl/certs
. - Jeg kan bekrefte at feilen eksisterer i CentOS 6.8 (OpenSSL 1.0.1e-fips 11. februar 2013).
- Også
openssl version -d
gir deg basiskonfigurasjonskatalogen …
Svar
"How to get openssl to use a cert without specifying it via -CAfile".
Jeg hadde det samme krav. Jeg ønsket å bruke en katalog med CA som jeg " stolte på " lokalt. Jeg ønsket ingen standard Trust store
forurensende resultater.
c_rehash
Før du ringer til verify
-kommandoen, hjalp hjelpesiden: man verify
meg til å bruke c_rehash
:
rehash skanner kataloger og beregner en hash-verdi for hver " .pem ", " .crt ", " .cer ", eller " .crl " -fil i filen spesifisert katalogliste og oppretter symbolske lenker for hver fil
export CERTS=/Users/{path_to_your_certs} [path to openssl]/openssl/bin/c_rehash ${CERTS}
Bekreft et bladsertifikat
openssl verify -CApath ${CERTS} local_leaf.pem local_leaf.pem: OK
Du laster Root CA og IntCA inne i katalogen CERTS
.Hvis jeg ikke gjorde rehash-trinnet, ville det gi meg feil 20 unable to get local issuer certificate
.
GTE_CyberTrust_Global_Root.pem
en mellomliggende CA? I så fall kan det hende at webserveren din ikke klarer å betjene det mellomliggende CA-sertifikatet sammen med nettstedssertifikatet ditt. Denne mangelen fra webserveren din kan forårsake kompatibilitetsproblemer med noen datamaskiner. På den annen side, hvisGTE_CyberTrust_Global_Root.pem
er et rotsertifikat på toppnivå, bør det fungere som standard.openssl
ikke er konfigurert med noen rotserier på toppnivå? Har du prøvdgoogle.com:443
?