"Kegagalan jabat tangan" berarti jabat tangan gagal, dan tidak ada koneksi SSL / TLS. Anda harus melihat bahwa opensslkeluar ke shell (atau CMD dll) dan tidak menunggu data input dikirim ke server. "Verifikasi kode pengembalian 0" berarti bahwa tidak ada masalah yang ditemukan dalam sertifikat server, baik karena tidak diperiksa sama sekali atau karena sudah diperiksa dan baik (sejauh pemeriksaan OpenSSL berjalan, yang tidak mencakup semuanya); dalam hal ini dengan mengetahui protokol kita dapat menyimpulkan kasus terakhir berlaku.
Menerima peringatanbad certificate (kode 42) berarti server meminta Anda untuk mengautentikasi dengan sertifikat, dan Anda tidak melakukannya, dan itu menyebabkan kegagalan jabat tangan. Beberapa baris sebelum baris, SSL handshake has read ... and written ...Anda akan melihat garis yang Acceptable client certificate CA namesbiasanya diikuti oleh beberapa baris yang mengidentifikasi CA, mungkin diikuti oleh garis awal Client Certificate Typesdan mungkin beberapa tentang Requested Signature Algorithmstergantung pada versi OpenSSL Anda dan protokol yang dinegosiasikan.
Temukan sertifikat yang dikeluarkan oleh CA di daftar 'dapat diterima', atau jika kosong cari dokumentasi di atau tentang server yang mengatakan CA mana yang dipercayai atau hubungi operator server atau pemilik dan tanyakan kepada mereka, ditambah kunci pribadi yang cocok , keduanya dalam format PEM, dan tentukan dengan -cert $file -key $file; jika Anda memiliki keduanya dalam satu file, seperti yang dimungkinkan dengan PEM, gunakan saja-cert $file. Jika Anda memilikinya dalam format yang berbeda, tentukan itu, atau cari di sini dan mungkin superuser dan keamanan. sudah ada banyak T&J tentang mengonversi berbagai format sertifikat dan privatekey. Jika sertifikat Anda memerlukan sertifikat "rantai" atau "perantara" (atau bahkan lebih dari satu) untuk diverifikasi, seperti yang sering terjadi untuk sertifikat dari CA publik (versus yang di dalam) tergantung pada bagaimana server dikonfigurasi, s_clientmembutuhkan trik: tambahkan sertifikat rantai ke truststore sistem Anda, atau buat truststore lokal / sementara yang berisi sertifikat CA yang perlu Anda verifikasi server PLUS dengan sertifikat rantai yang perlu Anda kirim.
Jika Anda tidak memiliki sertifikat seperti itu, Anda harus mendapatkannya, yang merupakan pertanyaan berbeda yang membutuhkan lebih banyak detail untuk dijawab, atau Anda perlu menemukan cara untuk terhubung ke server tanpa menggunakan otentikasi sertifikat; periksa lagi dokumentasi dan / atau tanya operator / pemilik.
EDIT: Tampaknya dari komentar Anda mungkin memiliki kunci klien dan rantai sertifikat serta jangkar server di Jawa. Saat memeriksa, saya tidak melihat jawaban yang ada untuk sepenuhnya menutupi kasus itu, jadi meskipun ini mungkin tidak akan mencari dengan baik:
# 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