Mam dziwny problem. Zaktualizowałem moją maszynę programistyczną LAMP (Debian) do PHP 7. Następnie nie mogę już połączyć się z konkretnym zaszyfrowanym API TLS przez Curl.
Certyfikat SSL, o którym mowa, jest podpisany przez thawte.
curl https://example.com
daje mi
curl: (60) SSL certificate problem: unable to get local issuer certificate
natomiast
curl https://thawte.com
który - oczywiście - jest również podpisany przez dzieła Thawte.
Mogę uzyskać dostęp do strony API za pośrednictwem HTTPS na innych komputerach, np. Na moim pulpicie przez curl i w przeglądarce. Więc certyfikat jest definitywnie ważny. Ocena SSL Labs to A.
Wszelkie inne żądania Curl z mojego urządzenia deweloperskiego do innych stron szyfrowanych SSL działają. Moje certyfikaty root są aktualne. Aby zweryfikować, pobiegłem update-ca-certificates
. Nawet pobrałem http://curl.haxx.se/ca/cacert.pem do / etc / ssl / certs i uruchomiłem c_rehash
.
Wciąż ten sam błąd.
Czy jest jakiś sposób na debugowanie procesu weryfikacji i sprawdzenie, który lokalny certyfikat wystawcy (lub openssl) szuka, ale nie znajduje, tj. Nazwę pliku?
AKTUALIZACJA
curl -vs https://example.com
mówi mi (anonimowa IP + Domena)
* Hostname was NOT found in DNS cache
* Trying 192.0.2.1...
* Connected to example.com (192.0.2.1) port 443 (#0)
* successfully set certificate verify locations:
* CAfile: none
CApath: /etc/ssl/certs
* SSLv3, TLS handshake, Client hello (1):
* SSLv3, TLS handshake, Server hello (2):
* SSLv3, TLS handshake, CERT (11):
* SSLv3, TLS alert, Server hello (2):
* SSL certificate problem: unable to get local issuer certificate
* Closing connection 0
I
echo | openssl s_client -connect example.com:443
daje
CONNECTED(00000003)
depth=2 C = US, O = "thawte, Inc.", OU = Certification Services Division, OU = "(c) 2006 thawte, Inc. - For authorized use only", CN = thawte Primary Root CA
verify error:num=20:unable to get local issuer certificate
verify return:0
---
Certificate chain
0 s:/C=DE/ST=XYZ/CN=*.example.com
i:/C=US/O=thawte, Inc./CN=thawte SSL CA - G2
1 s:/C=US/O=thawte, Inc./CN=thawte SSL CA - G2
i:/C=US/O=thawte, Inc./OU=Certification Services Division/OU=(c) 2006 thawte, Inc. - For authorized use only/CN=thawte Primary Root CA
2 s:/C=US/O=thawte, Inc./OU=Certification Services Division/OU=(c) 2006 thawte, Inc. - For authorized use only/CN=thawte Primary Root CA
i:/C=ZA/ST=Western Cape/L=Cape Town/O=Thawte Consulting cc/OU=Certification Services Division/CN=Thawte Premium Server CA/[email protected]
---
Server certificate
-----BEGIN CERTIFICATE-----
[...]
-----END CERTIFICATE-----
subject=/C=DE/ST=XYZ/CN=*.example.com
issuer=/C=US/O=thawte, Inc./CN=thawte SSL CA - G2
---
No client certificate CA names sent
---
SSL handshake has read 4214 bytes and written 421 bytes
---
New, TLSv1/SSLv3, Cipher is ECDHE-RSA-AES256-GCM-SHA384
Server public key is 2048 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
SSL-Session:
Protocol : TLSv1.2
Cipher : ECDHE-RSA-AES256-GCM-SHA384
Session-ID: [...]
Session-ID-ctx:
Master-Key: [...]
Key-Arg : None
PSK identity: None
PSK identity hint: None
SRP username: None
TLS session ticket lifetime hint: 300 (seconds)
TLS session ticket:
0000 - 5a 95 df 40 2c c9 6b d5-4a 50 75 c5 a3 80 0a 2d Z..@,.k.JPu....-
[...]
00b0 - d5 b9 e8 25 00 c5 c7 da-ce 73 fb f2 c5 46 c4 24 ...%.....s...F.$
Start Time: 1455111516
Timeout : 300 (sec)
Verify return code: 20 (unable to get local issuer certificate)
---
DONE
curl -vs https://example.com echo | openssl s_client -connect example.com:443
Odpowiedzi:
Korzystanie z
openssl s_client -connect thawte.com:443
programów:To ostatnie „i” pokazuje samopodpisujący się główny urząd certyfikacji. Zgaduję, że ten konkretny główny urząd certyfikacji Thawte , tj. Podstawowa głównej CA - G3 cert, nie znajduje się w
/etc/ssl/certs
katalogu (jak stwierdzono wcurl
produkcji;openssl s_client
nie posiada domyślną ścieżkę CA, i musi danemu jawnie np-CApath /etc/ssl/certs
).Bezpośrednie dodanie tego certyfikatu do
/etc/ssl/certs
katalogu (i ponowne uruchomieniec_rehash
) z pewnością nie zaszkodzi. A jeśli to działa, np. Jak zweryfikowano za pomocąopenssl s_client -connect example.com:443 -CApath /etc/ssl/certs
, to wiesz, że toupdate-ca-certificates
polecenie może wymagać sprawdzenia / debugowania, aby dowiedzieć się, dlaczego nie wybrał tego głównego urzędu certyfikacji.Możliwe, że powyższy główny urząd certyfikacji znajduje się już w
/etc/ssl/certs
katalogu i powyższe kroki nie przyniosły żadnego efektu. W takim przypadku istnieją dwa inne wydające certyfikaty CA do sprawdzenia (przynajmniej w łańcuchu certyfikatów oferowanych przezthawte.com:443
): thawte Primary Root CA i thawte SSL CA - G2 . Powtórzenie powyższych kroków w celu zainstalowania tych certyfikatów w/etc/ssl/certs
katalogu (i ponownym uruchomieniuc_rehash
) może działać. Ponieważ te dwa są pośrednimi urzędami certyfikacji, a nie głównymi urzędami certyfikacji, brak jednego z nich wyjaśniłby wyniki i może być oczekiwany jako przeoczony certyfikat przezupdate-ca-certificates
.Mam nadzieję że to pomoże!
źródło
openssl s_client -connect <server>:443 -CAfile cacert.pem
polecenie jest bardzo pomocne ... dziękuję!Może to być spowodowane niewłaściwą kolejnością witryny, wydawaniem certyfikatów pośrednich i głównych w pliku certyfikatu klucza publicznego witryny.
Przeglądarka wyświetla certyfikaty w odwrotnym kierunku góra-dół (root, pośrednie, wystawianie, witryna), ale certyfikat musi być w kierunku bottom-top (witryna, wystawianie, pośrednie, root).
źródło