«Échec de la négociation» signifie que la négociation a échoué et qu'il n'y a pas de connexion SSL / TLS. Vous devriez voir que cela opensslquitte le shell (ou CMD, etc.) et n'attend pas que les données d'entrée soient envoyées au serveur. "Vérifier le code retour 0" signifie qu'aucun problème n'a été trouvé dans le certificat du serveur, soit parce qu'il n'a pas été vérifié du tout, soit parce qu'il a été vérifié et était bon (en ce qui concerne les vérifications d'OpenSSL, qui ne couvrent pas tout); dans ce cas en connaissant le protocole on peut en déduire que ce dernier cas s'applique.
La réception d'une alertebad certificate (code 42) signifie que le serveur vous demande de vous authentifier avec un certificat, et vous ne l'avez pas fait, ce qui a provoqué l'échec de la prise de contact. Quelques lignes avant la ligne, SSL handshake has read ... and written ...vous devriez voir une ligne Acceptable client certificate CA namesgénéralement suivie de plusieurs lignes identifiant les autorités de certification, éventuellement suivie d'une ligne commençant Client Certificate Typeset peut-être en Requested Signature Algorithmsfonction de votre version d'OpenSSL et du protocole négocié.
Recherchez un certificat émis par une autorité de certification dans la liste «acceptable», ou s'il était vide, recherchez la documentation sur ou à propos du serveur indiquant les autorités de certification auxquelles il fait confiance ou contactez les opérateurs ou les propriétaires du serveur et demandez-leur, ainsi que la clé privée correspondante , les deux au format PEM, et spécifiez-les avec -cert $file -key $file; si vous avez les deux dans un seul fichier, comme c'est possible avec PEM, utilisez simplement-cert $file. Si vous les avez dans un format différent, spécifiez-le ou recherchez ici et peut-être superutilisateur et security.SX; il existe déjà de nombreuses questions et réponses sur la conversion de divers formats de certificats et de clés privées. Si votre certificat a besoin d'un certificat "chaîne" ou "intermédiaire" (ou même plus d'un) pour être vérifié, comme c'est souvent le cas pour un certificat provenant d'une autorité de certification publique (par opposition à un certificat interne) selon la configuration du serveur, s_clientnécessite une astuce: ajoutez le ou les certificats de chaîne à votre magasin de clés de confiance système, ou créez un fichier de clés de confiance local / temporaire contenant les certificats d'autorité de certification dont vous avez besoin pour vérifier le serveur PLUS les certificats de chaîne que vous devez envoyer.
Si vous ne disposez pas d'un tel certificat, vous devez en obtenir un, ce qui est une question différente qui nécessite beaucoup plus de détails pour répondre, ou vous devez trouver un moyen de vous connecter au serveur sans utiliser l'authentification par certificat; vérifier à nouveau la documentation et / ou demander aux opérateurs / propriétaires.
EDIT: Il ressort des commentaires que vous pouvez avoir la clé client et la chaîne de certificats ainsi que les ancres de serveur (s?) En Java. En vérifiant, je ne vois pas de bonne réponse existante couvrant entièrement ce cas, donc même si cela ne sera probablement pas bien recherché:
# 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
Dans mon cas, j'ai eu cette erreur lorsque la clé privée ne correspondait pas au certificat. J'avais mis à jour le certificat à l'expiration du mien et je devais créer une nouvelle clé privée. Cependant, j'ai oublié de faire référence à cela dans mon application. Lorsque j'ai indiqué la nouvelle clé privée, cette erreur a disparu.
la source