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.
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:
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.
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
tocacerts
, and that fixed the issue.I ran
to create a certificate file, and then:
I was back in business, thanks guys. It is a pity it's not included in the installation, but I got there in the end.
Another reason for this is it's actually a valid error. Some nefarious Wi-Fi 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).
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 fromjre/lib/security
into the Eclipse install directory (same place as theeclipse.ini
file) and added the following settings ineclipse.ini
: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: