Error - Le paramètre trustAnchors doit être non vide
J'essaie de configurer mon courrier électronique sur Jenkins/Hudson et je reçois constamment l'erreur:
Java.security.InvalidAlgorithmParameterException: the trustAnchors parameter must be
non-empty
J'ai vu une bonne quantité d'informations en ligne sur l'erreur, mais je n'ai pas réussi à les utiliser. J'utilise le JDK de Sun sur Fedora Linux (et non sur OpenJDK).
Voici quelques choses que j'ai essayées. J'ai essayé de suivre les conseils de ce post , mais copier les cacerts de Windows sur mon serveur Fedora hébergeant Jenkins ne fonctionnait pas. J'ai essayé de suivre ce guide alors que j'essaie de configurer Gmail en tant que serveur SMTP, mais cela n'a pas fonctionné non plus. J'ai également essayé de télécharger et de déplacer manuellement ces fichiers cacert et de les déplacer dans mon dossier Java en utilisant une variante des commandes de ce guide .
Je suis ouvert à toutes suggestions car je suis actuellement bloqué. Je l'ai obtenu pour fonctionner à partir d'un serveur Windows Hudson, mais je me bats sous Linux.
Ce message étrange signifie que le fichier de clés certifiées était:
- vide,
- non trouvé, ou
- ne peut pas être ouvert (en raison d’autorisations d’accès par exemple).
Voir aussi la réponse de/@ AdamPlumb ci-dessous .
Dans Ubuntu 18.04, cette erreur a une cause différente (JEP 229, passage du format par défaut du magasin jks au format pkcs12 et la génération de fichier Debian cacerts utilisant le fichier par défaut pour les nouveaux fichiers) et solution de contournement :
# Ubuntu 18.04 and various Docker images such as openjdk:9-jdk throw exceptions when
# Java applications use SSL and HTTPS, because Java 9 changed a file format, if you
# create that file from scratch, like Debian / Ubuntu do.
#
# Before applying, run your application with the Java command line parameter
# Java -Djavax.net.ssl.trustStorePassword=changeit ...
# to verify that this workaround is relevant to your particular issue.
#
# The parameter by itself can be used as a workaround, as well.
# 0. First make yourself root with 'Sudo bash'.
# 1. Save an empty JKS file with the default 'changeit' password for Java cacerts.
# Use 'printf' instead of 'echo' for Dockerfile RUN compatibility.
/usr/bin/printf '\xfe\xed\xfe\xed\x00\x00\x00\x02\x00\x00\x00\x00\xe2\x68\x6e\x45\xfb\x43\xdf\xa4\xd9\x92\xdd\x41\xce\xb6\xb2\x1c\x63\x30\xd7\x92' > /etc/ssl/certs/Java/cacerts
# 2. Re-add all the CA certs into the previously empty file.
/var/lib/dpkg/info/ca-certificates-Java.postinst configure
https://git.mikael.io/mikaelhg/broken-docker-jdk9-cacerts
Status (2018-08-07), le bogue a été corrigé dans Ubuntu Bionic LTS 18.04.1 et Ubuntu Cosmic 18.10.
???? Ubuntu 1770553: [SRU] Backport ca-certificats-Java de cosmic (20180413ubuntu1)
???? docker-library 145: des problèmes de SSL ont été détectés sur une image 9
???? JDK-8044445: JEP 229: Créer des magasins de clés PKCS12 par défaut
???? JEP 229: Créer des magasins de clés PKCS12 par défaut
Si le problème persiste après cette solution de contournement, vous voudrez peut-être vous assurer que vous exécutez bien la distribution Java que vous venez de corriger.
$ which Java
/usr/bin/Java
Vous pouvez définir les alternatives Java sur 'auto' avec:
$ Sudo update-Java-alternatives -a
update-alternatives: error: no alternatives for mozilla-javaplugin.so
Vous pouvez vérifier la version de Java que vous exécutez:
$ Java --version
openjdk 10.0.1 2018-04-17
OpenJDK Runtime Environment (build 10.0.1+10-Ubuntu-3ubuntu1)
OpenJDK 64-Bit Server VM (build 10.0.1+10-Ubuntu-3ubuntu1, mixed mode)
Il existe également des solutions de rechange, mais celles-ci ont leurs propres effets secondaires, qui nécessiteront un entretien supplémentaire à l'avenir, sans aucun bénéfice.
La meilleure solution consiste à ajouter la ligne.
javax.net.ssl.trustStorePassword=changeit
aux fichiers
/etc/Java-9-openjdk/management/management.properties
/etc/Java-11-openjdk/management/management.properties
selon le cas.
La troisième solution de contournement la moins problématique consiste à modifier la valeur de
keystore.type=pkcs12
à
keystore.type=jks
dans les dossiers
/etc/Java-9-openjdk/security/Java.security
/etc/Java-11-openjdk/security/Java.security
selon le cas, puis supprimez le fichier cacerts et régénérez-le de la manière décrite précédemment.
Cela a résolu le problème pour moi sur Ubuntu:
Sudo /var/lib/dpkg/info/ca-certificates-Java.postinst configure
(trouvé ici: https://bugs.launchpad.net/ubuntu/+source/ca-certificates-Java/+bug/1396760 )
ca-certificates-Java n'est pas une dépendance dans le JDK/JRE Oracle, elle doit donc être explicitement installée.
Sur Ubuntu 18.04, la cause première est un conflit entre openjdk-11-jdk (valeur par défaut) et d'autres packages qui en dépendent. Il a déjà été corrigé dans Debian et sera prochainement inclus dans Ubuntu. En attendant, la solution la plus simple consiste à rétrograder Java en version 8. Les autres solutions utilisant ca-certificates-Java sont beaucoup plus compliquées.
Commencez par supprimer les paquets en conflit:
Sudo apt-get remove --purge openjdk* Java-common default-jdk
Sudo apt-get autoremove --purge
Vérifiez si vous avez correctement supprimé tous les packages associés en:
Sudo update-alternatives --config Java
Le système vous demandera il n'y a pas de Java disponible pour configurer , sinon cette solution de contournement échoue .
Puis réinstallez les paquets requis:
Sudo apt-get install openjdk-8-jdk
J'ai rencontré cette solution à partir de l'article de blog - Résolution du problème de trustAnchors lors de l'exécution d'OpenJDK 7 sous OS X:
Résolution du problème de trustAnchors lors de l'exécution d'OpenJDK 7 sous OS X. Si vous exécutez OpenJDK 7 sous OS X et que vous avez vu cette exception:
Unexpected error: Java.security.InvalidAlgorithmParameterException: the trustAnchors
parameter must be non-empty
Il y a une solution simple. Liez simplement dans le même fichier cacerts que le JDK 1.6 d’Apple utilise:
cd $(/usr/libexec/Java_home -v 1.7)/jre/lib/security
ln -fsh /System/Library/Java/Support/CoreDeploy.bundle/Contents/Home/lib/security/cacerts
Vous devez le faire pour chaque version d'OpenJDK que vous avez installée. Il suffit de changer -v 1.7 à la version que vous souhaitez corriger. Exécutez /usr/libexec/Java_home -V pour voir tous les JRE et JDK que vous avez installés.
Peut-être que les gars d'OpenJDK pourraient ajouter ceci à leurs scripts d'installation.
EJP a essentiellement répondu à la question (et je me rends compte que sa réponse est acceptée), mais je viens de m'occuper de ce cas d'Edge et j'ai voulu immortaliser ma solution.
J'ai eu l'erreur InvalidAlgorithmParameterException sur un serveur Jira hébergé que j'avais précédemment configuré pour un accès uniquement SSL. Le problème était que j'avais configuré mon fichier de clés au format PKCS # 12, mais que mon fichier de clés certifiées était au format JKS.
Dans mon cas, j'avais édité mon fichier server.xml pour spécifier le keystoreType à PKCS, mais je n'ai pas spécifié le truststoreType. En spécifiant explicitement le truststoreType en tant que JKS, je l'ai résolu.
Dans Ubuntu 12.10 (Quantal Quetzal) ou ultérieur, les certificats sont conservés dans le package ca-certificates-Java . Utiliser -Djavax.net.ssl.trustStore=/etc/ssl/certs/Java/cacerts les récupèrera quel que soit le JDK utilisé.
J'ai rencontré ce problème sous OS X avec JDK 1.7 après la mise à niveau vers OS X v10.9 (Mavericks). Le correctif qui a fonctionné pour moi était simplement de réinstaller la version Apple de Java, disponible à l’adresse http://support.Apple.com/kb/DL1572 .
Iran
Sudo update-ca-certificates -f
pour créer un fichier de certificat, puis:
Sudo /var/lib/dpkg/info/ca-certificates-Java.postinst configure
J'étais de retour dans les affaires, merci les gars. C'est dommage que ce ne soit pas inclus dans l'installation, mais j'y suis arrivé à la fin.
J'ai eu beaucoup de problèmes de sécurité après la mise à niveau vers OS X v10.9 (Mavericks):
- Problème SSL avec Amazon AWS
- Peer non authentifié avec Maven et Eclipse
- Le paramètre
trustAnchorsdoit être non vide
J'ai appliqué cette mise à jour Java et résolu tous mes problèmes: http://support.Apple.com/kb/DL1572?viewlocale=en_US
Pour moi, cela a été causé par l’absence d’un dieu de confiance dans le magasin de clés de confiance.
Pour tester, utilisez:
keytool -list -keystore keystore.jks
Ça me donne:
Keystore type: JKS
Keystore provider: Sun
Your keystore contains 1 entry
cert-alias, 31-Jul-2017, PrivateKeyEntry
Même si mon PrivateKeyEntry contient un CA, il devait être importé séparément:
keytool -import -alias root-ca1 -file rootca.crt -keystore keystore.jks
Il importe le certificat, puis re-exécute keytool -list -keystore keystore.jks donne maintenant:
Your keystore contains 2 entries
cert-alias, 31-Jul-2017, PrivateKeyEntry,
Certificate fingerprint (SHA1):
<fingerprint>
root-ca1, 04-Aug-2017, trustedCertEntry,
Certificate fingerprint (SHA1):
<fingerprint>
Maintenant, il a un TrustedCertEntry, et Tomcat va démarrer avec succès.
L'erreur indique que le système ne peut pas trouver le fichier de clés certifiées dans le chemin fourni avec le paramètre javax.net.ssl.trustStore.
Sous Windows, j'ai copié le fichier cacerts de jre/lib/security dans le répertoire d'installation d'Eclipse (au même endroit que le fichier Eclipse.ini) et ajouté les paramètres suivants dans Eclipse.ini:
-Djavax.net.ssl.trustStore=cacerts
-Djavax.net.ssl.trustStorePassword=changeit
-Djavax.net.ssl.trustStoreType=JKS
J'ai eu quelques problèmes avec le chemin d'accès aux cacerts (la variable d'environnement% Java_home% est en quelque sorte écrasée), j'ai donc utilisé cette solution triviale.
L'idée est de fournir un chemin d'accès valide au fichier de clés certifiées. Idéalement, il s'agirait d'un fichier relatif. Vous pouvez également utiliser un chemin absolu.
Pour vous assurer que le type de magasin est JKS, vous devez exécuter la commande suivante:
keytool -list -keystore cacerts
Keystore type: JKS
Keystore provider: Sun
Je m'attendais à des choses comme celle-ci, à savoir que j'utilise une autre machine virtuelle Java dans Talend Open Studio (le support n'existe actuellement que jusqu'au JDK 1.7). J'utilise 8 à des fins de sécurité ... de toute façon
Mettez à jour votre magasin de certificats:
Sudo update-ca-certificates -f
puis
ajouter une nouvelle valeur dans vos paramètres d'initialisation
Sudo gedit $(path to your architecture specific ini i.e. TOS_DI...ini) Djavax.net.ssl.trustStore=/etc/ssl/certs/Java/cacerts
Pour moi, la deuxième entrée a fonctionné. Je pense que, selon la version de Talend Open Studio/TEnt + JVM, le nom du paramètre est différent, mais le même fichier de clés est recherché.
Supprimer le package ca-certificates-Java et l'installer à nouveau a fonctionné pour moi ( Ubuntu MATE 17.10 (Artful Aardvark)).
Sudo dpkg --purge --force-depends ca-certificates-Java
Sudo apt-get install ca-certificates-Java
Merci, jdstrand: Comment 1 pour le bogue 983302, Re: ca-certificates-Java ne parvient pas à installer les cacerts Java sur Oneiric Ocelot.
Si vous rencontrez ce problème sous Ubuntu avec JDK9 et Maven, vous pouvez ajouter cette option JVM - vérifiez d’abord si le chemin existe:
-Djavax.net.ssl.trustStore=/etc/ssl/certs/Java/cacerts
Si le fichier est manquant, essayez d'installer ca-certificates-Java comme quelqu'un l'a noté:
Sudo apt install ca-certificates-Java
J'avais ce problème lorsque j'essayais d'utiliser Maven 3, après la mise à niveau de Ubuntu 16.04 LTS (Xenial Xerus) vers Ubuntu 18.04 LTS (Bionic Beaver).
L'examen de/usr/lib/jvm/Java-8-Oracle/jre/lib/security a montré que mon fichier cacerts était un lien symbolique pointant vers /etc/ssl/certs/Java/cacerts.
J'avais aussi un fichier suspect nommé cacerts.original.
J'ai renommé cacerts.original en cacerts et le problème a été résolu.
J'ai eu ce message d'erreur sur Java 9.0.1 sur Linux. Cela était dû à un bogue connu du JDK, où le fichier cacerts est vide dans le paquet binaire .tar.gz (téléchargé depuis http://jdk.Java.net/9/ ).
Reportez-vous au paragraphe "Problèmes connus" de Notes de mise à jour du JDK 9.0.1 pour indiquer que "TLS ne fonctionne pas par défaut sous OpenJDK 9".
Sur Debian/Ubuntu (et probablement d’autres dérivés), une solution simple consiste à remplacer le fichier cacerts par celui du paquet "ca-certificates-Java":
Sudo apt install ca-certificates-Java
cp /etc/ssl/certs/Java/cacerts /path/to/jdk-9.0.1/lib/security/cacerts
Sous Red Hat Linux/CentOS, vous pouvez faire de même à partir du package "ca-certificates":
Sudo yum install ca-certificates
cp /etc/pki/Java/cacerts /path/to/jdk-9.0.1/lib/security/cacerts
Vous pouvez également rencontrer cette erreur après la mise à niveau vers Spring Boot 1.4.1 (ou une version plus récente) car elle entraîne Tomcat 8.5.5 dans le cadre de ses dépendances.
Le problème est dû à la façon dont Tomcat gère le magasin de données de confiance. Si vous avez spécifié l'emplacement de votre magasin de clés de confiance comme identique à celui de votre magasin de clés dans la configuration de démarrage Spring, vous recevrez probablement le message trustAnchors parameter must be non-empty lors du démarrage de l'application.
server.ssl.key-store=classpath:server.jks
server.ssl.trust-store=classpath:server.jks
Supprimez simplement la configuration server.ssl.trust-store sauf si vous savez que vous en avez besoin. Dans ce cas, consultez les liens ci-dessous.
Les problèmes suivants contiennent plus de détails sur le problème:
Je l'ai également rencontré sous OS X après la mise à jour de OS X v10.9 (Mavericks), lorsque l'ancien Java 6 était utilisé et que j'essayais d'accéder à une URL HTTPS. Le correctif était l'inverse de Peter Kriens; J'avais besoin de copier la cacerts de l'espace 1.7 vers l'emplacement lié par la version 1.6:
(as root)
umask 022
mkdir -p /System/Library/Java/Support/CoreDeploy.bundle/Contents/Home/lib/security
cp $(/usr/libexec/Java_home -v 1.7)/jre/lib/security/cacerts \
/System/Library/Java/Support/CoreDeploy.bundle/Contents/Home/lib/security
Dans mon cas, le fichier JKS utilisé dans l'application cliente était corrompu. J'ai créé un nouveau et importé les certificats SSL du serveur de destination. Ensuite, j'ai utilisé le nouveau fichier JKS de l'application cliente en tant que magasin de données de confiance, par exemple
System.setProperty("javax.net.ssl.trustStore",path_to_your_cacerts_file);
Source: Java SSL et magasin de clés de certificats
J'utilise l'outil (KeyStore Explorer) pour créer le nouveau JKS. Vous pouvez le télécharger à partir de ce lien, KeyStore Explorer .
System.setProperty("javax.net.ssl.trustStore", "C:\\Users\\user-id\\Desktop\\Tomcat\\cacerts");
System.setProperty("javax.net.ssl.trustStorePassword", "passwd");
Vous devez ajouter les deux lignes ci-dessus à votre code. Il n'est pas en mesure de trouver le fichier de clés certifiées.
J'ai rencontré ce problème avec le SDK Android SDKMANAGER. Pour moi cette solution a fonctionné:
- Accédez à/usr/lib/jvm/Java-8-Oracle/jre/lib/security /
- Remplacer "cacert" par "cacert.original"
Le fichier 'cacert' était minuscule (22B). J'ai installé Oracle-Java8-Installer depuis ppa: webupd8team/Java (selon ce manuel: https://docs.nativescript.org/start/ns-setup-linux )
Aucune des solutions que j'ai trouvées sur Internet n'a fonctionné, mais une version modifiée de la réponse de Peter Kriens semble faire l'affaire.
Commencez par rechercher votre dossier Java en exécutant /usr/libexec/Java_home. Pour moi, c'était la version 1.6.0.jdk. Ensuite, allez dans son sous-dossier lib/security (pour moi /Library/Java/JavaVirtualMachines/1.6.0.jdk/Contents/Home/lib/security).
Supprimez ensuite le fichier cacerts s'il en existe déjà un et recherchez-le sur le système avec Sudo find / -name "cacerts". Il a trouvé plusieurs éléments pour moi, dans des versions de Xcode ou d’autres applications que j’avais installées, mais aussi à /Library/Internet Plug-Ins/JavaAppletPlugin.plugin/Contents/Home/lib/security/cacerts que j’ai choisi.
Utilisez ce fichier et faites-lui un lien symbolique (dans le dossier Java d’avant), Sudo ln -fsh "/Library/Internet Plug-Ins/JavaAppletPlugin.plugin/Contents/Home/lib/security/cacerts", et cela devrait fonctionner.
J'ai les deux - Java depuis le téléchargement 2017-001 d'Apple ( https://support.Apple.com/kb/dl1572 - Je suppose que c'est de là que proviennent les bons certificats) et celui d'Oracle installé sur Mac OS X v10.12 (Sierra).
Dans windows10 et openjdk a été provoqué par avoir un fichier cacerts vide distribué avec le binaire. Le bogue est expliqué ici: https://github.com/AdoptOpenJDK/openjdk-build/issues/555
Vous pouvez copier sur adoptOpenJdk8\jre\lib\security\cacerts le fichier depuis une ancienne installation telle que c:\Program Files\Java\jdk1.8.0_192\jre\lib\security\cacerts.
La version buggy AdoptOpenJDK est https://github.com/AdoptOpenJDK/openjdk8-releases/releases/download/jdk8u172-b11/OpenJDK8_x64_Win_jdk8u172-b11.Zip
J'ai fait face à ce problème lors de l'exécution d'une suite particulière d'Android pour tester sur Ubuntu 14.04 (Trusty Tahr). Deux choses ont fonctionné pour moi, comme suggéré par shaheen:
Sudo update-ca-certificates -f
Sudo /var/lib/dpkg/info/ca-certificates-Java.postinst configure
Pour mémoire, aucune des réponses n’a fonctionné pour moi. Ma génération Gradle a commencé à échouer mystérieusement avec cette erreur, incapable d'extraire HEAD de Mavencentral pour un fichier POM particulier.
Il s’est avéré que j’avais Java_HOME défini dans ma version personnelle d’OpenJDK, que j’avais construite pour le débogage d’un problème javac. Le rétablir dans le JDK installé sur mon système a corrigé le problème.
Une autre raison à cela est que c'est en fait une erreur valide. Certains points d'accès Wi-Fi néfastes bousilleront certificats et attaque de l'homme au milieu vous devez faire qui sait quoi (fuyez!).
Certains grands employeurs vont faire la même chose, en particulier dans les zones réseau sensibles, afin de pouvoir surveiller tout le trafic crypté (ce qui n'est pas génial du point de vue de l'utilisateur final, mais il peut y avoir de bonnes raisons à cela).
Sur Ubuntu:
Sudo apt install ca-certificates-Java
ou
Sudo apt-get install ca-certificates-Java
trié pour moi.
J'ai eu cette erreur lors de l'utilisation d'un fichier de clés certifiées exporté à l'aide d'un outil clé IBM Websphere JDK au format # PKCS12 et lors d'une tentative de communication via SSL à l'aide de ce fichier sur un JRE Oracle.
Ma solution consistait à s'exécuter sur un environnement JRE IBM ou à convertir le fichier de clés certifiées en JKS à l'aide d'un outil clé IBM Websphere. J'ai donc pu l'exécuter dans un environnement JRE Oracle.
J'ai rencontré le problème lors de l'importation d'un projet Gradle dans IntelliJ IDEA 14 . Une solution utilisait une copie locale de Gradle au lieu d'un wrapper du répertoire du projet.
En fait, vous devez seulement exécuter:
Sudo chmod +x ./gradlew(your script)
sur Ubuntu 14.04 avec openjdk 11 de ppa: openjdk-r/ppa cela a fonctionné pour moi:
dans Java.security, changez le type de magasin de clés en
keystore.type=jks
puis:
Sudo dpkg --purge --force-depends ca-certificates-Java
Sudo apt-get install ca-certificates-Java
lorsque vous vérifiez si cela a fonctionné, assurez-vous de ne pas utiliser de démon avec l'ancien Java toujours en cours d'exécution (par exemple, l'option --no-daemon pour gradle)
ce bogue décrit bien tout et vous aidera à comprendre ce qui se passe https://bugs.launchpad.net/ubuntu/+source/ca-certificates-Java/+bug/1739631
Sous Red Hat Linux, ce problème a été résolu en important les certificats dans /etc/pki/Java/cacerts.
Sur Ubuntu 18.04, je devais utiliser OpenJDK 1.7 pour la maintenance d’un projet ancien. J'ai téléchargé le package binaire. Mais quand j'ai exécuté mon script dessus, j'ai eu la même erreur.
La solution consistait à supprimer le fichier cacerts du JDK téléchargé dans le dossier jre/lib/security, puis à le créer en tant que lien symbolique vers le fichier systems cacerts dans /etc/ssl/certs/Java/:
Sudo ln -s /etc/ssl/certs/Java/cacerts /path/to/downloaded/Java/jre/lib/security/cacerts
J'ai la même erreur lors de l'envoi d'e-mails, mais PAS TOUJOURS. Dans mon cas, j'ai changé une ligne de code pour obtenir à chaque fois un nouveau Session object:
MimeMessage message = new MimeMessage(Session.getDefaultInstance(props, authenticator));
à
MimeMessage message = new MimeMessage(Session.getInstance(props, authenticator));
Depuis lors, l'envoi d'e-mails fonctionne à chaque fois.
L'erreur que j'ai eu:
javax.mail.MessagingException: Impossible de convertir le socket en TLS;
l'exception imbriquée est la suivante: javax.net.ssl.SSLException:
Java.lang.RuntimeException: erreur inattendue:
Java.security.InvalidAlgorithmParameterException: les trustAnchors
paramètre doit être non vide à
com.Sun.mail.smtp.SMTPTransport.startTLS (SMTPTransport.Java:1907) à l'adresse
com.Sun.mail.smtp.SMTPTransport.protocolConnect (SMTPTransport.Java:666)
à javax.mail.Service.connect (Service.Java:317) à
javax.mail.Service.connect (Service.Java:176) sur
javax.mail.Service.connect (Service.Java:125) sur
javax.mail.Transport.send0 (Transport.Java:194) sur
javax.mail.Transport.send (Transport.Java:124)
J'ai trouvé encore une autre raison de cette erreur, qui n'est pas liée à Ubuntu.
J'ai essayé de configurer TLS mutuel dans une application Spring Boot 2 et je me suis heurté à ce problème après avoir utilisé un fichier de clés certifiées qui ne contenait qu'une entrée de clé privée et aucune entrée de certificat approuvé.
Ceci est ma configuration Spring Boot TLS
server.port=8443
server.ssl.key-alias=oba-tls
server.ssl.key-password=mypw
server.ssl.key-store-password=mypw
server.ssl.key-store=classpath:keys/tls-keystore.pfx
server.ssl.key-store-type=PKCS12
server.ssl.enabled=true
server.ssl.client-auth=need
server.ssl.trust-store=classpath:keys/truststore.pfx
server.ssl.trust-store-password=mypw
server.ssl.trust-store-type=PKCS12
server.ssl.ciphers=ECDHE-RSA-AES128-GCM-SHA256,ECDHE-RSA-AES256-SHA384
server.ssl.protocol=TLS
server.ssl.enabled-protocols=TLSv1.2
Pour générer truststore.pfx, je devais utiliser les commandes suivantes pour que cela fonctionne.
openssl req -newkey rsa:2048 -nodes -keyout private.key -x509 -out cert.crt
keytool -importcert -alias oba-trust -file cert.crt -keystore truststore.jks
keytool -importkeystore -srckeystore truststore.jks -destkeystore truststore.pfx -srcstoretype JKS - deststoretype PKCS12 -deststorepass yourpassword
J'ai eu la même erreur, et le problème n'était pas dans la configuration du JDK, mais dans un simple chemin erroné vers le fichier jks dans le fichier application.properties sous le paramètre 'trust-store:', vérifiez si le chemin est correct.
Pour moi, cela a été résolu simplement en mettant à jour un plugin Jenkins, "Email Extension Plugin", vers la dernière version (2.61).
Ces deux plugins sont responsables de la configuration du courrier électronique dans Jenkins:
- Extension Email
- Modèle d'extension de courrier électronique