SSL routines:ssl3_read_bytes:ssl/tls alert handshake failure

OpenSSL 3.3 et les versions ultérieures affichent « ssl/tls alert handshake failure », les versions antérieures « sslv3 alert handshake failure » (même code 0A000410 ; 1.1.1 utilisait 14094410). La ligne se termine par l’emplacement dans le code source et « SSL alert number 40 ».

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

Ce que cela signifie

Le serveur a envoyé l’alerte TLS 40 (handshake_failure) et fermé la connexion. Il s’agit d’un refus générique : le serveur n’a trouvé dans le ClientHello aucune suite de chiffrement, aucun groupe d’échange de clés ni aucun algorithme de signature acceptable, il exigeait un certificat client, ou il a rejeté le nom de serveur demandé. L’alerte ne permet pas au client d’en connaître la raison ; celle-ci figure dans le journal du serveur.

Pourquoi cela se produit

• Aucune suite de chiffrement en commun

  fréquente

  Des serveurs anciens limités aux suites à échange de clés RSA, aux suites 3DES ou aux suites RC4 ; ou des serveurs stricts qui n’autorisent qu’une poignée de suites qu’un client ancien ne possède pas.

• Un certificat client est exigé (TLS 1.2)

  fréquente

  En TLS 1.2, de nombreux serveurs répondent à un certificat client absent ou inacceptable par handshake_failure ; les serveurs TLS 1.3 utilisent à la place certificate_required (alerte 116).

• SNI absent ou inconnu

  occasionnelle

  openssl s_client n’envoie le SNI que si l’hôte est un nom ou si -servername est indiqué ; les CDN et les proxys multilocataires interrompent les handshakes qui ne portent pas de nom connu.

• Aucun groupe ni algorithme de signature en commun

  rare

  Les serveurs limités à un seul groupe (par exemple un groupe hybride post-quantique) ou aux signatures RSA-PSS peuvent échouer face aux clients qui ne proposent ni l’un ni l’autre.

Comment corriger l’erreur

1. 1.

   Lire le journal du serveur

   Le serveur consigne la raison réelle, par exemple « no shared cipher » ou « 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.

   Cerner le problème depuis le client

   Faites varier le SNI, la version du protocole, la liste de chiffrements et la présence d’un certificat client ; la variante qui réussit désigne l’élément manquant.

   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.

   Propriétaires de serveurs : proposer des suites actuelles

   TLS 1.3, complété par TLS 1.2 avec des suites ECDHE et AEAD, fonctionne avec tous les clients maintenus.

   # 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;

← Parcourir toute la base de données des erreurs de signature