Gibt die Warnung "SSL3_READ_BYTES: SSLV3-Warnung fehlerhaftes Zertifikat" an, dass die SSL fehlgeschlagen ist

Während der Ausführung des folgenden Befehls wird s_client -host example.xyz -port 9093 geöffnet

Ich erhalte folgenden Fehler:

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:

Aber am Ende bekomme ich eine "Verify return code: 0 (ok)"Nachricht.

Meine Frage ist, was die oben genannte Warnung bedeutet und ob das SSL wirklich erfolgreich war. Vielen Dank für die Hilfe im Voraus.

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

"Handshake-Fehler" bedeutet, dass der Handshake fehlgeschlagen ist und keine SSL / TLS-Verbindung besteht. Sie sollten sehen, dass openssldie Shell (oder CMD usw.) beendet wird und nicht darauf wartet, dass Eingabedaten an den Server gesendet werden. "Verify return code 0" bedeutet, dass im Zertifikat des Servers kein Problem gefunden wurde, entweder weil es überhaupt nicht geprüft wurde oder weil es geprüft wurde und gut war (was OpenSSLs Prüfungen betrifft, die nicht alles abdecken); In diesem Fall können wir durch Kenntnis des Protokolls schließen, dass der letztere Fall zutrifft.

Beim Empfang einer Warnungbad certificate (Code 42) werden Sie vom Server aufgefordert, sich mit einem Zertifikat zu authentifizieren. Dies ist jedoch nicht der Fall und hat den Handshake-Fehler verursacht. Ein paar Zeilen vor der Zeile SSL handshake has read ... and written ...sollte eine Zeile Acceptable client certificate CA namesangezeigt werden, in der Regel gefolgt von mehreren Zeilen, die Zertifizierungsstellen identifizieren, möglicherweise gefolgt von einem Zeilenanfang Client Certificate Typesund möglicherweise Requested Signature Algorithmsabhängig von Ihrer OpenSSL-Version und dem ausgehandelten Protokoll.

Suchen Sie ein Zertifikat von einer Zertifizierungsstelle in der ‚akzeptabel‘ Liste ausgegeben, oder wenn es leer ist Blick für die Dokumentation auf oder über den Server zu sagen , welche CAs er vertraut oder kontaktieren Sie die Server - Betreiber oder Eigentümer und fragen sie, plus die passenden privaten Schlüssel , die beide im PEM-Format, und geben Sie sie mit -cert $file -key $file; Wenn Sie beide in einer Datei haben, wie es mit PEM möglich ist, verwenden Sie einfach-cert $file. Wenn Sie sie in einem anderen Format haben, geben Sie sie entweder an oder suchen Sie hier nach Superuser und security.SX; Es gibt bereits viele Fragen und Antworten zum Konvertieren verschiedener Zertifikats- und Private-Key-Formate. Wenn für Ihr Zertifikat ein "Chain" - oder "Intermediate" -Zertifikat (oder sogar mehr als eines) überprüft werden muss, wie dies bei einem Zertifikat einer öffentlichen Zertifizierungsstelle (im Gegensatz zu einem internen) häufig der Fall ist, je nachdem, wie der Server konfiguriert ist, s_clienterfordert einen Trick: Fügen Sie entweder die Kettenzertifikate zu Ihrem System-Truststore hinzu oder erstellen Sie einen lokalen / temporären Truststore mit den CA-Zertifikaten, die Sie zum Überprüfen des Servers benötigen, sowie den Kettenzertifikaten, die Sie senden müssen.

Wenn Sie nicht über ein solches Zertifikat verfügen, müssen Sie entweder eines anfordern. Dies ist eine andere Frage, deren Beantwortung wesentlich detaillierter ist, oder Sie müssen eine Möglichkeit finden, eine Verbindung zum Server herzustellen, ohne die Zertifikatauthentifizierung zu verwenden. Überprüfen Sie erneut die Dokumentation und / oder fragen Sie die Bediener / Eigentümer.

BEARBEITEN: Aus dem Kommentar geht hervor, dass Sie möglicherweise den Client-Schlüssel und die Zertifizierungskette sowie den Server-Anker (s?) In Java haben. Bei der Überprüfung sehe ich keine gute Antwort, die diesen Fall vollständig abdeckt, auch wenn dies wahrscheinlich nicht gut aussieht:

# 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

In meinem Fall habe ich diesen Fehler erhalten, wenn der private Schlüssel nicht mit dem Zertifikat übereinstimmt. Ich hatte das Zertifikat aktualisiert, als es abgelaufen war und ich einen neuen privaten Schlüssel erstellen musste. Allerdings habe ich vergessen, das in meiner App zu verweisen. Als ich auf den neuen privaten Schlüssel zeigte, verschwand dieser Fehler.