例外: 在 Linux 上，trust Anchors 参数必须是非空的，或者为什么默认的信任存储是空的

当你谷歌这个例外: java.security.InvalidAlgorithmParameterException: the trustAnchors parameter must be non-empty，多个结果出现。但没有明确的解决方案，只有猜测。

当我尝试使用通过 SSL 打开连接时，问题出现了(至少在我的情况下)。它在我的 windows 机器上工作得很好，但是当我将它部署到 linux 机器上(安装了 sun 的 jre)时，它会因上述异常而失败。

问题是 JRE 的默认信任存储由于某种原因是空的(大小只有32字节，而在 windows 上是80kb)。

当我将 jre/lib/security/cacerts文件从 windows 复制到 linux 时，它工作得很好。

问题是——为什么 linux jre 有一个空的信任存储？

注意，这种情况发生在使用 AMI Linux 的 Amazon EC2实例上，因此可能是由于一些 Amazon 策略(我认为 Java 是预先安装的，但我不确定)

265469 次浏览
小开
最佳答案

The standard Sun JDK for linux has an absolutely ok cacerts and overall all files in the specified directory. The problem is the installation you use.

小开

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.

小开

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

小开

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)
小开

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
小开

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.

小开

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

小开

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

小开

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.

小开

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
小开

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.


提交答案