Ik gebruik dit commando:
openssl s_client -connect example.com:443 -CAfile /etc/ssl/certs/GTE_CyberTrust_Global_Root.pem Het werkt. Als ik die CAfile niet specificeer, krijg ik een code 20. Het certificaat staat in /etc/ssl/certs en /usr/lib/ssl/certs -> /etc/ssl/certs Het is ook opgenomen in de ca-certificates.crt
Wat bepaalt of openssl mijn cert kan vinden of niet en hoe kan ik ervoor zorgen dat het accepteert dit certificaat zonder het expliciet te specificeren?
Opmerkingen
Antwoord
Er is een bekende OpenSSL-bug waarbij s_client het standaardcertificaatarchief niet “controleert wanneer u de -CApath of -CAfile argument. OpenSSL op Ubuntu 14.04 lijdt aan deze bug, zoals ik zal aantonen:
Versie:
ubuntu@puppetmaster:/etc/ssl$ openssl version OpenSSL 1.0.1f 6 Jan 2014 Kan de standaardopslag niet gebruiken wanneer ik geef de `-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 niet door als de -CApath en het werkt:
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 Helaas denk ik niet dat er een lijst met getroffen OpenSSL-versies bestaat. De enige manier om dit te weten is door het te testen.
Opmerkingen
- Bedankt. Ik gebruikte die versie. OpenSSL 1.1.0 lijkt het probleem niet te hebben opgelost. I ' m het probleem dat hier wordt vermeld niet zien: github.com/openssl/openssl/issues Kunt u naar het probleem verwijzen?
- Het ' s in de oude RT-probleemtracker . Er is een patch, deze is ' s achter een login (guest: guest) Het ' s probleem # 3697, gemarkeerd als opgelost. rt.openssl.org/Ti cket / Display.html? id = 3697
- Oké, ik heb bevestigd dat dit in 1.1 is opgelost, tenminste in de richsalz-vork ervan. Toen ik de upgrade uitvoerde, merkte ik aanvankelijk niet dat de basismap was verschoven naar
/usr/local/ssl, die een certs-map had die niet was toegewezen aan/etc/ssl/certs. - Ik kan verifiëren dat de bug bestaat in CentOS 6.8 (OpenSSL 1.0.1e-fips 11 februari 2013).
- Ook geeft
openssl version -dje de basisconfiguratiemap …
Antwoord
"How to get openssl to use a cert without specifying it via -CAfile". Ik had hetzelfde vereiste. Ik wilde een directory met CAs gebruiken die ik " " lokaal vertrouwde. Ik wilde geen standaard Trust store vervuilende resultaten.
c_rehash
Voordat ik het verify commando aanriep, leidde de helppagina: man verify me naar c_rehash:
rehash scant mappen en berekent een hashwaarde van elke " .pem ", " .crt ", " .cer ", of " .crl " bestand in de gespecificeerde directorylijst en maakt symbolische links voor elk bestand
export CERTS=/Users/{path_to_your_certs} [path to openssl]/openssl/bin/c_rehash ${CERTS} Verifieer een leaf-certificaat
openssl verify -CApath ${CERTS} local_leaf.pem local_leaf.pem: OK Je laadt de root-CA en IntCA in de directory CERTS.Als ik de herhalingsstap niet zou doen, zou ik fout 20 unable to get local issuer certificate krijgen.
GTE_CyberTrust_Global_Root.pemeen tussenliggende CA? Als dit het geval is, kan het zijn dat uw webserver dat tussenliggende CA-certificaat niet samen met uw sitecertificaat levert. Deze tekortkoming van de kant van uw webserver kan compatibiliteitsproblemen veroorzaken met sommige computers. Aan de andere kant, alsGTE_CyberTrust_Global_Root.pemeen rootcertificaat van het hoogste niveau is, dan zou het standaard moeten werken.opensslniet geconfigureerd met rootcertificaten op het hoogste niveau? Heb jegoogle.com:443geprobeerd?