Error - trustAnchors parameter must be non-empty

Viewed 838292

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.

45 Answers

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.

On Ubuntu 18.04 the root cause is a conflict between openjdk-11-jdk (which is default) and other packages depending on it. It has already been fixed in Debian and will be included in Ubuntu shortly. Meanwhile the simplest workaround is to demote your java to version 8. Other solutions employing ca-certificates-java are much more complicated.

First remove conflicting packages:

sudo apt-get remove --purge openjdk* java-common default-jdk
sudo apt-get autoremove --purge

Check whether you successfully removed all related packages by:

sudo update-alternatives --config java

The system shall prompt you there is no Java available to config, otherwise this workaround fails.

Then reinstall required packages:

sudo apt-get install openjdk-8-jdk

Removing the ca-certificates-java package and installing it again worked for me (Ubuntu MATE 17.10 (Artful Aardvark)).

sudo dpkg --purge --force-depends ca-certificates-java

sudo apt-get install ca-certificates-java

Thank you, jdstrand: Comment 1 for bug 983302, Re: ca-certificates-java fails to install Java cacerts on Oneiric Ocelot.

If you experience this on Ubuntu with JDK9 and Maven, you can add this JVM option - first check if the path exists:

-Djavax.net.ssl.trustStore=/etc/ssl/certs/java/cacerts

If the file is missing, try to install the ca-certificates-java as someone noted:

sudo apt install ca-certificates-java

