SSL routines:tls_post_process_client_hello:no shared cipher

openssl s_server (OpenSSL 3.x) consigne « error:0A0000C1:SSL routines:tls_post_process_client_hello:no shared cipher:<source> » ; nginx consigne « SSL_do_handshake() failed (SSL: error:0A0000C1:SSL routines::no shared cipher) while SSL handshaking » au niveau info, si bien que le message est invisible avec le niveau d’error_log par défaut. OpenSSL 1.1.1 utilisait le code 1417A0C1.

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

Ce que cela signifie

C’est le point de vue du serveur sur un handshake qui a échoué : aucune des suites de chiffrement du ClientHello du client n’est à la fois activée sur le serveur et utilisable avec la clé de son certificat. Le serveur envoie alors handshake_failure (alerte 40) au client. Ce message apparaît dans les journaux du serveur, pas dans la sortie du client.

Pourquoi cela se produit

• La liste de chiffrements ne correspond pas au type de clé du certificat

  fréquente

  Un certificat ECDSA avec uniquement des suites ECDHE-RSA-* activées (ou un certificat RSA avec uniquement des suites ECDHE-ECDSA-*) ne laisse aucune suite TLS 1.2 utilisable : tous les clients TLS 1.2 échouent donc.

• Une liste de chiffrements élaguée à la main exclut de vrais clients

  fréquente

  Les listes réduites à une ou deux suites, ou à CHACHA20 seul, excluent les clients (et les outils de surveillance) qui préfèrent d’autres suites modernes.

• Clients très anciens

  occasionnelle

  Les clients limités aux suites à échange de clés RSA, aux suites CBC ou aux suites 3DES (anciennes versions de Java, systèmes embarqués) ne peuvent pas se connecter à une configuration moderne ; décidez en connaissance de cause s’il faut les prendre en charge.

Comment corriger l’erreur

1. 1.

   Confronter la clé du certificat aux suites

   Les suites ECDHE-ECDSA-* nécessitent un certificat ECDSA, les suites ECDHE-RSA-* un certificat RSA ; les serveurs qui disposent des deux certificats peuvent lister les deux familles.

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

   Lister les suites que le serveur accepte réellement

   Énumérez-les depuis l’extérieur et comparez-les avec les clients que vous devez prendre en charge.

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

3. 3.

   Utiliser une liste de suites éprouvée

   Partez d’une configuration générée, moderne ou intermédiaire, plutôt que d’élaguer les listes à la main.

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

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