blocks|key|815069|text|用于linux的标准Sun+JDK在指定目录中的所有文件的cacerts和整体设置都是完全正确的。问题出在你使用的安装上。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|815070|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

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.

blocks|key|815111|text|如果你在Mac上安装了OpenJDK+(而不是Linux)，并且你确实通过软件更新安装了官方的Mac+(即最新的Java6)，你可以这样做：|type|unstyled|depth|inlineStyleRanges|entityRanges|data|815112|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+|code-block|syntax|javascript|815113|其中，$OPENJDK_HOME是OpenJDK安装的根目录，通常为OPENJDK_HOME=/Library/Java/JavaVirtualMachines/1.7.0u.jdk。这与Mac上的官方Java安装获取这些文件的方式相同--它们也只是从那些系统包中符号链接这些文件。适用于Lion，不确定是否适用于较早版本的操作系统。|offset|length|style|CODE|815114|entityMap^0|0|0|3|D|Y|1L|0^^$0|@$1|2|3|4|5|6|7|O|8|@]|9|@]|A|$]]|$1|B|3|C|5|D|7|P|8|@]|9|@]|A|$E|F]]|$1|G|3|H|5|6|7|Q|8|@$I|R|J|S|K|L]|$I|T|J|U|K|L]]|9|@]|A|$]]|$1|M|3|-4|5|6|7|V|8|@]|9|@]|A|$]]]|N|$]]

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:

<pre><code>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 
</code></pre>

where <code>$OPENJDK_HOME</code> is the root directory of your OpenJDK install, typically <code>OPENJDK_HOME=/Library/Java/JavaVirtualMachines/1.7.0u.jdk</code>. 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.

blocks|key|815147|text|我通过在密钥库中放置一个虚拟证书来避免这个错误(+OSX+10.5.8上的Java+1.6.0+)，比如|type|unstyled|depth|inlineStyleRanges|entityRanges|data|815148|keytool+-genkey+-alias+foo+-keystore+cacerts+-dname+cn=test+-storepass+changeit+-keypass+changeit|code-block|syntax|javascript|815149|当然，问题应该是“为什么java不能处理空的trustStore?”|815150|entityMap^0|0|0|0^^$0|@$1|2|3|4|5|6|7|K|8|@]|9|@]|A|$]]|$1|B|3|C|5|D|7|L|8|@]|9|@]|A|$E|F]]|$1|G|3|H|5|6|7|M|8|@]|9|@]|A|$]]|$1|I|3|-4|5|6|7|N|8|@]|9|@]|A|$]]]|J|$]]

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

<pre><code>keytool -genkey -alias foo -keystore cacerts -dname cn=test -storepass changeit -keypass changeit
</code></pre>

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

blocks|key|1029961|text|确保在JRE/security中具有有效的trustAnchors，否则您将无法绕过invalid+empty+cacerts错误。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1029962|在我的亚马逊EC2+Opensuse12安装中，问题是JRE安全目录中的cacerts所指向的文件无效：|1029963|$+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|code-block|syntax|javascript|1029964|所以我解决了安装旧的Opensuse+11有效证书的问题。(很抱歉！)|1029965|$+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|1029966|我知道您可以使用密钥工具来生成一个新的密钥(http://mail.openjdk.java.net/pipermail/distro-pkg-dev/2010-April/008961.html)。我可能很快就得这么做了。|offset|length|1029967|关于lellis|1029968|entityMap|0|LINK|mutability|MUTABLE|url|http://mail.openjdk.java.net/pipermail/distro-pkg-dev/2010-April/008961.html^0|0|0|0|0|0|M|24|0|0|0^^$0|@$1|2|3|4|5|6|7|10|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|11|8|@]|9|@]|A|$]]|$1|D|3|E|5|F|7|12|8|@]|9|@]|A|$G|H]]|$1|I|3|J|5|6|7|13|8|@]|9|@]|A|$]]|$1|K|3|L|5|F|7|14|8|@]|9|@]|A|$G|H]]|$1|M|3|N|5|6|7|15|8|@]|9|@$O|16|P|17|1|18]]|A|$]]|$1|Q|3|R|5|6|7|19|8|@]|9|@]|A|$]]|$1|S|3|-4|5|6|7|1A|8|@]|9|@]|A|$]]]|T|$U|$5|V|W|X|A|$Y|Z]]]]

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:

<pre><code>$ 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 -&gt; /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
</code></pre>

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

<pre><code>$ 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
</code></pre>

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

regards
 lellis

blocks|key|1029990|text|也有同样的问题。通过安装Mozilla提供的ca-certificate捆绑包解决了此问题：|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1029991|$+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|code-block|syntax|javascript|1029992|附注：|1029993|$+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)|1029994|entityMap^0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|M|8|@]|9|@]|A|$]]|$1|B|3|C|5|D|7|N|8|@]|9|@]|A|$E|F]]|$1|G|3|H|5|6|7|O|8|@]|9|@]|A|$]]|$1|I|3|J|5|D|7|P|8|@]|9|@]|A|$E|F]]|$1|K|3|-4|5|6|7|Q|8|@]|9|@]|A|$]]]|L|$]]

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

