curl: (35) TLS connect error: error:0A000102:SSL routines::unsupported protocol

Les versions récentes de curl (ici 8.14.1) ajoutent « TLS connect error: » devant la raison donnée par OpenSSL. OpenSSL 1.1.1 indique le nom de la fonction : « error:1425F102:SSL routines:ssl_choose_client_version:unsupported protocol ». Lorsque c’est le serveur qui refuse, le client voit à la place « tlsv1 alert protocol version ».

curl (OpenSSL backend) — CURLE_SSL_CONNECT_ERROR, SSL_R_UNSUPPORTED_PROTOCOL

Ce que cela signifie

Le serveur a répondu au ClientHello en choisissant une version du protocole que la bibliothèque TLS de curl n’a pas le droit d’utiliser, généralement TLS 1.0 ou 1.1. Le client abandonne alors de son côté. Le chemin réseau et le certificat n’y sont pour rien : les deux extrémités n’ont tout simplement aucune version de TLS en commun.

Pourquoi cela se produit

• Le serveur ne prend en charge que TLS 1.0 ou 1.1

  fréquente

  Les anciennes installations de Windows Server/IIS, les applications de l’époque de Java 6/7 et les répartiteurs de charge non maintenus négocient encore TLS 1.0. La RFC 8996 a rendu TLS 1.0 et 1.1 obsolètes en 2021, et les clients actuels ne les proposent plus.

• La politique système du client impose au minimum TLS 1.2

  fréquente

  Les politiques cryptographiques de Debian, d’Ubuntu (depuis 20.04) et de RHEL 8+, ainsi que le niveau de sécurité par défaut d’OpenSSL 3, rejettent tous TLS 1.0/1.1. Le même serveur peut encore fonctionner depuis une machine plus ancienne, si bien que l’échec semble propre à l’environnement.

• Interfaces d’administration et équipements embarqués

  occasionnelle

  Les interfaces web des imprimantes et des onduleurs, les anciens firmwares IPMI/iLO, les passerelles SCADA et les équipements similaires ne peuvent souvent pas être mis à niveau au-delà de TLS 1.0.

Comment corriger l’erreur

1. 1.

   Confirmer les versions acceptées par le serveur

   Essayez chaque version explicitement. Si seuls tls1 ou tls1_1 aboutissent, le serveur doit être mis à niveau ; si tls1_2 aboutit aussi, cherchez une option du client qui plafonne la version maximale.

   # Which versions does the server accept? (each line succeeds or fails on its own)
   for v in tls1 tls1_1 tls1_2 tls1_3; do
     printf '%s: ' "$v"
     openssl s_client -connect legacy.example.com:443 -"$v" </dev/null >/dev/null 2>&1 && echo ok || echo no
   done

2. 2.

   Activer TLS 1.2 et 1.3 sur le serveur

   Activez TLS 1.2 (et 1.3 là où la pile le prend en charge) et désactivez 1.0/1.1. C’est la seule correction qui aide aussi les navigateurs, les applications mobiles et les autres clients d’API.

   # nginx
   ssl_protocols TLSv1.2 TLSv1.3;
   # Apache httpd
   SSLProtocol -all +TLSv1.2 +TLSv1.3
   # IIS / Windows Server: enable TLS 1.2 under
   # HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.2\Server

3. 3.

   En dernier recours : autoriser TLS 1.0 pour un seul appel vers un équipement impossible à mettre à niveau

   Réactivez l’ancienne version uniquement pour la commande précise qui communique avec l’ancien équipement, jamais pour tout le système. TLS 1.0 repose sur des constructions SHA-1 et CBC exposées à des attaques connues ; cantonnez ce trafic à un réseau d’administration isolé.

   # Last resort for a device you cannot upgrade: allow TLS 1.0 for this one call only.
   # OpenSSL 3 also needs security level 0 for the SHA-1 based handshake of TLS 1.0/1.1.
   curl --tlsv1.0 --ciphers 'DEFAULT:@SECLEVEL=0' https://legacy-device.example.internal/

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