Ява.безопасность.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 69

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. Однако это можно преодолеть, выполнив следующие простые шаги:

  1. увеличить доступность с AccessController.doPrivileged(java.security.PrivilegedAction subclass)
  2. Установите свой собственный java.security.Provider подкласс как свойство безопасности. безопасность.insertProviderAt(new, 2);
  3. Установите свой алгоритм с помощью Security.setProperty("ssl.TrustManagerFactory.algorithm" , “XTrust509”);

Я получаю эту же ошибку на моей машине Windows 7, Когда разрешения на мой файл cacerts в моем C:\Program файлы\Java\jdk1.7.0_51\jre\lib\security папка установлены неправильно.

чтобы решить эту проблему, я разрешаю службе и интерактивным пользователям иметь все разрешения на изменение cacerts за исключением "изменить разрешения" и "взять на себя ответственность" (из дополнительных настроек, в свойствах безопасности). Я предполагаю, что разрешение этим службам как читать, так и писать расширено атрибуты могут иметь какое-то отношение к удалению ошибки.