L'alerte "SSL3_READ_BYTES: mauvais certificat d'alerte sslv3" indique-t-elle que le SSL a échoué
Lors de l'exécution de la commande ci-dessous, openssl s_client -Host example.xyz -port 9093
J'obtiens l'erreur suivante:
139810559764296:error:14094412:SSL routines:SSL3_READ_BYTES:sslv3 alert bad certificate:s3_pkt.c:1259:SSL alert number 42
39810559764296:error:140790E5:SSL routines:SSL23_WRITE:ssl handshake failure:s23_lib.c:184:
Mais à la fin, je reçois un message "Verify return code: 0 (ok)".
Ma question est de savoir ce que signifie l'alerte ci-dessus et si le SSL a réellement réussi. Merci beaucoup pour l'aide à l'avance.
SSL handshake has read 6648 bytes and written 354 bytes
New, TLSv1/SSLv3, Cipher is AES128-SHA
Server public key is 2048 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
SSL-Session:
Protocol : TLSv1.2
Cipher : AES128-SHA
Session-ID: xx
Session-ID-ctx:
Master-Key: xx
Key-Arg : None
Krb5 Principal: None
PSK identity: None
PSK identity hint: None
Start Time: 1475096098
Timeout : 300 (sec)
**Verify return code: 0 (ok)**
"É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 openssl quitte 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 chèques 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.
Réception d'une alerte bad 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 names généralement suivi de plusieurs lignes identifiant les autorités de certification, éventuellement suivi d'une ligne commençant par Client Certificate Types et peut-être un peu de Requested Signature Algorithms en fonction de votre version d'OpenSSL et du protocole négocié.
Trouver un certificat émis par une autorité de certification dans la liste 'acceptable', ou s'il était vide, recherchez de la documentation sur ou à propos du serveur indiquant les autorités de certification auxquelles il fait confiance ou contactez les opérateurs ou propriétaires du serveur et demandez eux, plus la clé privée correspondante, tous 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_client nécessite une astuce: ajoutez 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 de CA 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érifiez à nouveau la documentation et/ou demandez aux opérateurs/propriétaires.
EDIT: Il ressort du commentaire 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. Quand j'ai pointé la nouvelle clé privée - cette erreur a disparu.