"Falha de handshake" significa que o handshake falhou e não há conexão SSL / TLS. Você deve ver que openssl sai para o shell (ou CMD, etc) e não espera que os dados de entrada sejam enviados para o servidor. "Verificar o código de retorno 0" significa que nenhum problema foi encontrado no certificado do servidor, porque não foi verificado ou porque foi verificado e foi bom (no que diz respeito às verificações do OpenSSL, que não cobre tudo); Nesse caso, conhecendo o protocolo, podemos deduzir que o último caso se aplica.
Recebendo o alerta bad certificate (código 42) significa que o servidor exige que você autentique com um certificado, e você não o fez e causou a falha de handshake. Algumas linhas antes da linha SSL handshake has read ... and written ... você deve ver uma linha Acceptable client certificate CA names geralmente seguida por várias linhas identificando CAs, possivelmente seguidas por uma linha que começa com Client Certificate Types e talvez cerca de Requested Signature Algorithms dependendo da sua versão do OpenSSL e do protocolo negociado .
Encontre um certificado emitido por uma autoridade de certificação na lista 'aceitável' ou, se estiver vazio, procure documentação sobre ou sobre o servidor informando em quais CAs confia ou entre em contato com os operadores ou proprietários do servidor e pergunte a eles, mais a chave privada correspondente , no formato PEM, e especifique-os com -cert $file -key $file ; se você tiver ambos em um arquivo, como é possível com o PEM, use apenas -cert $file . Se você os tiver em um formato diferente, especifique-o ou pesquise aqui e talvez superusuário e security.SX; já existem muitos Q & como sobre a conversão de vários formatos de certificado e chave privada. Se o seu certificado precisar de um certificado "chain" ou "intermediário" (ou até mais de um) para ser verificado, como é frequentemente o caso de um certificado de uma CA pública (versus uma CA interna) dependendo de como o servidor está configurado, s_client requer um truque: adicione o (s) certificado (s) de cadeia ao armazenamento confiável do sistema ou crie um armazenamento confiável local / temporário contendo o (s) certificado (s) CA necessário (s) para verificar o servidor enviar.
Se você não possui esse certificado, é necessário obter um, que é uma pergunta diferente que requer muito mais detalhes para responder ou é necessário encontrar uma maneira de se conectar ao servidor sem usar a autenticação de certificado; verifique novamente a documentação e / ou pergunte aos operadores / proprietários.
EDIT: Parece que a partir do comentário você pode ter a chave do cliente e a cadeia de certificados, bem como a âncora do servidor (s?) em Java. Ao verificar, não vejo uma boa resposta existente cobrindo totalmente esse caso, por isso, mesmo que isso provavelmente não seja bem pesquisado:
# 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