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