Home Error - trustAnchors parameter must be non-empty

# 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#
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#
 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#
 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): root-ca1, 04-Aug-2017, trustedCertEntry, Certificate fingerprint (SHA1):  Now it has a trustedCertEntry tomcat will start successfully.
dmatej
12#
 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#
 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#
 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#
 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#
 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#
 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#
 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#
 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#
 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#