"Fallo de protocolo de enlace" significa que el protocolo de enlace falló y no hay conexión SSL / TLS. Debería ver que opensslsale al shell (o CMD, etc.) y no espera a que los datos de entrada se envíen al servidor. "Verificar el código de retorno 0" significa que no se encontró ningún problema en el certificado del servidor, ya sea porque no se verificó en absoluto o porque se verificó y era bueno (en lo que respecta a las verificaciones de OpenSSL, que no cubre todo); en este caso al conocer el protocolo podemos deducir que se aplica el último caso.
Recibir alertabad certificate (código 42) significa que el servidor exige que se autentique con un certificado, y no lo hizo, y eso provocó la falla del apretón de manos. Unas pocas líneas antes de la línea SSL handshake has read ... and written ...debería ver una línea Acceptable client certificate CA namesgeneralmente seguida de varias líneas que identifican a las CA, posiblemente seguidas por un comienzo de línea Client Certificate Typesy tal vez algunas sobre la base Requested Signature Algorithmsde su versión de OpenSSL y el protocolo negociado.
Encuentre un certificado emitido por una CA en la lista 'aceptable', o si estaba vacío, busque documentación en el servidor o sobre el servidor que indique en qué CA confía o comuníquese con los operadores o propietarios del servidor y pregúnteles, además de la clave privada correspondiente . en formato PEM y especifíquelos con -cert $file -key $file; si tiene ambos en un archivo, como es posible con PEM, simplemente use-cert $file. Si los tiene en un formato diferente, especifíquelo o busque aquí y quizás superusuario y seguridad. SX; Ya hay muchas preguntas y respuestas sobre la conversión de varios formatos de certificado y clave privada. Si su certificado necesita un certificado de "cadena" o "intermedio" (o incluso más de uno) para ser verificado, como suele ser el caso de un certificado de una CA pública (versus uno interno) dependiendo de cómo esté configurado el servidor, s_clientrequiere un truco: agregue los certificados de cadena al almacén de confianza de su sistema o cree un almacén de confianza local / temporal que contenga los certificados de CA que necesita para verificar el servidor MÁS los certificados de cadena que necesita enviar.
Si no tiene dicho certificado, necesita obtener uno, que es una pregunta diferente que requiere muchos más detalles para responder, o necesita encontrar una manera de conectarse al servidor sin usar la autenticación de certificado; nuevamente verifique la documentación y / o pregunte a los operadores / propietarios.
EDITAR: Parece que, por comentario, puede tener la clave del cliente y la cadena de certificados, así como los anclajes del servidor en Java. Al verificar, no veo una buena respuesta existente que cubra completamente ese caso, por lo que a pesar de que esto probablemente no busque bien:
# 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