L'alerte "SSL3_READ_BYTES: certificat sslv3 est-elle incorrecte" indique que le SSL a échoué


17

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 "Verify return code: 0 (ok)"message.

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)**

Réponses:


25

«É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

salut Dave; voici la procédure que nous avons suivie. 1: Téléchargez l'autorité de certification racine et les certificats intermédiaires dans le magasin de clés. 2: Téléchargez le certificat Comodo signé dans le magasin de clés. 3: Téléchargez l'autorité de certification racine et les certificats intermédiaires dans le magasin de clés de confiance. 4: Copiez les fichiers de clés et de fichiers de clés de confiance sur chaque nœud du cluster (cassandra). Les nœuds utilisent SSL pour la communication et semblent échanger des données sans problème. Cependant, lorsque j'exécute la commande SSL mentionnée ci-dessus, le problème se pose.
kris433

@ kris433: de quel magasin de clés s'agit-il? La procédure que vous décrivez ressemble à celle de Java si (et seulement si) elle a déjà généré une clé privée pour laquelle vous obtenez (ed) le `` certificat Comodo signé '', bien que si vous utilisez une installation Java standard, elle ait une valeur par défaut truststore qui comprend Comodo, vous ne devriez donc pas avoir besoin de changer cela. OpenSSL n'utilise aucun magasin de clés ou truststore Java et par défaut, il n'utilise aucun magasin de clés, c'est pourquoi vous devez spécifier des fichiers avec -cert [-key]. Si j'ai correctement interprété votre commentaire, voir modifier.
dave_thompson_085

Merci beaucoup Dave. Cela a parfaitement fonctionné. Tu as sauvé ma semaine. Si jamais vous venez à Philadelphie, le steak au fromage et le Gelato sont sur moi;). Merci encore.
kris433

@ kris433: vous êtes les bienvenus, mais la manière officielle de StackExchange consiste à accepter une réponse utile en utilisant la coche, afin que le système puisse automatiquement utiliser ces informations pour afficher les résultats aux autres candidats; voir la «visite» que vous étiez censé regarder lorsque vous êtes venu sur ce site, ou plus précisément serverfault.com/help/someone-answers .
dave_thompson_085

0

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.

En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.