Является ли предупреждение «SSL3_READ_BYTES: sslv3 alert bad certificate», указывающее на сбой SSL

"Сбой при рукопожатии" означает сбой при рукопожатии, а также отсутствие SSL/TLS-соединения. Вы должны увидеть, что openssl выходит в оболочку (или CMD и т.д.) и не ждет отправки входных данных на сервер. "Verify return code 0" означает, что в сертификате сервера не было обнаружено проблем , либо потому, что он не был проверен вообще, либо потому, что он был проверен и был хорош (поскольку проверки OpenSSL идут, что не покрывает все); в этом случае, зная протокол, мы можем сделать вывод, что применяется последний случай.

Получение предупреждения плохой сертификат (код 42) означает, что сервер требует, чтобы вы аутентифицировали с помощью сертификата, а вы этого не делали, что и вызвало сбой при рукопожатии. За несколько строк до того, как строка SSL рукопожатия прочла ... и записала ..., вы должны увидеть строку Приемлемые имена CA клиентского сертификата , за которой обычно следуют несколько строк, идентифицирующих CA, возможно, за ними следует строка, начинающаяся со строки Типы клиентских сертификатов и, возможно, некоторые из Запрошенных алгоритмов подписей , в зависимости от вашей версии OpenSSL и согласованного протокола.

Найдите сертификат , выданный УЦ, в списке "приемлемых", или, если он пустой, ищите документацию на сервере или о том, какому УЦ он доверяет, или свяжитесь с операторами или владельцами сервера и спросите их, плюс соответствующий частный ключ , оба в формате PEM, и укажите их с помощью -cert $file -key $file ; если у вас оба в одном файле, как это возможно в PEM, просто используйте -cert $file. Если они у вас в другом формате, либо укажите их, либо ищите здесь и, возможно, суперпользователя и security.SX; Уже существует множество вопросов и ответов о преобразовании различных форматов сертификатов и приватных ключей. Если вашему сертификату нужен "цепной" или "промежуточный" сертификат (или даже более одного) для проверки, как это часто бывает для сертификата из публичного ЦС (по сравнению с внутренним), в зависимости от того, как сконфигурирован сервер, s_client требует подвоха: либо добавьте цепной сертификат(ы) в ваше системное хранилище трастов, либо создайте локальное/временное хранилище трастов, содержащее сертификат(ы) ЦС, вам нужно проверить сервер ПЛЮС сертификата(ов) цепочки, который вы должны отправить.

Если у вас нет такого сертификата, вам нужно либо получить его, что является другим вопросом, требующим гораздо более подробного ответа, либо найти способ подключиться к серверу без использования аутентификации сертификата; снова проверьте документацию и/или спросите операторов/владельцев.

EDIT: Из комментария видно, что у вас может быть клиентский ключ и цепочка сертификатов, а также якорь(и) сервера на 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