Error - trustAnchors parameter must be non-empty

Question

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.

Answer 1

My gradle build fail with:

Could not resolve org.testcontainers:postgresql:1.16.2.
Could not get resource 'https://plugins.gradle.org...'
Could not GET 'https://plugins.gradle.org...'
Unexpected error: java.security.InvalidAlgorithmParameterException: the trustAnchors parameter must be non-empty

I export root cert 'GlobalSign.crt' from browser (try load problem source https://plugins.gradle.org and get root cert) to java (my java -version is 1.8.0_191) cert store:

keytool -import -alias anyAlias -file C:/GlobalSign.crt -keystore C:/jdk1.8.0_191/jre/lib/security/cacerts -storepass changeit

The problem has been solved

Answer 2

I broke my head at this problem and checked all 45 articles on stackoverflow about this. In the end I found out, that I emptied the existing cacerts keystore first and added then my certificates (with KeyStore Explorer). This seemed to be wrong. I had to add my certificates first and then remove all the others I do not need. It seems that somehow the structure broke with emptying it or something like that. Hope that helps anybody.

Answer 3

Working on an implementation of Spring Boot OAuth2 Authorization server (from samples). I ran into this issue. Answer here - https://stackoverflow.com/a/44908840/7411342 was verify useful. Simply removing the trustore configuration was suficient to get this to work. Tomcat does not supporting SSL-client-auth with self signed certificates which means we need to have a truststore that is different from the keystore.

If you need to create a keystore, follow the instructions here - Applications With SSL Bundles

Keystore

openssl pkcs12 -export -in src/main/resources/cert.pem -inkey src/main/resources/key.pem -out src/main/resources/keystore.p12 -name secure-service -passin pass:FooBar -passout pass:FooBar

Trustore

keytool -import -file C:\cascerts\firstCA.cert -alias firstCA -keystore myTrustStore

More info con creating keystore/truststore

Answer 4

On Ubuntu 22.04.1 upgrading my java version to jdk-12.0.2 from 11.0.22 and setting it to the default runtime worked.

How to do that can be found on this thread Install jdk-12.0.2 on Ubuntu

Answer 5

With me, problem is settings.xml file for maven is not config right user First check the settings file you use for build and check this with right user

Answer 6

This bizarre message means that the trust store you specified was:

• empty,
• not found, or
• couldn't be opened, due for example to:
  • wrong/missing trustStorePassword, or
  • file access permissions.

See also @AdamPlumb's answer below.

Answer 7

I had to explicitly specify the path to the store, but I didn't need to do this before. The application connects to the remote service over https.

Answer 8

I got the same error. But when I restarted the Tomcat service, thankfully it has gone.

sudo /usr/local/tomcat/bin/shutdown.sh
sudo /usr/local/tomcat/bin/startup.sh

Answer 9

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). Nothing worked for me.

cacerts file is empty

In my case, reviewing my jdk folder, the cacerts file had a little size compared with other jdk folder (servers & friends):

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

I downloaded it from:

• https://download.java.net/openjdk/jdk8u41/ri/openjdk-8u41-b04-linux-x64-14_jan_2020.tar.gz
• https://download.java.net/java/GA/jdk9/9/binaries/openjdk-9_linux-x64_bin.tar.gz

Fix

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

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

• https://github.com/AdoptOpenJDK/openjdk8-upstream-binaries/releases/download/jdk8u262-b10/OpenJDK8U-jdk-jfr_x64_linux_8u262b10.tar.gz

I found this url in this Dockerfile :

• https://github.com/docker-library/openjdk/blob/b5d14d9165fad693901c285d6e7bbc36d1cde41f/8/jdk/Dockerfile

Answer 10

I ran into the the trustAnchors parameter must be non-empty error when I tried to run my app in IntelliJ. To fix the problem I had to make the Run Configuration point to the JDK or JRE that had the /lib/security/ folder which had the cacerts file.

Answer 11

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>

Answer 12

For me it was caused by the lack of a trustedCertEntry in the truststore.

To test, use:

