"Falha no handshake" significa que o handshake falhou e não há conexão SSL / TLS. Você deve ver que opensslsai para o shell (ou CMD etc) e não espera que os dados de entrada sejam enviados ao servidor. "Verificar código de retorno 0" significa que não foi encontrado nenhum problema no certificado do servidor, porque não foi verificado ou porque foi verificado e estava em boas condições (tanto quanto as verificações do OpenSSL, o que não cobre tudo); neste caso, conhecendo o protocolo, podemos deduzir que o último caso se aplica.
Receber alertabad certificate (código 42) significa que o servidor exige que você se autentique com um certificado, e você não o fez, o que causou a falha do handshake. Algumas linhas antes da linha, SSL handshake has read ... and written ...você verá uma linha Acceptable client certificate CA namesgeralmente seguida por várias linhas que identificam CAs, possivelmente seguidas por uma linha iniciada Client Certificate Typese talvez algumas Requested Signature Algorithmsdependendo da versão do OpenSSL e do protocolo negociado.
Encontre um certificado emitido por uma CA na lista 'aceitável' ou, se estiver vazio, procure documentação no servidor ou sobre o servidor dizendo em quais CAs confia ou entre em contato com os operadores ou proprietários do servidor e pergunte a eles, além da chave privada correspondente , ambos no formato PEM e especifique-os com -cert $file -key $file; se você tiver os dois em um arquivo, como é possível com o PEM, use-cert $file. Se você os tiver em um formato diferente, especifique-o ou pesquise aqui e talvez superusuário e security.SX; já existem muitas perguntas e respostas sobre a conversão de vários formatos de certificado e chave privada. Se o seu certificado precisar de um certificado "em cadeia" ou "intermediário" (ou até mais de um) para ser verificado, como geralmente é o caso de um certificado de uma CA pública (versus uma interna), dependendo de como o servidor está configurado, s_clientrequer um truque: adicione os certificados da cadeia ao armazenamento confiável do sistema ou crie um armazenamento confiável local / temporário que contenha os certificados da CA. Você precisa verificar o servidor MAIS os certificados da cadeia que você precisa enviar.
Se você não possui esse certificado, é necessário obter um, que é uma pergunta diferente, que exige muito mais detalhes para responder, ou precisa 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 as âncoras do servidor em Java. Ao verificar, não vejo uma boa resposta existente cobrindo completamente esse caso, portanto, mesmo que isso provavelmente não procure bem:
# 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