"Errore di handshake" significa che l'handshake non è riuscito e non esiste una connessione SSL / TLS. Dovresti vedere che opensslesce dalla shell (o CMD ecc.) E non aspetta che i dati di input vengano inviati al server. "Verifica codice di ritorno 0" significa che non è stato riscontrato alcun problema nel certificato del server, sia perché non è stato controllato per niente o perché è stato controllato ed era buono (per quanto riguarda i controlli OpenSSL, che non copre tutto); in questo caso conoscendo il protocollo possiamo dedurre che si applica quest'ultimo caso.
La ricezione di un avvisobad certificate (codice 42) indica che il server richiede l'autenticazione con un certificato e non lo ha fatto e ciò ha causato l'errore di handshake. Alcune righe prima della riga SSL handshake has read ... and written ...dovresti vedere una riga Acceptable client certificate CA namesgeneralmente seguita da diverse righe che identificano le CA, eventualmente seguite da una riga che inizia Client Certificate Typese forse alcune circa a Requested Signature Algorithmsseconda della tua versione OpenSSL e del protocollo negoziato.
Trova un certificato emesso da una CA nell'elenco "accettabile" o se era vuoto cerca la documentazione sul o sul server che dice quali CA si fida o contatta gli operatori o i proprietari del server e chiedi loro, oltre alla chiave privata corrispondente , entrambi in formato PEM e specificarli con -cert $file -key $file; se hai entrambi in un file, come è possibile con PEM, basta usare-cert $file. Se li hai in un formato diverso, specificalo o cerca qui e forse superutente e security.SX; ci sono già molte domande e risposte sulla conversione di vari formati di certificati e chiavi private. Se il tuo certificato necessita di un certificato "a catena" o "intermedio" (o anche più di uno) da verificare, come spesso accade per un certificato di una CA pubblica (rispetto a uno interno) a seconda della configurazione del server, s_clientrichiede un trucco: aggiungi i certificati di catena al tuo truststore di sistema o crea un truststore locale / temporaneo contenente i certificati di CA che devi verificare sul server PIÙ i certificati di catena che devi inviare.
Se non si dispone di un tale certificato, è necessario ottenerne uno, che è una domanda diversa che richiede molti più dettagli per rispondere, oppure è necessario trovare un modo per connettersi al server senza utilizzare l'autenticazione tramite certificato; controlla nuovamente la documentazione e / o chiedi agli operatori / proprietari.
EDIT: Sembra che dai commenti potresti avere la chiave client e la catena di certificati nonché gli ancoraggi del server in Java. Al momento del controllo non vedo una buona risposta esistente che copra completamente quel caso, quindi anche se questo probabilmente non cercherà bene:
# 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