SSL routines:ssl3_read_bytes:ssl/tls alert handshake failure

OpenSSL 3.3 y las versiones posteriores imprimen «ssl/tls alert handshake failure», y las anteriores, «sslv3 alert handshake failure» (el mismo código 0A000410; 1.1.1 usaba 14094410). La línea termina con la ubicación en el código fuente y «SSL alert number 40».

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

Qué significa

El servidor envió la alerta TLS 40 (handshake_failure) y cerró la conexión. Es un rechazo genérico: el servidor no encontró en el ClientHello ningún conjunto de cifrado, grupo de intercambio de claves ni algoritmo de firma aceptable, exigía un certificado de cliente o rechazó el nombre de servidor solicitado. El cliente no puede conocer el motivo a partir de la alerta; está en el registro del servidor.

Por qué ocurre

• Ningún conjunto de cifrado en común

  frecuente

  Servidores antiguos limitados a conjuntos con intercambio de claves RSA, 3DES o RC4, o servidores estrictos que solo permiten unos pocos conjuntos que un cliente antiguo no tiene.

• Se exige un certificado de cliente (TLS 1.2)

  frecuente

  Con TLS 1.2, muchos servidores responden con handshake_failure cuando el certificado de cliente falta o no es aceptable; los servidores TLS 1.3 usan en su lugar certificate_required (alerta 116).

• SNI ausente o desconocido

  ocasional

  openssl s_client solo envía SNI cuando el host es un nombre o cuando se indica -servername; las CDN y los proxies multiinquilino abortan los handshakes sin un nombre conocido.

• Ningún grupo ni algoritmo de firma en común

  rara

  Los servidores restringidos a un único grupo (por ejemplo, uno híbrido poscuántico) o a firmas RSA-PSS pueden fallar con clientes que no ofrecen ninguno de los dos.

Cómo solucionarlo

1. 1.

   Leer el registro del servidor

   El servidor registra el motivo real, por ejemplo «no shared cipher» o «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.

   Acotar el problema desde el cliente

   Varía el SNI, la versión del protocolo, la lista de cifrados y la presencia de un certificado de cliente; la variante que funciona identifica la pieza que falta.

   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.

   Propietarios del servidor: ofrecer conjuntos actuales

   TLS 1.3 junto con TLS 1.2 con conjuntos ECDHE y AEAD funciona con todos los clientes que siguen teniendo mantenimiento.

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

← Explorar toda la base de datos de errores de firma