I had this error message on Java 9.0.1 on Linux. It was due to a known bug of the JDK, where the cacerts file is empty in the .tar.gz binary package (downloaded from http://jdk.java.net/9/).

See the "known issues" paragraph of JDK 9.0.1 Release Notes, saying "TLS does not work by default on OpenJDK 9".

On Debian/Ubuntu (and probably other derivaties), a simple workaround is to replace the cacerts file with the one from the "ca-certificates-java" package:

sudo apt install ca-certificates-java
cp /etc/ssl/certs/java/cacerts /path/to/jdk-9.0.1/lib/security/cacerts

On Red Hat Linux/CentOS, you can do the same from the "ca-certificates" package:

sudo yum install ca-certificates
cp /etc/pki/java/cacerts /path/to/jdk-9.0.1/lib/security/cacerts

I'm a fan of portability, so I don't install java, just download the tar.gz and export some values in the path and everything works.

I fought with this issue and no solution (install or update operative systems certs) worked for me.

Error in my case was: empty cacerts inside my jdk.

I don't know why, but my jdk.tar.gz had an empty cacerts file

/../some_openjdk/jre/lib/security/cacerts size: 32 bytes

Downloaded from:

Fix

After several attempts I found a correct jdk.tar.gz with a cacerts file with size 101 KB

I downloaded this open jdk from https://github.com/AdoptOpenJDK/openjdk8-upstream-binaries

I found this url in this Dockerfile :

I had this issue when trying to use Maven 3, after upgrading from Ubuntu 16.04 LTS (Xenial Xerus) to Ubuntu 18.04 LTS (Bionic Beaver).

Checking /usr/lib/jvm/java-8-oracle/jre/lib/security showed that my cacerts file was a symbolic link pointing to /etc/ssl/certs/java/cacerts.

I also had a file suspiciously named cacerts.original.

I renamed cacerts.original to cacerts, and that fixed the issue.

I also encountered this on OS X after updating OS X v10.9 (Mavericks), when the old Java 6 was being used and tried to access an HTTPS URL. The fix was the inverse of Peter Kriens; I needed to copy the cacerts from the 1.7 space to the location linked by the 1.6 version:

(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

I encountered this problem with the Android SDK sdkmanager. For me this solution worked:

  1. Go to /usr/lib/jvm/java-8-oracle/jre/lib/security/
  2. Replace cacert with cacert.original

The cacert file was a tiny one (22B). I have installed oracle-java8-installer from ppa:webupd8team/java (according to this manual: https://docs.nativescript.org/start/ns-setup-linux).

Marquis of Lorne's answer is accurate, I'm adding some info for debugging purposes:

To debug this issue (I wrote about it with more details in here) and understand what truststore is being used (or trying to use) you can add the property javax.net.debug=all and then filter the logs about truststore. You can also play with the property javax.net.ssl.trustStore to specify a specific truststore. For example :


    java -Djavax.net.debug=all -Djavax.net.ssl.trustStore=/Another/path/to/cacerts -jar test_get_https-0.0.1-SNAPSHOT-jar-with-dependencies.jar https://www.calca.com.py 2>&1| grep -i truststore

On Ubuntu 18.04 I needed to use OpenJDK 1.7 for the maintenance of an old project. I downloaded the binary package. But when I executed my script on it I got the same error.

The solution was to remove the cacerts file of the downloaded JDK in the jre/lib/security folder and then to create it as symlink to the systems cacerts file in /etc/ssl/certs/java/:

sudo ln -s /etc/ssl/certs/java/cacerts /path/to/downloaded/java/jre/lib/security/cacerts

Slim chance this will help anyone but....for anyone running Java 8 from a Docker Image on a Raspberry Pi (using AMD CPU) I got the following Dockerfile to build and run successfully for me

FROM hypriot/rpi-java
USER root

WORKDIR /usr/build/

RUN /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
RUN update-ca-certificates -f
RUN /var/lib/dpkg/info/ca-certificates-java.postinst configure

EXPOSE 8080

ARG JAR_FILE=target/app-0.0.1-SNAPSHOT.jar

ADD ${JAR_FILE} app.jar

ENTRYPOINT ["java", "-Djavax.net.ssl.trustStorePassword=changeit", "-Djavax.net.ssl.trustStore=/etc/ssl/certs/java/cacerts", "-jar", "app.jar"]

I faced this problem while running a particular suite of Android for testing on Ubuntu 14.04 (Trusty Tahr). Two things worked for me as suggested by shaheen:

sudo update-ca-certificates -f

sudo /var/lib/dpkg/info/ca-certificates-java.postinst configure

None of solutions that I found on the Internet worked, but a modified version of Peter Kriens's answer seems to do the job.

First find your Java folder by running /usr/libexec/java_home. For me it was the 1.6.0.jdk version. Then go to its lib/security subfolder (for me /Library/Java/JavaVirtualMachines/1.6.0.jdk/Contents/Home/lib/security).

Then delete the cacerts file if there is one already and search for one on the system with sudo find / -name "cacerts". It found multiple items for me, in versions of Xcode or other applications that I had installed, but also at /Library/Internet Plug-Ins/JavaAppletPlugin.plugin/Contents/Home/lib/security/cacerts which I chose.

Use that file and make a symbolic link to it (while inside the Java folder from before), sudo ln -fsh "/Library/Internet Plug-Ins/JavaAppletPlugin.plugin/Contents/Home/lib/security/cacerts", and it should work.

I have both - Java from Apple's 2017-001 download (https://support.apple.com/kb/dl1572 - I assume that's where the correct certificates are from) and Oracle's one installed on Mac OS X v10.12 (Sierra).

on ubuntu 14.04 with openjdk 11 from ppa:openjdk-r/ppa this worked for me:

in java.security change keystore type to

keystore.type=jks

then:

sudo dpkg --purge --force-depends ca-certificates-java
sudo apt-get install ca-certificates-java

when you check if it worked, be sure you are not using any daemon with old java still running (eg. --no-daemon option for gradle)

this bug describes everything nicely and will help you understand what's going on https://bugs.launchpad.net/ubuntu/+source/ca-certificates-java/+bug/1739631

I found yet another reason for this error, which is not related to Ubuntu.

I tried setting up mutual TLS in a Spring boot 2 app and ran into this issue after using a truststore that had only a private key entry and no trusted certificate entry.

This is my Spring Boot TLS configuration

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

For generating truststore.pfx I had to use the following commands to make it work.

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

I ran

sudo update-ca-certificates -f

to create a certificate file, and then:

sudo /var/lib/dpkg/info/ca-certificates-java.postinst configure`

and then change the command line of jar execution:

sudo java -cp xx.jar:lib/* co.com.ixxx.clixxxlarxa.Main

Fall into this using Amazon SDK v2, Windows 10 and JDK8. Amazon SDK was complaining about credentials loading.
I solved this by replacing the security/cacert file of JDK8 by the JDK11 one.

In my case root cause of this issue was empty truststore (it was app server truststore). When I added any dummy x.509 certificate then stopped throwing this error.

Command to add certificate in truststore vis keytool

keytool -import -alias dummy -keystore <path to keystore> -storepass <truststore password if any>

For me it got resolved just by upgrading a Jenkins plugin, "Email Extension Plugin", to the latest version (2.61).

These two plugins are responsible for email configuration in Jenkins:

  • Email Extension
  • Email Extension Template

I had the same error, and the problem was not in configuring the JDK, but a simple wrong path to the JKS file in application.properties file under trust-store: parameter, double-check if the path is correct.

For my case I didn't had specified VM Arguments fully.

(Run Configurations.. > (under Apache Tomcat) any server > (x)= Arguments > VM arguments:)

Make sure all VM Arguments are set tup correctly.

You must add the cert file to your java keystore Go to chrom , open the website , save the certificate in txt format

Go to cmd> keytool -import -trustcacerts -keystore $JAVA_HOME/jre/lib/security/cacerts -storepass changeit -alias Root -import -file Trustedcaroot.txt

https://knowledge.digicert.com/solution/SO4085.html

This has worked like a charm

Related