„Błąd uzgadniania” oznacza niepowodzenie uzgadniania i brak połączenia SSL / TLS. Powinieneś zobaczyć, że opensslwychodzi z powłoki (lub CMD itp.) I nie czeka na przesłanie danych wejściowych do serwera. „Zweryfikuj kod powrotu 0” oznacza, że nie znaleziono żadnego problemu w certyfikacie serwera, albo dlatego, że nie został wcale sprawdzony, albo dlatego, że został sprawdzony i był dobry (jeśli chodzi o kontrole OpenSSL, co nie obejmuje wszystkiego); w tym przypadku znając protokół, możemy wywnioskować, że zastosowanie ma ten drugi przypadek.
Otrzymanie alertubad certificate (kod 42) oznacza, że serwer żąda uwierzytelnienia za pomocą certyfikatu, a ty tego nie zrobiłeś, co spowodowało błąd uzgadniania. Kilka linii przed linią SSL handshake has read ... and written ...powinieneś zobaczyć linię, Acceptable client certificate CA namespo której zwykle następuje kilka linii identyfikujących urzędy certyfikacji, ewentualnie może być linia rozpoczynająca się, Client Certificate Typesa może trochę o Requested Signature Algorithmszależności od wersji OpenSSL i wynegocjowanego protokołu.
Znajdź certyfikat wydany przez urząd certyfikacji na liście „akceptowalnych” lub, jeśli był pusty, poszukaj dokumentacji na serwerze lub na temat tego, który urząd certyfikacji ufa lub skontaktuj się z operatorami lub właścicielami serwera i poproś o nie, a także pasujący klucz prywatny , oba w formacie PEM i określ je za pomocą -cert $file -key $file; jeśli masz oba w jednym pliku, jak to jest możliwe w PEM, po prostu użyj-cert $file. Jeśli masz je w innym formacie, określ go lub wyszukaj tutaj, a może superużytkownik i bezpieczeństwo.SX; istnieje już wiele pytań i odpowiedzi dotyczących konwersji różnych formatów certyfikatów i kluczy prywatnych. Jeśli Twój certyfikat wymaga weryfikacji certyfikatu „łańcuchowego” lub „pośredniego” (lub nawet więcej niż jednego), jak to często bywa w przypadku certyfikatu z publicznego urzędu certyfikacji (w porównaniu z wewnętrznym) w zależności od konfiguracji serwera, s_clientwymaga sztuczki: albo dodaj certyfikaty łańcuchowe do systemowego magazynu zaufanych certyfikatów, albo utwórz lokalny / tymczasowy magazyn zaufanych certyfikatów zawierający certyfikaty CA potrzebne do zweryfikowania na serwerze PLUS certyfikatów łańcuchowych, które musisz wysłać.
Jeśli nie masz takiego certyfikatu, musisz go zdobyć, co jest innym pytaniem, które wymaga znacznie więcej szczegółów, lub musisz znaleźć sposób na połączenie się z serwerem bez korzystania z uwierzytelniania certyfikatu; ponownie sprawdź dokumentację i / lub zapytaj operatorów / właścicieli.
EDYCJA: Z komentarza wynika, że możesz mieć klucz klienta i łańcuch certyfikatów, a także kotwicę (-y) serwera w Javie. Podczas sprawdzania nie widzę dobrej istniejącej odpowiedzi w pełni obejmującej tę sprawę, więc nawet jeśli prawdopodobnie nie będzie to dobrze wyszukiwać:
# Assume Java keystore is type JKS (the default but not only possibility)
# named key.jks and the privatekey entry is named mykey (ditto)
# and the verify certs are in trust.jks in entries named trust1 trust2 etc.
# convert Java key entry to PKCS12 then PKCS12 to PEM files
keytool -importkeystore -srckeystore key.jks -destkeystore key.p12 -deststoretype pkcs12 -srcalias mykey
openssl pkcs12 -in key.p12 -nocerts -out key.pem
openssl pkcs12 -in key.p12 -nokeys -clcerts -out cert.pem
openssl pkcs12 -in key.p12 -nokeys -cacerts -out chain.pem
# extract verify certs to individual PEM files
# (or if you 'uploaded' PEM files and still have them just use those)
keytool -keystore trust.jks -export -alias trust1 -rfc -file trust1.pem
keytool -keystore trust.jks -export -alias trust2 -rfc -file trust2.pem
... more if needed ...
# combine for s_client
cat chain.pem trust*.pem >combined.pem
openssl s_client -connect host:port -key key.pem -cert cert.pem -CAfile combined.pem