Home Error - trustAnchors parameter must be non-empty
Reply: 28

Error - trustAnchors parameter must be non-empty

David Gill
1#
David Gill Published in 2011-07-22 00:35:02Z

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

Community
2#
Community Reply to 2017-05-23 12:26:32Z

This bizarre message means that the truststore you specified was not found, or couldn't be opened due to access permissions for example.

See also @AdamPlumb's answer below.

Archimedes Trajano
3#
Archimedes Trajano Reply to 2016-11-04 19:05:55Z

This fixed the problem for me on Ubuntu:

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

(found here: https://bugs.launchpad.net/ubuntu/+source/ca-certificates-java/+bug/1396760)

ca-certificates-java is not a dependency in the Oracle JDK/JRE so this must be explicitly installed.

Gray
4#
Gray Reply to 2015-05-04 17:50:18Z

I ran into this solution from http://architecturalatrocities.com/post/19073788679/fixing-the-trustanchors-problem-when-running-openjdk-7:

Fixing the trustAnchors problem when running OpenJDK 7 on OS X. If you're running OpenJDK 7 on OS X and have seen this exception:

Unexpected error: java.security.InvalidAlgorithmParameterException: the trustAnchors
    parameter must be non-empty

There's a simple fix, just link in the same cacerts file that Apple’s JDK 1.6 uses:

cd $(/usr/libexec/java_home -v 1.7)/jre/lib/security   
ln -fsh /System/Library/Java/Support/CoreDeploy.bundle/Contents/Home/lib/security/cacerts

You need to do this for every OpenJDK version you have installed, just change -v 1.7 to the version you want to fix. Run /usr/libexec/java_home -V to see all the JREs and JDKs you have installed.

Perhaps the OpenJDK guys could add this to their install scripts.

Adam Plumb
5#
Adam Plumb Reply to 2014-08-07 17:08:48Z

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 did not specify the truststoreType, so it defaults to whatever the keystoreType is. Specifying the truststoreType explicitly as JKS solved it for me.

KiwiMartin
6#
KiwiMartin Reply to 2013-10-30 11:14:27Z

I ran into this exact problem on OSX, using JDK 1.7, after upgrading to Maverick. The fix that worked for me was to simply re-install the Apple version of Java, available here: http://support.apple.com/kb/DL1572

yvesr
7#
yvesr Reply to 2013-03-14 12:59:47Z

In Ubuntu >= 12.10, the certificates are held in the ca-certificates-java package. Using -Djavax.net.ssl.trustStore=/etc/ssl/certs/java/cacerts will pick them up regardless of what JDK you're using.

Shaheen Ghiassy
8#
Shaheen Ghiassy Reply to 2017-09-24 21:58:01Z

Ran

sudo update-ca-certificates -f 

to create cert file then

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

and I was back in business thanks guys, a pity it's not included in the installation but got there in the end.

Freddy Boucher
9#
Freddy Boucher Reply to 2013-12-30 21:06:52Z

I've had lot of security issues after upgrading to OSX Mavericks

  • SSL problem with Amazon AWS
  • peer not authenticated with Maven and Eclipse
  • trustAnchors parameter must be non-empty

I applied this JAVA update and it fixed all my issues: http://support.apple.com/kb/DL1572?viewlocale=en_US

steveoams
10#
steveoams Reply to 2015-07-24 16:33:41Z

I expected things like this, being that I use an alternate jvm in my Talend Open Studio. (support at the moment exists only until jdk1.7) i use 8 for security purposes... anyway

  • update your cert store

    sudo update-ca-certificates -f

then

  • add a new value in your initialization parameters

    sudo gedit $(path to your architecture specific ini i.e. TOS_DI...ini)

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

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

for me, the second entry worked. I think, depending on the version of TOS/TEnt + jvm, it has a different parameter name, but looks for the same keystore file

muttonUp
11#
muttonUp Reply to 2017-08-04 00:01:02Z

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

To test use keytool -list -keystore keystore.jks

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

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 tomcat will start successfully.

dmatej
12#
dmatej Reply to 2017-09-22 16:22:02Z

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
Mossroy
13#
Mossroy Reply to 2017-10-29 17:42:48Z

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 http://www.oracle.com/technetwork/java/javase/9-0-1-relnotes-3883752.html , 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 RedHat/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
Gray
14#
Gray Reply to 2015-08-31 18:54:01Z

Also encountered this on OS X after updating Mavericks, when the old Java 6 was being used and tried to access an https URL. 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
Community
15#
Community Reply to 2017-05-23 11:47:20Z

In my case the JKS file used in client application was corrupted. I created new one and import the destination server SSL certificates in it. Then I use the new JKS file in the client application as trust store like :

System.setProperty("javax.net.ssl.trustStore",path_to_your_cacerts_file);

Source: java SSL and cert keystore

I use the (KeyStore Explorer) tool to create the new JKS. You can downloaded from this link KeyStore Explorer

razvanone
16#
razvanone Reply to 2016-03-30 10:06:02Z

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 location into the eclipse install directory (same place as 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

Had some troubles with the path to the cacerts (the %java_home% env variable is somehow overwritten), so I used this trivial solve.

The idea is to provide a valid path to the truststore file - ideally 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
user3562927
17#
user3562927 Reply to 2017-03-20 18:20:54Z

For the record, none of the answers here worked for me. My gradle build started failing mysteriously with this error, unable to fetch HEAD from maven central for a particular pom file.

It turned out that I had JAVA_HOME set to my own personal build of OpenJDK, which I had built for debugging a javac issue. Setting it back to the jdk installed on my system fixed it.

Robert Hunt
18#
Robert Hunt Reply to 2017-07-04 14:42:43Z

You may also encounter this error after upgrading to Spring Boot 1.4.1 (or newer) because it brings along Tomcat 8.5.5 as part of it's dependencies. The problem is due to the way that Tomcat deals with the trust store, if you happen to have specified your trust store location as the same as your keystore in the Spring Boot config you'll likely get the trustAnchors parameter must be non-empty message when starting the application.

server.ssl.key-store=classpath:server.jks
server.ssl.trust-store=classpath:server.jks

Simply remove the server.ssl.trust-store configuration unless you know that you need it, in which case consult the links below.

The following issue contain more details about the problem:

  • https://github.com/spring-projects/spring-boot/issues/7069
  • https://github.com/spring-projects/spring-boot/issues/7406
  • https://github.com/spring-projects/spring-boot/issues/6703
shw
19#
shw Reply to 2017-11-01 12:44:56Z

None of solutions that I found on the internet worked but a modified Peter Kried's seems to do the job.

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

Then delete cacerts file if there is one already and search for one on the system with sudo find / -name "cacerts". It found multiple for me, in versions of Xcode or other apps 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 certs are from) and Oracle's one installed on Mac OS X Sierra.

Sergey Filkin
20#
Sergey Filkin Reply to 2015-02-20 08:55:37Z

I have faced with the issue while importing a Gradle project in IntelliJ IDEA 14. A solution was using a local copy of Gradle instead of a wrapper from the project directory.

ak1
21#
ak1 Reply to 2015-05-13 20:21:37Z

On RedHat Linux I got this issue resolved by importing the certs to /etc/pki/java/cacerts

Divyesh Kalbhor
22#
Divyesh Kalbhor Reply to 2016-05-31 05:45:59Z
System.setProperty("javax.net.ssl.trustStore", "C:\\Users\\user-id\\Desktop\\tomcat\\cacerts");
System.setProperty("javax.net.ssl.trustStorePassword", "passwd");

You have to add above two lines in your code. It is not able to find the truststore.

Jason D
23#
Jason D Reply to 2016-08-05 18:21:04Z

The answers here are very helpful for Linux and Mac.

If you're on Windows 10, this problem can be caused by a Java update. These seem to change the directory path of the JRE (even if you have a JDK and JRE installed separately).

What worked for me was creating a symlink (Use MinGW, Cygwin, or your favorite Bash shell for Windows) in the c/Program Files/Java directory with the same name as the pre-update version like this:

ln -s jre1.8.0_101 jre1.8.0_92

That way, your old security settings can find the right path. This is admittedly a hack, but it works.

marioosh
24#
marioosh Reply to 2017-01-05 12:05:15Z

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

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. This may help someone.

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)

