Dans Ubuntu 18.04 , cette erreur a une cause différente (JEP 229, passer du jksformat par défaut du magasin de pkcs12clés au format, et la génération de fichiers Debian cacerts en utilisant la valeur par défaut pour les nouveaux fichiers) et solution :
# 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
État (2018-08-07) , le bogue a été corrigé dans Ubuntu Bionic LTS 18.04.1 et Ubuntu Cosmic 18.10.
Unt Ubuntu 1770553: [SRU] backport ca-certificats-java de cosmic (20180413ubuntu1)
🗹 Ubuntu 1769013: veuillez fusionner ca-certificats-java 20180413 (principal) de Debian unstable (principal)
🗹 Ubuntu 1739631: Une nouvelle installation avec JDK 9 ne peut pas utiliser le fichier de clés de cacerts PKCS12 généré
🗹 Docker -Library 145: l'image 9-jdk a des problèmes SSL
🗹 Debian 894979: ca-certificats-java: ne fonctionne pas avec OpenJDK 9, les applications échouent avec InvalidAlgorithmParameterException: le paramètre trustAnchors doit être non vide
🗹 JDK-8044445: JEP 229: création de 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 pouvez vous assurer que vous exécutez réellement 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 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 une maintenance future supplémentaire, sans aucun avantage.
La solution de contournement suivante 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 ce qui existe.
La troisième solution de contournement la moins problématique consiste à modifier la valeur de
keystore.type=pkcs12
à
keystore.type=jks
dans les fichiers
/etc/java-9-openjdk/security/java.security
/etc/java-11-openjdk/security/java.security
celui qui existe, puis supprimez le cacertsfichier et régénérez-le de la manière décrite dans la dernière ligne du script de contournement en haut de la publication.