keytool -list -keystore keystore.jks

It gives me:

Keystore type: JKS
Keystore provider: SUN

Your keystore contains 1 entry

cert-alias, 31-Jul-2017, PrivateKeyEntry

Even though my PrivateKeyEntry contains a CA it needed to be imported separately:

keytool -import -alias root-ca1 -file rootca.crt -keystore keystore.jks

It imports the certificate, and then re-running keytool -list -keystore keystore.jks now gives:

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>

Now it has a trustedCertEntry, and Tomcat will start successfully.

Answer 13

The error tells that the system cannot find the truststore in the path provided with the parameter javax.net.ssl.trustStore.

Under Windows I copied the cacerts file from jre/lib/security into the Eclipse install directory (same place as the eclipse.ini file) and added the following settings in eclipse.ini:

-Djavax.net.ssl.trustStore=cacerts
-Djavax.net.ssl.trustStorePassword=changeit
-Djavax.net.ssl.trustStoreType=JKS

I had some troubles with the path to the cacerts (the %java_home% environment variable is somehow overwritten), so I used this trivial solution.

The idea is to provide a valid path to the truststore file - ideally it would be to use a relative one. You may also use an absolute path.

To make sure the store type is JKS, you would run the following command:

keytool -list -keystore cacerts

Keystore type: JKS
Keystore provider: SUN

Note: because certificates have expiration dates, or can become invalid for other reasons, do check from time to time if the certificates in cacerts are still valid. You would usually find the valid versions of the certificates in the latest builds of jdk.

Answer 14

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

Answer 15

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.

Answer 16

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.

Answer 17

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).

Answer 18

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.

Answer 19

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

Answer 20

Some OpenJDK vendors releases caused this by having an empty cacerts file distributed with the binary. The bug is explained here: https://github.com/AdoptOpenJDK/openjdk-build/issues/555

You can copy to adoptOpenJdk8\jre\lib\security\cacerts the file from an old instalation like c:\Program Files\Java\jdk1.8.0_192\jre\lib\security\cacerts.

The AdoptOpenJDK buggy version is https://github.com/AdoptOpenJDK/openjdk8-releases/releases/download/jdk8u172-b11/OpenJDK8_x64_Win_jdk8u172-b11.zip

Answer 21

EJP basically answered the question (and I realize this has an accepted answer), but I just dealt with this edge-case gotcha and wanted to immortalize my solution.

I had the InvalidAlgorithmParameterException error on a hosted Jira server that I had previously set up for SSL-only access. The issue was that I had set up my keystore in the PKCS#12 format, but my truststore was in the JKS format.

In my case, I had edited my server.xml file to specify the keystoreType to PKCS, but I did not specify the truststoreType, so it defaults to whatever the keystoreType is. Specifying the truststoreType explicitly as JKS solved it for me.

Answer 22

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"]

Answer 23

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

Answer 24

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

Answer 25

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

Answer 26

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

Answer 27

I got the same error when sending emails, but NOT always. In my case I've changed one line of code to get a new Session object every time:

MimeMessage message = new MimeMessage(Session.getDefaultInstance(props, authenticator));

to

MimeMessage message = new MimeMessage(Session.getInstance(props, authenticator));

Since then sending e-mails works every time.

The error I got:

javax.mail.MessagingException: Could not convert socket to TLS;
nested exception is: javax.net.ssl.SSLException:
java.lang.RuntimeException: Unexpected error:
java.security.InvalidAlgorithmParameterException: the trustAnchors
parameter must be non-empty at
com.sun.mail.smtp.SMTPTransport.startTLS(SMTPTransport.java:1907) at
com.sun.mail.smtp.SMTPTransport.protocolConnect(SMTPTransport.java:666)
at javax.mail.Service.connect(Service.java:317) at
javax.mail.Service.connect(Service.java:176) at
javax.mail.Service.connect(Service.java:125) at
javax.mail.Transport.send0(Transport.java:194) at
javax.mail.Transport.send(Transport.java:124)

Answer 28

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.

Answer 29

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.

Answer 30

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).