[java] java.security.InvalidAlgorithmParameterException: the trustAnchors parameter must be non-empty on Linux, or why is the default truststore empty

When you google for this exception: java.security.InvalidAlgorithmParameterException: the trustAnchors parameter must be non-empty, multiple results appear. However there is no definitive solution, only guesses.

The problem arises (in my case at least) when I try to use open a connection over SSL. It works fine on my windows machine, but when I deploy it to the linux machine (with sun's jre installed) it fails with the above exception.

The problem is that the default truststore of the JRE is empty for some reason (size of only 32 bytes, whereas it is 80kb on windows).

When I copied my jre/lib/security/cacerts file from windows to linux, it worked fine.

The question is - why is the linux jre having an empty trust store?

Note that this happens on an Amazon EC2 instance, with the AMI linux, so it might be due to some amazon policies (I think java was pre-installed, but I'm not sure)

My solution on Windows was to either run console window as Administrator or change the environment variable MAVEN_OPTS to use a hardcoded path to trust.jks (e.g. 'C:\Users\oddros') instead of '%USERPROFILE%'. My MAVEN_OPTS now looks like this:

-Djavax.net.ssl.trustStore=C:\Users\oddros\trust.jks -Djavax.net.ssl.trustStorePassword=changeit

I have avoided this error (Java 1.6.0 on OSX 10.5.8) by putting a dummy cert in the keystore, such as

keytool -genkey -alias foo -keystore cacerts -dname cn=test -storepass changeit -keypass changeit

Surely the question should be "Why can't java handle an empty trustStore?"

I get this same error on my Windows 7 machine when the permissions on my cacerts file in my C:\Program Files\Java\jdk1.7.0_51\jre\lib\security folder are not set correctly.

To resolve the issue, I allow the SERVICE and INTERACTIVE users to have all modify permissions on cacerts except "change permissions" and "take ownership" (from Advanced Settings, in the Security properties). I assume that allowing these services to both read and write extended attributes may have something to do with the error going away.

My cacerts file was totally empty. I solved this by copying the cacerts file off my windows machine (that's using Oracle Java 7) and scp'd it to my Linux box (OpenJDK).

cd %JAVA_HOME%/jre/lib/security/
scp cacerts mylinuxmachin:/tmp

and then on the linux machine

cp /tmp/cacerts /etc/ssl/certs/java/cacerts

It's worked great so far.

Had the same issue on Ubuntu 14.10 with java-8-oracle installed.

Solved installing ca-certificates-java package:

sudo apt-get install ca-certificates-java

Not the answer to the original question but when trying to resolve a similar issue, I found that the Mac OS X update to Maverics screwed up the java install (the cacert actually). Remove sudo rm -rf /Library/Java/JavaVirtualMachines/*.jdk and reinstall from http://www.oracle.com/technetwork/java/javase/downloads/index.html

I can generate this error by setting system property trustStore to a missing jks file. For example

    System.setProperty("javax.net.ssl.keyStore", "C:/keystoreFile.jks");
    System.setProperty("javax.net.ssl.keyStorePassword", "mypassword");
    System.setProperty("javax.net.ssl.trustStore", "C:/missing-keystore.jks");
    System.setProperty("javax.net.ssl.trustStorePassword", "mypassword");

This code does not generate a FileNotFound exception for some reason, but exactly the InvalidAlgorithmParameter exception listed above.

Kind of a dumb answer, but I can reproduce.

This happens because Access Privilege varies from OS to OS. Windows access hierarchy is different from Unix. However, this could be overcome by following these simple steps:

1. Increase accessibility with AccessController.doPrivileged(java.security.PrivilegedAction subclass)
2. Set your own java.security.Provider subclass as security property. a. Security.insertProviderAt(new , 2);
3. Set your Algorythm with Security.setProperty("ssl.TrustManagerFactory.algorithm" , “XTrust509”);

I got this error in Ubuntu. I saw that /usr/lib/jvm/java-8-openjdk-amd64/jre/lib/security/cacerts was a broken link to /etc/ssl/certs/java/cacerts. That lead me to this bug: https://bugs.launchpad.net/ubuntu/+source/ca-certificates-java/+bug/983302 The README for ca-certificates-java eventually showed the actual fix:

run

update-ca-certificates -f

apt-get install ca-certificates-java didn't work for me. It just marked it as manually installed.

If this happens to you with an OpenJDK install on Mac OS X (as opposed to Linux), and you do have the official Mac OS X Java (i.e. latest Java 6) installed through Software Update, you can just do this:

cd $OPENJDK_HOME/Contents/Home/jre/lib/security
ln -s /System/Library/Java/Support/CoreDeploy.bundle/Contents/Home/lib/security/cacerts
ln -s /System/Library/Java/Support/Deploy.bundle/Contents/Home/lib/security/blacklist 
ln -s /System/Library/Java/Support/Deploy.bundle/Contents/Home/lib/security/trusted.libraries 

where $OPENJDK_HOME is the root directory of your OpenJDK install, typically OPENJDK_HOME=/Library/Java/JavaVirtualMachines/1.7.0u.jdk. This is identical to how official Java installs on Mac OS X acquire these files - they also just symlink them from those system bundles. Works for Lion, not sure for earlier versions of the OS.

Make sure that you have valid cacerts in the JRE/security, otherwise you will not bypass the invalid empty trustAnchors error.

In my Amazon EC2 Opensuse12 installation, the problem was that the file pointed by the cacerts in the JRE security directory was invalid:

$ java -version
java version "1.7.0_09"
OpenJDK Runtime Environment (IcedTea7 2.3.4) (suse-3.20.1-x86_64)
OpenJDK 64-Bit Server VM (build 23.2-b09, mixed mode)

$ ls -l /var/lib/ca-certificates/
-rw-r--r-- 1 root    363 Feb 28 14:17 ca-bundle.pem

$ ls -l /usr/lib64/jvm/jre/lib/security/
lrwxrwxrwx 1 root    37 Mar 21 00:16 cacerts -> /var/lib/ca-certificates/java-cacerts
-rw-r--r-- 1 root  2254 Jan 18 16:50 java.policy
-rw-r--r-- 1 root 15374 Jan 18 16:50 java.security
-rw-r--r-- 1 root    88 Jan 18 17:34 nss.cfg

So I solved installing an old Opensuse 11 valid certificates. (sorry about that!!)

$ ll
total 616
-rw-r--r-- 1 root 220065 Jan 31 15:48 ca-bundle.pem
-rw-r--r-- 1 root    363 Feb 28 14:17 ca-bundle.pem.old
-rw-r--r-- 1 root 161555 Jan 31 15:48 java-cacerts

I understood that you could use the keytool to generate a new one (http://mail.openjdk.java.net/pipermail/distro-pkg-dev/2010-April/008961.html). I'll probably have to that soon.

regards lellis

Have the same issue. Resolved it by installing ca-certificate bundle from Mozilla:

$ zypper in ca-certificates-mozilla
The following NEW package is going to be installed:
ca-certificates-mozilla 

1 new package to install.
Retrieving package ca-certificates-mozilla-1.85-8.8.1.noarch
(1/1), 143.7 KiB (239.1 KiB unpacked)
Retrieving: ca-certificates-mozilla-1.85-8.8.1.noarch.rpm.....................[done]
Installing: ca-certificates-mozilla-1.85-8.8.1 ...............................[done]
Additional rpm output:
Updating certificates in /etc/ssl/certs...
144 added, 0 removed.
creating /var/lib/ca-certificates/ca-bundle.pem ...
creating /var/lib/ca-certificates/java-cacerts ...
144 added, 0 removed.

$ ll /var/lib/ca-certificates/
total 392
drwxr-xr-x  2 root root   4096 Apr 26 07:25 ./
drwxr-xr-x 30 root root   4096 Apr 25 15:00 ../
-rw-r--r--  1 root root 220196 Apr 26 07:25 ca-bundle.pem
-rw-r--r--  1 root root 161555 Apr 26 07:25 java-cacerts

P.S.

$ cat /etc/SuSE-release
openSUSE 12.2 (x86_64)
VERSION = 12.2
CODENAME = Mantis
$ java -version
java version "1.7.0_09"
OpenJDK Runtime Environment (IcedTea7 2.3.4) (suse-3.20.1-x86_64)
OpenJDK 64-Bit Server VM (build 23.2-b09, mixed mode)