No appropriate protocol (protocol is disabled or cipher suites are inappropriate)

Le libellé est le même depuis les mises à jour du JDK 8 jusqu’au JDK 25. Lorsqu’une JVM joue le rôle de serveur, la même situation apparaît sous la forme « No appropriate protocol » quand ses propres protocoles sont tous désactivés.

Java (JSSE) — the client itself has no enabled protocol/cipher combination left

Ce que cela signifie

La JVM n’a même pas pu construire un ClientHello : après le retrait de tous les protocoles et de toutes les suites de chiffrement listés dans jdk.tls.disabledAlgorithms, il ne reste rien de ce que l’application a demandé. En général, le code ou la configuration exige TLS 1.0, TLS 1.1 ou SSLv3, tous désactivés dans les JDK actuels. Rien n’a été envoyé au serveur.

Pourquoi cela se produit

• L’application impose un ancien protocole

  fréquente

  SSLContext.getInstance("TLSv1"), setEnabledProtocols(new String[]{"TLSv1"}) ou https.protocols=TLSv1, écrits il y a des années pour un serveur ancien.

• Une mise à jour du JDK a désactivé ce que l’application utilisait

  fréquente

  TLS 1.0 et 1.1 ont été désactivés par défaut dans les mises à jour de sécurité de 2021 de Java 8, 11 et des versions ultérieures ; les applications qui ne fonctionnaient qu’avec eux cessent de fonctionner après la mise à niveau.

• Une liste explicite de suites de chiffrement ne contient que des suites désactivées

  occasionnelle

  Les configurations qui listent quelques suites TLS_RSA_* ou 3DES ne laissent plus rien d’utilisable une fois celles-ci désactivées.

Comment corriger l’erreur

1. 1.

   Trouver où l’ancien protocole est demandé

   Cherchez des noms de protocoles explicites dans le code et dans les options de la JVM ; -XshowSettings:security:tls affiche ce que le JDK a activé.

   grep -rnE 'SSLContext.getInstance\("(TLSv1|TLSv1\.1|SSL)"\)|setEnabledProtocols|https\.protocols' src/
   java -XshowSettings:security:tls -version 2>&1 | sed -n '/Enabled Protocols/,/Enabled Cipher/p'

2. 2.

   Demander « TLS » et laisser JSSE négocier

   SSLContext.getInstance("TLS") active TLS 1.3 et 1.2 sur les JDK actuels.

   // Let JSSE negotiate the best version (TLS 1.3 / 1.2)
   SSLContext ctx = SSLContext.getInstance("TLS");
   ctx.init(null, null, null);

3. 3.

   En dernier recours : une dérogation ciblée pour un seul point de terminaison ancien

   Si un équipement ne peut pas être mis à niveau, un fichier de propriétés de sécurité distinct peut retirer TLSv1/TLSv1.1 de jdk.tls.disabledAlgorithms pour la JVM qui communique avec lui. Partez de la valeur actuelle complète du JDK, ne modifiez que les entrées de protocole et isolez cette JVM.

   # Last resort for ONE legacy endpoint: take this JDK's own value and drop only TLSv1/TLSv1.1
   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