<pre><code>$ 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
</code></pre>

P.S.

<pre><code>$ 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)
</code></pre>

blocks|key|1030019|text|我在Windows上的解决方案是要么以管理员身份运行控制台窗口，要么更改环境变量MAVEN_OPTS以使用trust.jks的硬编码路径(例如'C:\Users\oddros')而不是'%25USERPROFILE%25‘。我的MAVEN_OPTS现在看起来像这样：|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1030020|-Djavax.net.ssl.trustStore=C:\Users\oddros\trust.jks+-Djavax.net.ssl.trustStorePassword=changeit|code-block|syntax|javascript|1030021|entityMap^0|0|0^^$0|@$1|2|3|4|5|6|7|I|8|@]|9|@]|A|$]]|$1|B|3|C|5|D|7|J|8|@]|9|@]|A|$E|F]]|$1|G|3|-4|5|6|7|K|8|@]|9|@]|A|$]]]|H|$]]

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:

<pre><code>-Djavax.net.ssl.trustStore=C:\Users\oddros\trust.jks -Djavax.net.ssl.trustStorePassword=changeit
</code></pre>

blocks|key|815216|text|我的cacerts文件完全是空的。我将cacerts文件从我的windows机器(使用Oracle+Java7)复制到我的Linux机器(OpenJDK)中，从而解决了这个问题。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|815217|cd+%25JAVA_HOME%25/jre/lib/security/
scp+cacerts+mylinuxmachin:/tmp|code-block|syntax|javascript|815218|然后在linux机器上|815219|cp+/tmp/cacerts+/etc/ssl/certs/java/cacerts|815220|到目前为止，它工作得很好。|815221|entityMap^0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|O|8|@]|9|@]|A|$]]|$1|B|3|C|5|D|7|P|8|@]|9|@]|A|$E|F]]|$1|G|3|H|5|6|7|Q|8|@]|9|@]|A|$]]|$1|I|3|J|5|D|7|R|8|@]|9|@]|A|$E|F]]|$1|K|3|L|5|6|7|S|8|@]|9|@]|A|$]]|$1|M|3|-4|5|6|7|T|8|@]|9|@]|A|$]]]|N|$]]

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

<pre><code>cd %JAVA_HOME%/jre/lib/security/
scp cacerts mylinuxmachin:/tmp
</code></pre>

and then on the linux machine

<pre><code>cp /tmp/cacerts /etc/ssl/certs/java/cacerts
</code></pre>

It's worked great so far.