The Tomahawk
25#
The Tomahawk Reply to 2017-01-11 15:12:05Z

On Ubuntu:

sudo apt install ca-certificates-java

or

sudo apt-get install ca-certificates-java

sorted it for me.

Matt Broekhuis
26#
Matt Broekhuis Reply to 2017-02-23 16:52:58Z

Another reason for this is its actually valid error. Some nefarious wifi hotspots will mess with certificates and man in the middle attack you to do who knows what (run away!).

Some large employers will do this same trick, especially in sensitive network zones so they can monitor all the encrypted traffic (not great from end user perspective but there may be good reasons for this).

Maarten
27#
Maarten Reply to 2017-03-07 09:16:10Z

I got this error when using a truststore which was exported using a IBM Websphere JDK keytool in #PKCS12 format and trying to communicate over ssl using that file on an Oracle JRE. My solution was to run on an IBM jre or convert the truststore to JKS using an IBM Websphere keytool so I was able to run it in an Oracle jre.

DPKGRG
28#
DPKGRG Reply to 2017-10-25 08:41:44Z

I faced this problem while running a particular suite of android for testing on ubuntu 14.04. Two things worked for me as suggested by shaheen

sudo update-ca-certificates -f

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

himanshu vyas
29#
himanshu vyas Reply to 2017-11-01 08:13:42Z

for me it got resolved just by upgrading a jenkins plugin "Email Extension Plugin" to latest version (2.61). these 2 plugins are responsible for email config in jenkins- Email Extension Plugin Email Extension Template Plugin

You need to login account before you can post.

About| Privacy statement| Terms of Service| Advertising| Contact us| Help| Sitemap|
Processed in 0.621772 second(s) , Gzip On .

© 2016 Powered by mzan.com design MATCHINFO