Ява.безопасность.InvalidAlgorithmParameterException: параметр trustAnchors должен быть непустым в Linux, или почему по умолчанию truststore пуст [дубликат]
этот вопрос уже есть ответ здесь:
когда вы Google для этого исключения: java.security.InvalidAlgorithmParameterException: the trustAnchors parameter must be non-empty
, появляется несколько результатов. Однако окончательного решения нет, только догадки.
проблема возникает (в моем случае по крайней мере), когда я пытаюсь использовать открыть соединение по протоколу SSL. Он отлично работает на моей машине windows, но когда я развертываю его на машине linux (с установленным JRE sun), он терпит неудачу с вышеуказанным исключением.
проблема в том, что хранилище доверия по умолчанию JRE по какой-то причине пусто (размер только 32 байта, тогда как в windows он составляет 80 КБ).
когда я скопировал мой jre/lib/security/cacerts
файл из windows в linux, он работал нормально.
вопрос в том, почему linux jre имеет пустое доверие магазин?
обратите внимание, что это происходит на экземпляре Amazon EC2 с AMI linux, поэтому это может быть связано с некоторыми политиками amazon (я думаю, что java была предварительно установлена, но я не уверен)
13 ответов:
стандартный Sun JDK для linux имеет абсолютно ОК cacerts и в целом все файлы в указанном каталоге. Проблема заключается в установке, которую вы используете.
Я получил эту ошибку в Ubuntu. Я видел, что в /usr/lib в/в jvm/java-в 8-пакеты OpenJDK-amd64 с/у jre/lib/безопасности/cacerts в была сломана ссылка на /etc/ssl/certs/java / cacerts. Что привело меня к этой ошибке: https://bugs.launchpad.net/ubuntu/ + source / ca-сертификаты-java / + bug / 983302 README для ca-certificates-java в конечном итоге показал фактическое исправление:
run
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
Я могу создать эту ошибку, установив системное свойство 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, указанное выше.
вроде глупый ответ, но я могу воспроизвести.
мое решение в Windows состояло в том, чтобы либо запустить окно консоли от имени администратора, либо изменить переменную среды MAVEN_OPTS, чтобы использовать жестко заданный путь для доверия.следующих (напр. 'C:\Users\oddros') вместо '%ПРОФИЛЬ_ПОЛЬЗОВАТЕЛЯ%'. Мой MAVEN_OPTS теперь выглядит так:
-Djavax.net.ssl.trustStore=C:\Users\oddros\trust.jks -Djavax.net.ssl.trustStorePassword=changeit
была такая же проблема на Ubuntu 14.10 с установленной java-8-oracle.
решена установка ca-сертификатов-пакет java:
sudo apt-get install ca-certificates-java
мой файл cacerts был полностью пуст. Я решил это, скопировав файл cacerts с моей машины windows (которая использует Oracle Java 7) и scp'D его в мой Linux box (OpenJDK).
cd %JAVA_HOME%/jre/lib/security/ scp cacerts mylinuxmachin:/tmp
а потом на linux машине
cp /tmp/cacerts /etc/ssl/certs/java/cacerts
Он отлично работал до сих пор.
Если это произойдет с вами при установке OpenJDK на Mac OS X (в отличие от Linux), и у вас есть официальная Mac OS X Java (т. е. последняя Java 6), установленная через обновление программного обеспечения, вы можете просто сделать это:
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 приобретают эти файлы - они также просто символически связывают их с этими системными пакетами. Работает для Льва, не уверен, что раньше версии ОС.
убедитесь, что у вас есть допустимые 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). мне, вероятно, придется это сделать в ближайшее время.
С уважением Леллис
есть та же проблема. Решить ее путем установки центра сертификации-сертификат пакет от 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
П. С.
$ 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
подкласс как свойство безопасности. безопасность.insertProviderAt(new, 2);- Установите свой алгоритм с помощью
Security.setProperty("ssl.TrustManagerFactory.algorithm" , “XTrust509”);
Я получаю эту же ошибку на моей машине Windows 7, Когда разрешения на мой файл cacerts в моем C:\Program файлы\Java\jdk1.7.0_51\jre\lib\security папка установлены неправильно.
чтобы решить эту проблему, я разрешаю службе и интерактивным пользователям иметь все разрешения на изменение cacerts за исключением "изменить разрешения" и "взять на себя ответственность" (из дополнительных настроек, в свойствах безопасности). Я предполагаю, что разрешение этим службам как читать, так и писать расширено атрибуты могут иметь какое-то отношение к удалению ошибки.