Ошибка - параметр trustAnchors должен быть непустым

Я пытаюсь настроить электронную почту на Jenkins/Hudson, и я постоянно получаю сообщение об ошибке:

java.security.InvalidAlgorithmParameterException: the trustAnchors parameter must be
    non-empty

Я видел много информации в Интернете об ошибке, но у меня нет работы. Я использую Sun JDK на Fedora Linux (а не OpenJDK).

Вот несколько вещей, которые я пробовал. Я пробовал следовать совету этого поста, но копирование cacerts из Windows на мой пакет Fedora, где размещается Jenkins, не сработало. Я попытался следовать этому руководству, поскольку я пытаюсь настроить Gmail как мой SMTP-сервер, но он тоже не работает. Я также попытался загрузить и переместить эти файлы cacert вручную и перенести их в свою папку Java, используя вариации команд в этом руководстве.

Я открыт для любых предложений, поскольку я сейчас застрял прямо сейчас. Я получил его для работы с сервером Windows Hudson, но я боюсь Linux.

Ответ 1

Это странное сообщение означает, что указанный вами траст-сервер:

  • пусто,
  • не найдено, или
  • не удалось открыть (из-за, например, прав доступа).

См. Также @AdamPlumb ответ ниже.

Ответ 2

В Ubuntu 18.04 эта ошибка имеет другую причину (JEP 229, переключение из формата по умолчанию jks формат pkcs12 и создание файла cacerts Debian с использованием по умолчанию для новых файлов) и обходной путь:

# Ubuntu 18.04 and various Docker images such as openjdk:9-jdk throw exceptions when
# Java applications use SSL and HTTPS, because Java 9 changed a file format, if you
# create that file from scratch, like Debian / Ubuntu do.
#
# Before applying, run your application with the Java command line parameter
#  java -Djavax.net.ssl.trustStorePassword=changeit ...
# to verify that this workaround is relevant to your particular issue.
#
# The parameter by itself can be used as a workaround, as well.

# 0. First make yourself root with 'sudo bash'.

# 1. Save an empty JKS file with the default 'changeit' password for Java cacerts.
#    Use 'printf' instead of 'echo' for Dockerfile RUN compatibility.
/usr/bin/printf '\xfe\xed\xfe\xed\x00\x00\x00\x02\x00\x00\x00\x00\xe2\x68\x6e\x45\xfb\x43\xdf\xa4\xd9\x92\xdd\x41\xce\xb6\xb2\x1c\x63\x30\xd7\x92' > /etc/ssl/certs/java/cacerts

# 2. Re-add all the CA certs into the previously empty file.
/var/lib/dpkg/info/ca-certificates-java.postinst configure

https://git.mikael.io/mikaelhg/broken-docker-jdk9-cacerts


Статус (2018-08-07), ошибка была исправлена в Ubuntu Bionic LTS 18.04.1 и Ubuntu Cosmic 18.10.


🗹 Ubuntu 1770553: [SRU] backport ca-certificate-java из космического (20180413ubuntu1)

🗹 Ubuntu 1769013: Пожалуйста, объедините ca-certificates-java 20180413 (main) из Debian unstable (main)

🗹 Ubuntu 1739631: свежая установка с JDK 9 не может использовать сгенерированный файл хранилища ключей cacerts PKCS12

🗹 docker-library 145: 9-jdk image имеет проблемы с SSL

🗹 Debian 894979: ca-certificates-java: не работает с OpenJDK 9, приложения терпят неудачу с InvalidAlgorithmParameterException: параметр trustAnchors должен быть непустым

🗹 JDK-8044445: JEP 229: Создать PKCS12 Keystores по умолчанию

🖺 JEP 229: Создание ключей PKCS12 по умолчанию


Если проблема не исчезнет после этого решения, возможно, вам захочется убедиться, что вы фактически используете дистрибутив Java, который вы только что исправили.

$ which java
/usr/bin/java

Вы можете установить альтернативы Java в "auto" с помощью:

$ sudo update-java-alternatives -a
update-alternatives: error: no alternatives for mozilla-javaplugin.so

Вы можете дважды проверить версию Java, которую вы выполняете:

