Error - trustAnchors parameter must be non-empty
I'm trying to configure my e-mail on Jenkins/Hudson, and I constantly receive the error:
java.security.InvalidAlgorithmParameterException: the trustAnchors parameter must be
non-empty
I've seen a good amount of information online about the error, but I have not gotten any to work. I'm using Sun's JDK on Fedora Linux (not OpenJDK).
Here are a few things I've tried. I tried following the advice from this post, but copying the cacerts from Windows over to my Fedora box hosting Jenkins didn't work. I tried following this guide as I'm trying to configure Gmail as my SMTP server, but it didn't work either. I also tried to download and move those cacert files manually and move them over to my Java folder using a variation of the commands on this guide.
I am open to any suggestions as I'm currently stuck right now. I have gotten it to work from a Windows Hudson server, but I am struggling on Linux.
Solution 1:
This bizarre message means that the trustStore you specified was:
- empty,
- not found, or
- couldn't be opened
- (due to wrong/missing
trustStorePassword, or - file access permissions, for example).
- (due to wrong/missing
See also @AdamPlumb's answer below.
Solution 2:
In Ubuntu 18.04, this error has a different cause (JEP 229, switch from the jks keystore default format to the pkcs12 format, and the Debian cacerts file generation using the default for new files) and workaround:
# 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
Status (2018-08-07), the bug has been fixed in Ubuntu Bionic LTS 18.04.1 and Ubuntu Cosmic 18.10.
🗹 Ubuntu 1770553: [SRU] backport ca-certificates-java from cosmic (20180413ubuntu1)
🗹 Ubuntu 1769013: Please merge ca-certificates-java 20180413 (main) from Debian unstable (main)
🗹 Ubuntu 1739631: Fresh install with JDK 9 can't use the generated PKCS12 cacerts keystore file
🗹 docker-library 145: 9-jdk image has SSL issues
🗹 Debian 894979: ca-certificates-java: does not work with OpenJDK 9, applications fail with InvalidAlgorithmParameterException: the trustAnchors parameter must be non-empty
🗹 JDK-8044445 : JEP 229: Create PKCS12 Keystores by Default
🖺 JEP 229: Create PKCS12 Keystores by Default
If the issue continues after this workaround, you might want to make sure that you're actually running the Java distribution you just fixed.
$ which java
/usr/bin/java
You can set the Java alternatives to 'auto' with:
$ sudo update-java-alternatives -a
update-alternatives: error: no alternatives for mozilla-javaplugin.so
You can double-check the Java version you're executing:
$ 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)
There are alternative workarounds as well, but those have their own side effects which will require extra future maintenance, for no payoff whatsoever.
The next-best workaround is to add the row
javax.net.ssl.trustStorePassword=changeit
to the files
/etc/java-9-openjdk/management/management.properties
/etc/java-11-openjdk/management/management.properties
whichever exists.
The third least problematic workaround is to change the value of
keystore.type=pkcs12
to
keystore.type=jks
in the files
/etc/java-9-openjdk/security/java.security
/etc/java-11-openjdk/security/java.security
whichever exists, and then remove the cacerts file and regenerate it in the manner described on the last row of the workaround script at the top of the post.