"Помика рукостискання" означає, що рукостискання не вдалося, і немає з'єднання SSL / TLS. Ви повинні побачити, що він opensslвиходить до оболонки (або CMD тощо) і не чекає надсилання вхідних даних на сервер. "Перевірити код повернення 0" означає, що в сертифікаті сервера не було виявлено жодних проблем , або тому, що він взагалі не був перевірений, або тому, що він був перевірений і був хороший (що стосується перевірок OpenSSL, який не охоплює все); в цьому випадку, знаючи протокол, ми можемо зробити висновок про те, що застосовується останній випадок.
Отримання сповіщенняbad certificate (код 42) означає, що сервер вимагає підтвердити автентифікацію сертифікатом, а ви цього не зробили, і це призвело до відмови рукостискання. За кілька рядків перед рядком SSL handshake has read ... and written ...ви повинні побачити рядок, Acceptable client certificate CA namesза яким зазвичай слідує кілька рядків, що ідентифікують ЦС, можливо, за ним слід початок рядка, Client Certificate Typesа може бути, приблизно, Requested Signature Algorithmsзалежно від вашої версії OpenSSL та протоколу узгодженого погодження.
Знайдіть сертифікат, виданий CA в списку "прийнятний", або якщо він порожній, шукайте документацію на або про сервер із зазначенням, яким ЦС він довіряє, або зв'яжіться з операторами або власниками серверів і запитайте їх, а також відповідний приватний ключ , обидва в форматі PEM, і вказати їх з -cert $file -key $file; якщо у вас є обидва в одному файлі, як це можливо з PEM, просто використовуйте-cert $file. Якщо у вас їх є в іншому форматі, або вкажіть його, або шукайте тут, і можливо, суперпользователь і безпека.SX; вже багато запитань щодо перетворення різних форматів сертифікатів та приватних ключів. Якщо ваш сертифікат потребує "ланцюгової" або "проміжної" церт (або навіть більше ніж один) для перевірки, як це часто буває для церта з загальнодоступного центрального офісу (проти домашнього), залежно від налаштування сервера, s_clientвимагає хитрості: або додайте церковні cert (s) до вашої системної довіри магазину, або створіть локальну / тимчасову довірену сховище, що містить сертифікати CA, які вам потрібно перевірити на сервері ПЛЮС церт (-ів) ланцюга, які вам потрібно надіслати.
Якщо у вас немає такого сертифіката, вам або потрібно отримати його, це інше питання, на яке потрібно відповісти набагато детальніше, або вам потрібно знайти спосіб підключення до сервера без використання автентифікації сертифікатів; ще раз перевірте документацію та / або запитайте операторів / власників.
РЕДАКТУВАННЯ: З коментарів випливає, що у вас можуть бути клієнтський ключ та ланцюг cert, а також серверний якор (и)? Під час перевірки я не бачу хорошої існуючої відповіді, яка повністю висвітлює цей випадок, так що, мабуть, це не буде добре шукати:
# 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