Sto usando questo comando:
openssl s_client -connect example.com:443 -CAfile /etc/ssl/certs/GTE_CyberTrust_Global_Root.pem Funziona. Se non specifichi che CAfile ottengo un codice 20. Il certificato è in /etc/ssl/certs e /usr/lib/ssl/certs -> /etc/ssl/certs È anche incluso nel ca-certificates.crt
Che cosa determina se openssl può trovare o meno il mio certificato e come posso convincerlo ad accettarlo questo certificato senza specificarlo esplicitamente?
Commenti
Risposta
Esiste un bug noto di OpenSSL in cui s_client non controlla larchivio certificati predefinito quando non si passa il -CApath o -CAfile argomento. OpenSSL su Ubuntu 14.04 soffre di questo bug come dimostrerò:
Versione:
ubuntu@puppetmaster:/etc/ssl$ openssl version OpenSSL 1.0.1f 6 Jan 2014 Non riesce a utilizzare larchivio predefinito quando non passare “-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 Ora passo null come -CApath e funziona:
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 Sfortunatamente non credo che esista un elenco di versioni di OpenSSL interessate. Lunico modo per saperlo è testarlo.
Commenti
- Grazie. Stavo usando quella versione. OpenSSL 1.1.0 non sembra aver risolto il problema. I ' m non vedi il problema elencato qui: github.com/openssl/openssl/issues Puoi fare riferimento al problema?
- It ' nel vecchio rilevatore di problemi RT . Cè una patch, ' è dietro un accesso (guest: guest) È ' il problema n. 3697, contrassegnato come risolto. rt.openssl.org/Ti cket / Display.html? id = 3697
- Ok, ho confermato che questo problema è stato risolto nella 1.1, almeno nel fork di richsalz. Quando ho eseguito laggiornamento, inizialmente non ho notato che la directory di base si è spostata in
/usr/local/sslche aveva una directory certs non mappata su/etc/ssl/certs. - Posso verificare che il bug esista in CentOS 6.8 (OpenSSL 1.0.1e-fips 11 febbraio 2013).
- Inoltre
openssl version -dti fornisce la directory di configurazione di base …
Risposta
"How to get openssl to use a cert without specifying it via -CAfile". Ho avuto lo stesso Requisiti. Volevo utilizzare una directory di CA di cui " attendibile " localmente. Non volevo Trust store risultati inquinanti predefiniti.
c_rehash
Prima di chiamare il comando verify, la pagina della guida: man verify mi ha guidato alluso di c_rehash:
rehash scansiona le directory e calcola un valore hash di ciascuna " .pem ", " .crt ", " .cer " o " .crl " nel file elenco di directory specificato e crea collegamenti simbolici per ogni file
export CERTS=/Users/{path_to_your_certs} [path to openssl]/openssl/bin/c_rehash ${CERTS} Verifica un certificato foglia
openssl verify -CApath ${CERTS} local_leaf.pem local_leaf.pem: OK Carica la CA radice e IntCA allinterno della directory CERTS.Se non avessi eseguito il passaggio di rehash, avrei ricevuto lerrore 20 unable to get local issuer certificate.
GTE_CyberTrust_Global_Root.pemè una CA intermedia? In tal caso, è possibile che il tuo server web non riesca a fornire quel certificato CA intermedio insieme al certificato del tuo sito. Questa mancanza da parte del tuo server web potrebbe causare problemi di compatibilità con alcuni computer. Daltra parte, seGTE_CyberTrust_Global_Root.pemè un certificato radice di primo livello, dovrebbe funzionare per impostazione predefinita.opensslnon è configurato con alcun certificato radice di primo livello? Hai provatogoogle.com:443?