SSL routines:tls_post_process_client_hello:no shared cipher

openssl s_server (OpenSSL 3.x) registra «error:0A0000C1:SSL routines:tls_post_process_client_hello:no shared cipher:<source>»; nginx registra «SSL_do_handshake() failed (SSL: error:0A0000C1:SSL routines::no shared cipher) while SSL handshaking» en el nivel info, así que no se ve con el nivel predeterminado de error_log. OpenSSL 1.1.1 usaba el código 1417A0C1.

OpenSSL (server side: nginx, Apache, Postfix, openssl s_server) — SSL_R_NO_SHARED_CIPHER

Qué significa

Esta es la visión que tiene el servidor de un handshake fallido: ninguno de los conjuntos de cifrado del ClientHello del cliente está a la vez habilitado en el servidor y se puede usar con la clave del certificado del servidor. Después, el servidor envía handshake_failure (alerta 40) al cliente. Aparece en los registros del servidor, no en la salida del cliente.

Por qué ocurre

• La lista de cifrados no se ajusta al tipo de clave del certificado

  frecuente

  Un certificado ECDSA con solo conjuntos ECDHE-RSA-* habilitados (o un certificado RSA con solo ECDHE-ECDSA-*) no deja ningún conjunto TLS 1.2 utilizable, así que todos los clientes TLS 1.2 fallan.

• Una lista de cifrados recortada a mano deja fuera a clientes reales

  frecuente

  Las listas reducidas a uno o dos conjuntos, o solo a CHACHA20, dejan fuera a los clientes (y a las herramientas de monitorización) que prefieren otros conjuntos modernos.

• Clientes muy antiguos

  ocasional

  Los clientes limitados a conjuntos con intercambio de claves RSA, CBC o 3DES (Java antiguo, dispositivos embebidos) no pueden conectarse a una configuración moderna; decide de forma deliberada si quieres admitirlos.

Cómo solucionarlo

1. 1.

   Comprobar que la clave del certificado encaja con los conjuntos

   Los conjuntos ECDHE-ECDSA-* necesitan un certificado ECDSA, y los ECDHE-RSA-*, uno RSA; los servidores con ambos certificados pueden incluir las dos familias.

   # ECDSA key + only ECDHE-RSA suites (or the reverse) leaves nothing usable
   openssl x509 -in server.pem -noout -text | grep 'Public Key Algorithm'
   openssl ciphers -v 'ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256'

2. 2.

   Enumerar los conjuntos que el servidor acepta realmente

   Enuméralos desde fuera y compáralos con los clientes que necesitas admitir.

   # Which TLS 1.2 suites does the server accept? (nmap needed)
   nmap --script ssl-enum-ciphers -p 443 api.example.com

3. 3.

   Usar una lista de conjuntos bien probada

   Parte de una configuración moderna o intermedia generada en lugar de recortar listas a mano.

   # nginx: suites for both RSA and ECDSA certificates, TLS 1.3 enabled
   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:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305;

← Explorar toda la base de datos de errores de firma