Używam tego polecenia:
openssl s_client -connect example.com:443 -CAfile /etc/ssl/certs/GTE_CyberTrust_Global_Root.pem
Działa. Jeśli nie określę pliku CA, otrzymam kod 20. Certyfikat znajduje się w /etc/ssl/certs
i /usr/lib/ssl/certs -> /etc/ssl/certs
Jest również uwzględnione w ca-certificates.crt
Co decyduje o tym, czy openssl może znaleźć mój certyfikat, czy nie i jak mogę go zaakceptować ten certyfikat bez wyraźnego określenia go?
Komentarze
Odpowiedź
Istnieje znany błąd OpenSSL, w którym s_client nie sprawdza domyślnego magazynu certyfikatów, jeśli nie przejdziesz -CApath
lub -CAfile
. OpenSSL na Ubuntu 14.04 cierpi z powodu tego błędu, ponieważ pokażę:
Wersja:
ubuntu@puppetmaster:/etc/ssl$ openssl version OpenSSL 1.0.1f 6 Jan 2014
Nie używa domyślnego magazynu, gdy ja nie przekazuj `-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
Teraz przekazuję null jako -CApath
i działa:
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
Niestety nie wydaje mi się, aby istnieje lista wersji OpenSSL, których dotyczy problem. Jedynym sposobem, aby się dowiedzieć, jest przetestowanie jej.
Komentarze
- Dzięki. Używałem tej wersji. Wydaje się, że OpenSSL 1.1.0 nie rozwiązało problemu. I ' m nie widzę problemu wymienionego tutaj: github.com/openssl/openssl/issues Czy możesz odnieść się do problemu?
- To ' znajduje się w starym module śledzenia problemów RT . Jest tam poprawka, ' za loginem (gość: gość) To ' problem nr 3697, oznaczony jako rozwiązany. rt.openssl.org/Ti cket / Display.html? id = 3697
- OK, potwierdziłem, że jest to poprawione w wersji 1.1, przynajmniej w widelcu richsalz. Podczas aktualizacji początkowo nie zauważyłem, że katalog podstawowy został przesunięty do
/usr/local/ssl
, w którym katalog certs nie został zmapowany do/etc/ssl/certs
. - Mogę sprawdzić, czy błąd istnieje w CentOS 6.8 (OpenSSL 1.0.1e-fips 11 lutego 2013 r.).
- Ponadto
openssl version -d
udostępnia podstawowy katalog konfiguracyjny …
Odpowiedź
"How to get openssl to use a cert without specifying it via -CAfile".
Miałem to samo wymaganie. Chciałem użyć katalogu urzędów certyfikacji, które " zaufane " lokalnie. Nie chciałem żadnych domyślnych Trust store
wyników zanieczyszczających.
c_rehash
Przed wywołaniem polecenia verify
strona pomocy: man verify
poprowadziła mnie do użycia c_rehash
:
rehash skanuje katalogi i oblicza wartość skrótu każdego " .pem ", " .crt ", " .cer " lub " .crl " w określoną listę katalogów i tworzy dowiązania symboliczne dla każdego pliku
export CERTS=/Users/{path_to_your_certs} [path to openssl]/openssl/bin/c_rehash ${CERTS}
Zweryfikuj certyfikat liścia
openssl verify -CApath ${CERTS} local_leaf.pem local_leaf.pem: OK
Ładujesz główny urząd certyfikacji i IntCA w katalogu CERTS
.Gdybym nie wykonał kroku ponownego skrótu, dałby mi błąd 20 unable to get local issuer certificate
.
GTE_CyberTrust_Global_Root.pem
to pośredni urząd certyfikacji? Jeśli tak, może to oznaczać, że serwer WWW nie obsługuje tego pośredniego certyfikatu CA wraz z certyfikatem witryny. Ta wada po stronie twojego serwera internetowego może powodować problemy ze zgodnością z niektórymi komputerami. Z drugiej strony, jeśliGTE_CyberTrust_Global_Root.pem
jest certyfikatem głównym najwyższego poziomu, to powinien działać domyślnie.openssl
nie ma skonfigurowanych żadnych certyfikatów głównych najwyższego poziomu? Czy próbowałeś jużgoogle.com:443
?