blocks|key|1030061|text|不是原始问题的答案，但当我试图解决类似的问题时，我发现Mac+OS+X更新到Maverics时搞砸了java安装(实际上是cacert+)。从http://www.oracle.com/technetwork/java/javase/downloads/index.html中删除sudo+rm+-rf+/Library/Java/JavaVirtualMachines/*.jdk并重新安装|type|unstyled|depth|inlineStyleRanges|offset|length|style|CODE|entityRanges|data|1030062|entityMap|0|LINK|mutability|MUTABLE|url|http://www.oracle.com/technetwork/java/javase/downloads/index.html^0|3W|1F|1Z|1U|0|0^^$0|@$1|2|3|4|5|6|7|N|8|@$9|O|A|P|B|C]]|D|@$9|Q|A|R|1|S]]|E|$]]|$1|F|3|-4|5|6|7|T|8|@]|D|@]|E|$]]]|G|$H|$5|I|J|K|E|$L|M]]]]

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 <code>sudo rm -rf /Library/Java/JavaVirtualMachines/*.jdk</code> and reinstall from <a href="http://www.oracle.com/technetwork/java/javase/downloads/index.html">http://www.oracle.com/technetwork/java/javase/downloads/index.html</a>

blocks|key|815347|text|我可以通过将系统属性trustStore设置为缺少的jks文件来生成此错误。例如|type|unstyled|depth|inlineStyleRanges|entityRanges|data|815348|++++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");|code-block|syntax|javascript|815349|由于某种原因，这段代码不会生成FileNotFound异常，但它恰好是上面列出的InvalidAlgorithmParameter异常。|815350|这是个愚蠢的答案，但我可以重现。|815351|entityMap^0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|M|8|@]|9|@]|A|$]]|$1|B|3|C|5|D|7|N|8|@]|9|@]|A|$E|F]]|$1|G|3|H|5|6|7|O|8|@]|9|@]|A|$]]|$1|I|3|J|5|6|7|P|8|@]|9|@]|A|$]]|$1|K|3|-4|5|6|7|Q|8|@]|9|@]|A|$]]]|L|$]]

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

<pre><code> 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");
</code></pre>

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.

blocks|key|815396|text|在安装了java-8-oracle的Ubuntu+14.10上也有同样的问题。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|815397|解决了安装ca-certificates+java包的问题：|815398|sudo+apt-get+install+ca-certificates-java|code-block|syntax|javascript|815399|entityMap^0|0|0|0^^$0|@$1|2|3|4|5|6|7|K|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|L|8|@]|9|@]|A|$]]|$1|D|3|E|5|F|7|M|8|@]|9|@]|A|$G|H]]|$1|I|3|-4|5|6|7|N|8|@]|9|@]|A|$]]]|J|$]]

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

Solved installing ca-certificates-java package: 

<pre><code>sudo apt-get install ca-certificates-java
</code></pre>

blocks|key|1030288|text|我在Ubuntu中遇到了这个错误。我看到/usr/lib/jvm/java-8-openjdk-amd64/jre/lib/security/cacerts是一个指向/etc/ssl/certs/java/cacerts的断开链接。这就引出了这个bug：https://bugs.launchpad.net/ubuntu/%2Bsource/ca-certificates-java/%2Bbug/983302+ca-certificates+java的自述文件最终显示了实际的修复：|type|unstyled|depth|inlineStyleRanges|entityRanges|offset|length|data|1030289|跑|1030290|update-ca-certificates+-f|code-block|syntax|javascript|1030291|apt-get+install+ca-certificates-java不适合我。它只是将其标记为手动安装。|1030292|entityMap|0|LINK|mutability|MUTABLE|url|https://bugs.launchpad.net/ubuntu/%2Bsource/ca-certificates-java/%2Bbug/983302^0|3J|22|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|U|8|@]|9|@$A|V|B|W|1|X]]|C|$]]|$1|D|3|E|5|6|7|Y|8|@]|9|@]|C|$]]|$1|F|3|G|5|H|7|Z|8|@]|9|@]|C|$I|J]]|$1|K|3|L|5|6|7|10|8|@]|9|@]|C|$]]|$1|M|3|-4|5|6|7|11|8|@]|9|@]|C|$]]]|N|$O|$5|P|Q|R|C|$S|T]]]]

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: 
<a href="https://bugs.launchpad.net/ubuntu/+source/ca-certificates-java/+bug/983302">https://bugs.launchpad.net/ubuntu/+source/ca-certificates-java/+bug/983302</a>
The README for ca-certificates-java eventually showed the actual fix:

run

<pre><code>update-ca-certificates -f
</code></pre>

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

When you google for this exception: <code>java.security.InvalidAlgorithmParameterException: the trustAnchors parameter must be non-empty</code>, 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 <code>jre/lib/security/cacerts</code> 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)

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

openSUSE

Windows

Ubuntu

Linux

Java

当你在谷歌上搜索这个异常：java.security.InvalidAlgorithmParameterException: the trustAnchors parameter must be non-empty时，会出现多个结果。然而，没有确定的解决方案，只有猜测。当我尝试通过SSL打开连接时，问题就出现了(至少在...

问java.security.InvalidAlgorithmParameterException:在Linux上，trustAnchors参数必须为非空，或者为什么默认信任存储区为空
EN

社区

活动

资源

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问java.security.InvalidAlgorithmParameterException:在Linux上，trustAnchors参数必须为非空，或者为什么默认信任存储区为空EN

社区

活动

资源

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问java.security.InvalidAlgorithmParameterException:在Linux上，trustAnchors参数必须为非空，或者为什么默认信任存储区为空
EN