$ java --version
openjdk 10.0.1 2018-04-17
OpenJDK Runtime Environment (build 10.0.1+10-Ubuntu-3ubuntu1)
OpenJDK 64-Bit Server VM (build 10.0.1+10-Ubuntu-3ubuntu1, mixed mode)

Существуют альтернативные способы обхода, но у них есть свои собственные побочные эффекты, которые потребуют дополнительного обслуживания в будущем, без каких-либо выплат.

Следующим лучшим решением является добавление строки

javax.net.ssl.trustStorePassword=changeit

к файлам

/etc/java-9-openjdk/management/management.properties
/etc/java-11-openjdk/management/management.properties

в зависимости от того, что существует.

Третьим наименее проблематичным обходным решением является изменение значения

keystore.type=pkcs12

в

keystore.type=jks

в файлах

/etc/java-9-openjdk/security/java.security
/etc/java-11-openjdk/security/java.security

в зависимости от того, что существует, и затем удалить файл cacerts и регенерировать его описанным выше способом.

Ответ 3

Это исправило проблему для меня на Ubuntu:

sudo /var/lib/dpkg/info/ca-certificates-java.postinst configure

(найдено здесь: https://bugs.launchpad.net/ubuntu/+source/ca-certificates-java/+bug/1396760)

ca-certificates-java не является зависимостью в Oracle JDK/JRE, поэтому это должно быть явно установлено.

Ответ 4

В Ubuntu 18.04 основной причиной является конфликт между openjdk-11-jdk (который используется по умолчанию) и другими пакетами, зависящими от него. Это уже исправлено в Debian и скоро будет включено в Ubuntu. Между тем, самый простой обходной путь - это понизить Java до версии 8. Другие решения, использующие ca-certificates-java, намного сложнее.

Сначала удалите конфликтующие пакеты:

sudo apt-get remove --purge openjdk* java-common default-jdk
sudo apt-get autoremove --purge

Проверьте, успешно ли вы удалили все связанные пакеты:

sudo update-alternatives --config java

Система сообщит вам, что Java не доступен для настройки, в противном случае этот обходной путь завершится неудачно.

Затем переустановите необходимые пакеты:

sudo apt-get install openjdk-8-jdk

Ответ 5

EJP в основном ответил на вопрос (и я понимаю, что у него есть принятый ответ), но я только что имел дело с этим крайним случаем и хотел увековечить свое решение.

У меня была ошибка InvalidAlgorithmParameterException на размещенном сервере Jira, который я ранее настроил для доступа только по SSL. Проблема была в том, что я настроил хранилище ключей в формате PKCS # 12, но хранилище доверенных сертификатов было в формате JKS.

В моем случае я отредактировал свой файл server.xml, чтобы указать keystoreType для PKCS, но я не указал truststoreType, поэтому по умолчанию используется значение keystoreType. Я указал truststoreType явно, поскольку JKS решил это для меня.

Ответ 6

Я столкнулся с этим решением из сообщения в блоге Исправлена проблема trustAnchors при запуске OpenJDK 7 в OS X:

Устранение проблемы trustAnchors при запуске OpenJDK 7 в OS X. Если вы используете OpenJDK 7 в OS X и видели это исключение:

Unexpected error: java.security.InvalidAlgorithmParameterException: the trustAnchors
    parameter must be non-empty

Там простое исправление. Просто ссылку в том же файле cacerts, что и Apples JDK 1.6:

cd $(/usr/libexec/java_home -v 1.7)/jre/lib/security
ln -fsh /System/Library/Java/Support/CoreDeploy.bundle/Contents/Home/lib/security/cacerts

Вам нужно сделать это для каждой установленной версии OpenJDK. Просто измените -v 1.7 на версию, которую вы хотите исправить. Запустите /usr/libexec/java_home -v чтобы увидеть все установленные JRE и JDK.

Возможно, ребята из OpenJDK могут добавить это в свои установочные скрипты.

Ответ 7

В Ubuntu 12.10 (Quantal Quetzal) или более поздних версиях сертификаты хранятся в пакете ca-certificate-java. Использование -Djavax.net.ssl.trustStore=/etc/ssl/certs/java/cacerts подберет их независимо от того, какой JDK вы используете.

Ответ 8

Я столкнулся с этой точной проблемой на OS X, используя JDK 1.7, после обновления до OS X версии 10.9 (Mavericks). Исправление, которое сработало для меня, было просто переустановить версию Java для Java, доступную по адресу http://support.apple.com/kb/DL1572.

Ответ 9

Я побежал

sudo update-ca-certificates -f

для создания файла сертификата, а затем:

sudo /var/lib/dpkg/info/ca-certificates-java.postinst configure

Я вернулся в бизнес, спасибо, ребята. Жаль, что он не включен в установку, но я попал туда, в конце концов.

Ответ 10

Ошибка говорит о том, что система не может найти javax.net.ssl.trustStore в пути, предоставляемом параметром javax.net.ssl.trustStore.

В Windows я скопировал файл cacerts из jre/lib/security в каталог установки Eclipse (то же самое место, что и файл eclipse.ini), и добавил следующие параметры в eclipse.ini:

-Djavax.net.ssl.trustStore=cacerts
-Djavax.net.ssl.trustStorePassword=changeit
-Djavax.net.ssl.trustStoreType=JKS

У меня были некоторые проблемы с пути к cacerts (переменная среды% java_home% как-то перезаписана), поэтому я использовал это тривиальное решение.

Идея состоит в том, чтобы предоставить допустимый путь к файлу доверия - в идеале это будет использовать относительный. Вы также можете использовать абсолютный путь.

Чтобы убедиться, что тип хранилища JKS, вы должны выполнить следующую команду:

keytool -list -keystore cacerts

Keystore type: JKS
Keystore provider: SUN

Ответ 11

У меня было много проблем с безопасностью после обновления до OS X v10.9 (Mavericks):

  • Проблема с SSL с Amazon AWS
  • Peer не аутентифицирован Maven и Eclipse
  • Параметр trustAnchors должен быть непустым

Я применил это обновление Java и исправил все мои проблемы: http://support.apple.com/kb/DL1572?viewlocale=en_US

Ответ 12

Удаление пакета ca-certificate-java и его установка снова помогли мне (Ubuntu MATE 17.10 (Artful Aardvark)).

sudo dpkg --purge --force-depends ca-certificates-java

sudo apt-get install ca-certificates-java

Спасибо, jdstrand: Комментарий 1 к ошибке 983302, Re: ca-certificate-java не может установить Java cacerts на Oneiric Ocelot.

Ответ 13

Я ожидал таких вещей, потому что я использую альтернативную JVM в своей Talend Open Studio (поддержка на данный момент существует только до JDK 1.7). Я использую 8 для целей безопасности... в любом случае

  • Обновите хранилище сертификатов:

    sudo update-ca-certificates -f
    

тогда

  • добавьте новое значение в параметры инициализации

    sudo gedit $(path to your architecture specific ini i.e. TOS_DI...ini)
    
    Djavax.net.ssl.trustStore=/etc/ssl/certs/java/cacerts
    

Для меня вторая работа. Я думаю, в зависимости от версии Talend Open Studio/TEnt + JVM у нее есть другое имя параметра, но она ищет тот же файл хранилища ключей.

Ответ 14

Для меня это было вызвано отсутствием trustedCertEntry в доверенности.

Для тестирования используйте:

keytool -list -keystore keystore.jks

Это дает мне:

Keystore type: JKS
Keystore provider: SUN

Your keystore contains 1 entry

cert-alias, 31-Jul-2017, PrivateKeyEntry

Хотя мой PrivateKeyEntry содержит CA, его нужно было импортировать отдельно:

keytool -import -alias root-ca1 -file rootca.crt -keystore keystore.jks

Он импортирует сертификат, а затем повторно запускает keytool -list -keystore keystore.jks теперь дает:

Your keystore contains 2 entries

cert-alias, 31-Jul-2017, PrivateKeyEntry,
Certificate fingerprint (SHA1):
<fingerprint>
root-ca1, 04-Aug-2017, trustedCertEntry,
Certificate fingerprint (SHA1):
<fingerprint>

Теперь у него есть trustedCertEntry, и Tomcat начнется успешно.

Ответ 15

Если вы испытываете это на Ubuntu с JDK9 и Maven, вы можете добавить эту опцию JVM - сначала проверьте, существует ли путь:

-Djavax.net.ssl.trustStore=/etc/ssl/certs/java/cacerts

Если файл отсутствует, попробуйте установить ca-certificates-java, как заметил кто-то:

sudo apt install ca-certificates-java

Ответ 16

У меня была эта проблема при попытке использовать Maven 3 после обновления от Ubuntu 16.04 LTS (Xenial Xerus) до Ubuntu 18.04 LTS (Bionic Beaver).

Проверка /usr/lib/jvm/java-8-oracle/jre/lib/security показала, что мой файл cacerts был символической ссылкой, указывающей на /etc/ssl/certs/java/cacerts.

У меня также был файл подозрительно названный cacerts.original.

Я переименовал cacerts.original в cacerts, и это исправило проблему.

Ответ 17

В некоторых выпусках Openjdk для Windows10 это вызвано тем, что пустой двоичный файл распространялся вместе с двоичным файлом. Ошибка объясняется здесь: https://github.com/AdoptOpenJDK/openjdk-build/issues/555

Вы можете скопировать в adoptOpenJdk8\jre\lib\security\cacerts файл из старой установки, например c:\Program Files\Java\jdk1.8.0_192\jre\lib\security\cacerts.

Версия с ошибкой AdoptOpenJDK https://github.com/AdoptOpenJDK/openjdk8-releases/releases/download/jdk8u172-b11/OpenJDK8_x64_Win_jdk8u172-b11.zip

Ответ 18

Я также столкнулся с этим на OS X после обновления OS X версии 10.9 (Mavericks), когда использовался старый Java 6 и пытался получить доступ к URL-адресу HTTPS. Исправление было обратным к Питеру Кринс; Мне нужно было скопировать cacerts из пространства 1.7 в место, связанное с версией 1.6:

(as root)
umask 022
mkdir -p /System/Library/Java/Support/CoreDeploy.bundle/Contents/Home/lib/security
cp $(/usr/libexec/java_home -v 1.7)/jre/lib/security/cacerts \
    /System/Library/Java/Support/CoreDeploy.bundle/Contents/Home/lib/security

Ответ 19

В моем случае файл JKS, используемый в клиентском приложении, был поврежден. Я создал новую и импортировал в нее SSL-сертификаты целевого сервера. Затем я использовал новый файл JKS в клиентском приложении в качестве хранилища доверия, например:

System.setProperty("javax.net.ssl.trustStore",path_to_your_cacerts_file);

Источник: Java SSL и хранилище сертификатов

Я использую инструмент (KeyStore Explorer) для создания нового JKS. Вы можете скачать его по этой ссылке, KeyStore Explorer.

Ответ 20

Вы также можете столкнуться с этой ошибкой после обновления до Spring Boot 1.4.1 (или новее), поскольку она вносит в Tomcat 8.5.5 часть своих зависимостей.

Проблема связана с тем, как Tomcat имеет дело с магазином доверия. Если вы, вероятно, указали местоположение своего хранилища доверия так же, как ваше хранилище ключей в конфигурации Spring Boot, вероятно, вы получите trustAnchors parameter must be non-empty при запуске приложения.

server.ssl.key-store=classpath:server.jks
server.ssl.trust-store=classpath:server.jks

Просто удалите конфигурацию server.ssl.trust-store если вы не знаете, что она вам нужна, и в этом случае обратитесь к ссылкам ниже.

Следующие проблемы содержат более подробную информацию о проблеме:

Ответ 21

У меня было это сообщение об ошибке на Java 9.0.1 в Linux. Это было связано с известной ошибкой JDK, где файл cacerts пуст в бинарном пакете.tar.gz (скачан с сайта http://jdk.java.net/9/).

См. Параграф "Известные проблемы" примечаний к выпуску JDK 9.0.1, в котором говорится, что "TLS не работает по умолчанию в OpenJDK 9".

В Debian/Ubuntu (и, возможно, другие производные) простым решением является замена файла cacerts на один из пакета ca-certificates-java:

sudo apt install ca-certificates-java
cp /etc/ssl/certs/java/cacerts /path/to/jdk-9.0.1/lib/security/cacerts

В Red Hat Linux/CentOS вы можете сделать то же самое из пакета "ca-certificates":

sudo yum install ca-certificates
cp /etc/pki/java/cacerts /path/to/jdk-9.0.1/lib/security/cacerts

Ответ 22

Я столкнулся с этой проблемой с Android SDK sdkmanager. Для меня это решение сработало:

  1. Перейдите в /usr/lib/jvm/java-8-oracle/jre/lib/security/
  2. Замените 'cacert' на 'cacert.original'

Файл "cacert" был крошечным (22B). Я установил oracle-java8-installer из ppa: webupd8team/java (в соответствии с этим руководством: https://docs.nativescript.org/start/ns-setup-linux).

Ответ 23

System.setProperty("javax.net.ssl.trustStore", "C:\\Users\\user-id\\Desktop\\tomcat\\cacerts");
System.setProperty("javax.net.ssl.trustStorePassword", "passwd");

Вы должны добавить две вышеуказанные строки в свой код. Он не может найти траст-магазин.

Ответ 24

Для записи ни один из ответов здесь не работал для меня. Моя сборка Gradle начала таинственно с этой ошибкой, неспособная извлечь HEAD из центра Maven для конкретного файла POM.

Оказалось, что у меня JAVA_HOME установлен в мою личную сборку OpenJDK, которую я создал для отладки javac-проблемы. Вернувшись к JDK, установленному на моей системе, это исправлено.

Ответ 25

Я столкнулся с этой проблемой при запуске определенного пакета Android для тестирования на Ubuntu 14.04 (Trusty Tahr). Две вещи работали для меня, как предложил шахин:

sudo update-ca-certificates -f

sudo /var/lib/dpkg/info/ca-certificates-java.postinst configure

Ответ 26

Ни один из решений, которые я нашел в Интернете, не работал, но модифицированная версия ответа Питера Кринса, похоже, выполняет эту работу.

Сначала найдите свою папку Java, запустив /usr/libexec/java_home. Для меня это была версия 1.6.0.jdk. Затем перейдите в свою подпапку lib/security (для меня /Library/Java/JavaVirtualMachines/1.6.0.jdk/Contents/Home/lib/security).

Затем удалите файл cacerts если он уже есть, и выполните поиск в системе с помощью sudo find / -name "cacerts". Он нашел несколько элементов для меня, в версиях Xcode или других приложений, которые я установил, а также в /Library/Internet Plug-Ins/JavaAppletPlugin.plugin/Contents/Home/lib/security/cacerts которые я выбрал.

Используйте этот файл и создайте для него символическую ссылку (в то время как внутри папки Java раньше), sudo ln -fsh "/Library/Internet Plug-Ins/JavaAppletPlugin.plugin/Contents/Home/lib/security/cacerts" и он должен работать.

У меня есть оба - Java от Apple 2017-001 скачать (https://support.apple.com/kb/dl1572 - я предполагаю, что там, где находятся правильные сертификаты) и Oracle one, установленный в Mac OS X v10.12 (Sierra),

Ответ 27

на Ubuntu 14.04 с openjdk 11 из ppa: openjdk-r/ppa это работало для меня:

в java.security измените тип хранилища ключей на

keystore.type=jks

затем:

sudo dpkg --purge --force-depends ca-certificates-java
sudo apt-get install ca-certificates-java

когда вы проверите, работает ли он, убедитесь, что вы не используете ни одного демона со старой запущенной java (например --no-daemon опция --no --no-daemon для gradle)

эта ошибка хорошо описывает все и поможет вам понять, что происходит на https://bugs.launchpad.net/ubuntu/+source/ca-certificates-java/+bug/1739631

Ответ 28

В Ubuntu 18.04 мне нужно было использовать OpenJDK 1.7 для поддержки старого проекта. Я скачал бинарный пакет. Но когда я выполнил свой сценарий, я получил ту же ошибку.

Решением было удалить файл cacerts загруженного JDK в папке jre/lib/security и затем создать его как символическую ссылку на файл системных cacerts в /etc/ssl/certs/java/:

sudo ln -s/etc/ssl/certs/java/cacerts/path/to/downloaded/java/jre/lib/security/cacerts

Ответ 29

Я столкнулся с проблемой при импорте проекта Gradle в IntelliJ IDEA 14. Решение использовало локальную копию Gradle вместо оболочки из каталога проекта.

Ответ 30

В Red Hat Linux я решил эту проблему решить, импортировав сертификаты в /etc/pki/java/cacerts.