SSL routines:ssl3_read_bytes:ssl/tls alert handshake failure

Ab OpenSSL 3.3 lautet die Ausgabe „ssl/tls alert handshake failure“, in früheren Versionen „sslv3 alert handshake failure“ (derselbe Code 0A000410; 1.1.1 verwendete 14094410). Die Zeile endet mit der Stelle im Quellcode und „SSL alert number 40“.

OpenSSL (client side) — TLS alert 40 (handshake_failure) received from the server

Was der Fehler bedeutet

Der Server hat den TLS-Alert 40 (handshake_failure) gesendet und die Verbindung geschlossen. Das ist eine allgemeine Ablehnung: Der Server hat im ClientHello keine akzeptable Cipher Suite, keine akzeptable Schlüsselaustauschgruppe oder keinen akzeptablen Signaturalgorithmus gefunden, ein Client-Zertifikat verlangt oder den angeforderten Servernamen abgelehnt. Der Client kann den Grund nicht aus dem Alert erfahren; er steht im Log des Servers.

Warum der Fehler auftritt

• Keine gemeinsame Cipher Suite

  häufig

  Veraltete Server, die auf Suites mit RSA-Schlüsselaustausch, 3DES oder RC4 beschränkt sind; oder strenge Server, die nur eine Handvoll Suites zulassen, die einem alten Client fehlen.

• Ein Client-Zertifikat ist erforderlich (TLS 1.2)

  häufig

  Bei TLS 1.2 beantworten viele Server ein fehlendes oder nicht akzeptables Client-Zertifikat mit handshake_failure; Server mit TLS 1.3 verwenden stattdessen certificate_required (Alert 116).

• SNI fehlt oder ist unbekannt

  gelegentlich

  openssl s_client sendet SNI nur, wenn der Host ein Name ist oder -servername angegeben wird; CDNs und mandantenfähige Proxys brechen Handshakes ohne bekannten Namen ab.

• Keine gemeinsame Gruppe oder kein gemeinsamer Signaturalgorithmus

  selten

  Server, die auf eine einzige Gruppe (zum Beispiel ein hybrides Post-Quanten-Verfahren) oder auf RSA-PSS-Signaturen beschränkt sind, können an Clients scheitern, die keines von beidem anbieten.

So behebst du den Fehler

1. 1.

   Log des Servers lesen

   Der Server protokolliert den tatsächlichen Grund, zum Beispiel „no shared cipher“ oder „peer did not return a certificate“.

   # The server knows why; with openssl s_server or nginx the log says e.g.
   #   ...:tls_post_process_client_hello:no shared cipher
   #   ...:tls_process_client_certificate:peer did not return a certificate
   sudo tail -n 50 /var/log/nginx/error.log | grep -i ssl

2. 2.

   Vom Client aus eingrenzen

   Variiere SNI, die Protokollversion, die Cipher-Liste und ob ein Client-Zertifikat vorhanden ist; die Variante, die funktioniert, zeigt, was fehlt.

   h=api.example.com
   echo | openssl s_client -connect $h:443 -servername $h -brief                       # with SNI
   echo | openssl s_client -connect $h:443 -servername $h -tls1_2 -cipher 'ALL:@SECLEVEL=0' -brief
   echo | openssl s_client -connect $h:443 -servername $h -cert client.pem -key client.key -brief   # mTLS

3. 3.

   Eigener Server: aktuelle Suites anbieten

   Eine Konfiguration mit TLS 1.3 und zusätzlich TLS 1.2 mit ECDHE- und AEAD-Suites funktioniert mit jedem Client, der noch gepflegt wird.

   # nginx: modern suites for TLS 1.2 plus TLS 1.3
   ssl_protocols TLSv1.2 TLSv1.3;
   ssl_ciphers ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384;

← Gesamte Signaturfehler-Datenbank durchsuchen