curl: (35) TLS connect error: error:0A00042E:SSL routines::tlsv1 alert protocol version

Les versions récentes de curl ajoutent « TLS connect error: » devant la raison donnée par OpenSSL. OpenSSL 1.1.1 indique aussi la fonction : « error:1409442E:SSL routines:ssl3_read_bytes:tlsv1 alert protocol version ». Si c’est au contraire le serveur qui choisit une version que le client refuse, le client signale « unsupported protocol ».

curl (OpenSSL backend) — CURLE_SSL_CONNECT_ERROR, TLS alert 70 (protocol_version) received from the server

Ce que cela signifie

Le serveur a envoyé l’alerte TLS 70 (protocol_version) : aucune des versions de TLS proposées par curl ne lui convient. Le préfixe « tlsv1 » est seulement le nom qu’OpenSSL donne aux alertes définies depuis TLS 1.0, et non la version utilisée. En général, le serveur est bloqué sur TLS 1.0/1.1 alors que le client propose 1.2 et 1.3, ou bien un client a été plafonné en dessous du minimum du serveur.

Pourquoi cela se produit

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

  fréquente

  Le ClientHello d’un client moderne ne propose que TLS 1.2 et 1.3. Un serveur dont la version la plus élevée est 1.0 ou 1.1, et qui comprend l’extension supported_versions, n’a rien à choisir et refuse avec protocol_version.

• Le client a été limité à une ancienne version maximale

  occasionnelle

  --tls-max 1.1, --tlsv1.0 assorti d’un plafond, ou une ligne de .curlrc oubliée après le débogage d’un ancien équipement amène curl à proposer des versions qu’un serveur actuel a désactivées.

• Un serveur limité à TLS 1.3 face à un client plafonné à 1.2

  occasionnelle

  Certains points de terminaison durcis n’acceptent que TLS 1.3. Les clients compilés avec d’anciennes bibliothèques, ou forcés à TLS 1.2 par leur configuration, sont refusés avec la même alerte.

Comment corriger l’erreur

1. 1.

   Trouver les versions acceptées par le serveur

   Essayez chaque version avec openssl s_client. Le résultat indique s’il faut corriger le serveur (seuls tls1/tls1_1 sont acceptés) ou le client (il n’a jamais proposé la version acceptée).

   for v in tls1 tls1_1 tls1_2 tls1_3; do
     printf '%s: ' "$v"
     openssl s_client -connect api.example.com:443 -servername api.example.com -"$v" </dev/null >/dev/null 2>&1 \
       && echo accepted || echo refused
   done

2. 2.

   Activer TLS 1.2 et 1.3 sur le serveur

   Mettez à jour la configuration TLS (et, si nécessaire, la bibliothèque TLS ou le système d’exploitation) pour que le serveur accepte TLS 1.2 et 1.3.

   # nginx
   ssl_protocols TLSv1.2 TLSv1.3;
   # HAProxy (global section)
   ssl-default-bind-options ssl-min-ver TLSv1.2

3. 3.

   Supprimer les plafonds de version côté client

   Supprimez --tls-max et les anciennes options de protocole des scripts et du .curlrc ; ne fixez qu’un minimum, pour que curl puisse négocier la version la plus élevée que les deux parties prennent en charge.

   grep -nE 'tls-max|tlsv1|sslv3' ~/.curlrc   # a forgotten cap in the config file
   curl --tlsv1.2 https://api.example.com/        # minimum 1.2, no maximum

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