Ответ 1
Стандартный Sun JDK для linux имеет абсолютно ok cacerts и в целом все файлы в указанном каталоге. Проблема заключается в установке, которую вы используете.
Когда вы google для этого исключения: java.security.InvalidAlgorithmParameterException: the trustAnchors parameter must be non-empty
, появляется несколько результатов. Однако окончательного решения нет, только догадки.
Проблема возникает (по крайней мере, в моем случае), когда я пытаюсь использовать открытое соединение через SSL. Он отлично работает на моем компьютере с Windows, но когда я его развертываю на машине linux (при установке sun jre), он не справляется с вышеуказанным исключением.
Проблема заключается в том, что по умолчанию доверительная сеть JRE по умолчанию пуста (размер составляет всего 32 байта, тогда как на окнах - 80 КБ).
Когда я скопировал мой файл jre/lib/security/cacerts
из окон в linux, он отлично работал.
Вопрос в том, почему linux jre имеет пустой хранилище доверия?
Обратите внимание, что это происходит на экземпляре Amazon EC2, с AMI linux, поэтому это может быть связано с некоторыми политиками amazon (я думаю, что Java был предварительно установлен, но я не уверен)
Стандартный Sun JDK для linux имеет абсолютно ok cacerts и в целом все файлы в указанном каталоге. Проблема заключается в установке, которую вы используете.
Я получил эту ошибку в Ubuntu. я видел это /USR/Library/JVM/Java -8-OpenJDK-amd64/JRE/Library/безопасность/cacerts была неработающей ссылкой на /etc/ssl/certs/java/cacerts. Это привело меня к этой ошибке: https://bugs.launchpad.net/ubuntu/+source/ca-certificates-java/+bug/983302 README для ca-certificate-java в конечном итоге показал фактическое исправление:
бег
update-ca-certificates -f
apt-get install ca-certificates-java не работает для меня. Он просто отметил его как установленный вручную.
Я избегал этой ошибки (Java 1.6.0 на OSX 10.5.8), помещая фиктивный сертификат в хранилище ключей, например
keytool -genkey -alias foo -keystore cacerts -dname cn=test -storepass changeit -keypass changeit
Несомненно, вопрос должен быть "Почему Java не может обрабатывать пустой TrustStore?"
Не ответ на исходный вопрос, но при попытке решить подобную проблему я обнаружил, что обновление Mac OS X до Maverics испортило установку java (на самом деле, cacert). Удалите sudo rm -rf /Library/Java/JavaVirtualMachines/*.jdk
и переустановите его из http://www.oracle.com/technetwork/java/javase/downloads/index.html
Моим решением в Windows было либо запустить консольное окно в качестве администратора, либо изменить переменную окружения MAVEN_OPTS, чтобы использовать hardcoded путь к trust.jks(например, "C:\Users\oddros" ) вместо "% USERPROFILE%". Теперь мой MAVEN_OPTS выглядит следующим образом:
-Djavax.net.ssl.trustStore=C:\Users\oddros\trust.jks -Djavax.net.ssl.trustStorePassword=changeit
Я могу сгенерировать эту ошибку, установив системное свойство trustStore в отсутствующий файл jks. Например
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");
Этот код по какой-то причине не генерирует исключение FileNotFound, а именно исключение InvalidAlgorithmParameter, указанное выше.
Какой-то глупый ответ, но я могу воспроизвести.
Мой файл cacerts был полностью пуст. Я решил это, скопировав файл cacerts с моей машины Windows (используя Oracle Java 7) и scp'd в мой Linux-блок (OpenJDK).
cd %JAVA_HOME%/jre/lib/security/
scp cacerts mylinuxmachin:/tmp
а затем на машине linux
cp /tmp/cacerts /etc/ssl/certs/java/cacerts
До сих пор он отлично работал.
Была ли та же проблема на Ubuntu 14.10 с установленным java-8-оракулом.
Решено установить пакет ca-certificates-java:
sudo apt-get install ca-certificates-java
Если это произойдет с установкой OpenJDK в Mac OS X (в отличие от Linux), и у вас есть официальная Mac OS X Java (т.е. последняя версия Java 6), установленная с помощью Software Update, вы можете просто сделать это:
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
где $OPENJDK_HOME
- это корневой каталог вашей установки OpenJDK, обычно OPENJDK_HOME=/Library/Java/JavaVirtualMachines/1.7.0u.jdk
. Это идентично тому, как официальные Java-установки в Mac OS X приобретают эти файлы - они также просто символизируют их из этих системных пакетов. Работает для Lion, не уверен в более ранних версиях ОС.
Убедитесь, что у вас есть допустимые cacerts в JRE/security, иначе вы не обойдете недопустимую пустую ошибку trustAnchors.
В моей установке Amazon EC2 Opensuse12 проблема заключалась в том, что файл, отмеченный cacerts в каталоге безопасности JRE, был недействительным:
$ 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
Поэтому я решил установить старые действительные сертификаты Opensuse 11. (извините за это!!)
$ 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
Я понял, что вы можете использовать keytool для создания нового (http://mail.openjdk.java.net/pipermail/distro-pkg-dev/2010-April/008961.html). Вероятно, я скоро это сделаю.
С уважением lellis
Иметь такую же проблему. Разрешил его, установив пакет ca-certificate из 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)
Это происходит потому, что доступ к привилегии зависит от ОС и ОС. Иерархия доступа к Windows отличается от Unix. Однако это можно преодолеть, выполнив следующие простые шаги:
AccessController.doPrivileged(java.security.PrivilegedAction subclass)
java.security.Provider
как свойство безопасности.
а. Security.insertProviderAt(новый, 2);Security.setProperty("ssl.TrustManagerFactory.algorithm" , "XTrust509");
Я получаю эту же ошибку на своей машине с Windows 7, когда права на мой файл cacerts в папке C:\Program Files\Java\jdk1.7.0_51\jre\lib\безопасности не установлены правильно.
Чтобы устранить эту проблему, я разрешаю пользователям SERVICE и INTERACTIVE разрешать все изменения для cacerts, кроме "разрешений на изменение" и "взять собственность" (из "Дополнительные параметры" в свойствах "Безопасность" ). Я предполагаю, что разрешение этих служб на чтение и запись расширенных атрибутов может иметь какое-то отношение к ошибке, уходящей.