The server selected protocol version TLS10 is not accepted by client preferences [TLS13, TLS12]

La version choisie (TLS10, TLS11) et la liste entre crochets dépendent du serveur et des protocoles activés dans la JVM. À partir du JDK 21, le texte de l’exception est précédé de « (protocol_version) ». Les serveurs qui refusent au lieu de se replier sur une version inférieure produisent « Received fatal alert: protocol_version ».

Java (JSSE) — the server picked a TLS version the JVM does not allow

Ce que cela signifie

La JVM a proposé TLS 1.3 et 1.2, mais le serveur n’en a pas tenu compte et a répondu en TLS 1.0 (TLS10) ou 1.1 (TLS11), que la JVM n’accepte pas. Java interrompt le handshake de son propre côté. Le serveur est trop ancien pour les clients actuels : tout JDK, navigateur ou curl à jour réagit de la même façon.

Pourquoi cela se produit

• Le serveur n’implémente que TLS 1.0/1.1

  fréquente

  Serveurs hérités, équipements et systèmes embarqués dont la pile TLS est antérieure à TLS 1.2 (ou l’a désactivé).

• Un ancien équipement intermédiaire qui assure la terminaison TLS

  occasionnelle

  Un répartiteur de charge ou un proxy placé devant un serveur moderne assure la terminaison TLS avec une pile obsolète.

• Le JDK a été mis à jour

  occasionnelle

  En 2021, des mises à jour de sécurité ont désactivé TLS 1.0 et 1.1 dans toutes les branches maintenues du JDK ; le même serveur fonctionnait avec des mises à jour plus anciennes.

Comment corriger l’erreur

1. 1.

   Activer TLS 1.2 ou une version ultérieure sur le serveur

   C’est la correction qui profite à tous les clients. TLS 1.0 et 1.1 sont officiellement dépréciés (RFC 8996).

   # Enable TLS 1.2 (and 1.3) on the server or appliance
   ssl_protocols TLSv1.2 TLSv1.3;                 # nginx
   SSLProtocol -all +TLSv1.2 +TLSv1.3             # Apache httpd

2. 2.

   Confirmer l’absence de TLS 1.2

   Si un handshake TLS 1.2 échoue alors que TLS 1.0 réussit, le serveur doit être mis à niveau.

   echo | openssl s_client -connect legacy.example.com:443 -servername legacy.example.com -tls1_2 -brief

3. 3.

   En dernier recours : autoriser TLS 1.0/1.1 dans une seule JVM isolée

   Une surcharge des propriétés de sécurité construite à partir de la valeur propre au JDK réactive les anciennes versions pour cette JVM uniquement. TLS 1.0/1.1 reposent sur des constructions SHA-1 et CBC aux faiblesses connues : limitez donc cette dérogation à un réseau de confiance et supprimez-la dès que l’équipement est remplacé.

   # Last resort for ONE JVM that must reach the legacy server: drop TLSv1/TLSv1.1 from
   # this JDK's own jdk.tls.disabledAlgorithms value and pass it as an override
   v=$(sed -n '/^jdk.tls.disabledAlgorithms=/,/[^\\]$/p' "$JAVA_HOME/conf/security/java.security" | sed 's/\\$//' | tr -d '\n')
   printf '%s\n' "$v" | sed -E 's/ TLSv1(\.1)?,//g' > legacy-tls.security
   java -Djava.security.properties=legacy-tls.security -jar legacy-client.jar

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