Ошибка - параметр trustAnchors должен быть не пустым
Я пытаюсь настроить свою электронную почту на Jenkins/Hudson, и я постоянно получаю сообщение об ошибке:
java.security.InvalidAlgorithmParameterException: the trustAnchors parameter must be
non-empty
Я видел много информации в Интернете об ошибке, но я не получил никакой работы. Я использую JDK от Sun в Fedora Linux (не OpenJDK).
Вот несколько вещей, которые я попробовал. Я попытался последовать совету из этого поста, но копирование cacerts из Windows на мой ящик Fedora с хостингом Jenkins не сработало. Я попытался следовать этому руководству, поскольку я пытаюсь настроить Gmail в качестве SMTP-сервера, но он тоже не работает. Я также попытался загрузить и переместить эти файлы cacert вручную и переместить их в свою папку Java, используя различные команды в этом руководстве.
Я открыт для любых предложений, так как сейчас я застрял. Я получил его на работу с сервера Windows Hudson, но я борюсь с Linux.
49 ответов
Это странное сообщение означает, что указанное вами хранилище доверенных сертификатов было:
- пусто,
- не найден или
- не может быть открыт (например, из-за прав доступа).
В Ubuntu 18.04 эта ошибка имеет другую причину (JEP 229, переключиться с jks Формат хранилища ключей по умолчанию pkcs12 формат и создание файла Debian cacerts с использованием по умолчанию для новых файлов) и обходного пути:
# 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-Certificates-Java из космического пространства (20180413ubuntu1)
docker-library 145: образ 9-jdk имеет проблемы с SSL
JDK-8044445: JEP 229: создание хранилищ ключей PKCS12 по умолчанию
JEP 229. Создание PKCS12 Keystores по умолчанию
Если проблема не устраняется после этого обходного пути, возможно, вы захотите убедиться, что на самом деле вы используете только что исправленный дистрибутив 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 файл и восстановить его в порядке, описанном ранее.
Это исправило проблему для меня в 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, поэтому она должна быть явно установлена.
В 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
EJP в основном ответил на вопрос (и я понимаю, что у него есть принятый ответ), но я только что имел дело с этим крайним случаем и хотел увековечить свое решение.
У меня была ошибка InvalidAlgorithmParameterException на размещенном сервере Jira, который я ранее настроил для доступа только по SSL. Проблема была в том, что я настроил хранилище ключей в формате PKCS#12, но хранилище доверенных сертификатов было в формате JKS.
В моем случае я отредактировал свой файл server.xml, чтобы указать keystoreType для PKCS, но я не указал truststoreType, поэтому по умолчанию используется значение keystoreType. Я указал truststoreType явно, поскольку JKS решил это для меня.
Я столкнулся с этим решением из поста в блоге. Исправление проблемы 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, который использует Apple 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 могли бы добавить это в свои сценарии установки.
В Ubuntu 12.10 (Quantal Quetzal) или более поздних версиях сертификаты хранятся в пакете ca-certificate-java. С помощью -Djavax.net.ssl.trustStore=/etc/ssl/certs/java/cacerts подберут их независимо от того, какой JDK вы используете.
Я столкнулся с этой проблемой на OS X, используя JDK 1.7, после обновления до OS X v10.9 (Mavericks). Исправление, которое работало для меня, состояло в том, чтобы просто переустановить версию Java для Apple, доступную по адресу http://support.apple.com/kb/DL1572.
Ошибка говорит о том, что система не может найти склад доверенных сертификатов по пути, указанному в параметре javax.net.ssl.trustStore,
Под виндой я скопировал 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
Я побежал
sudo update-ca-certificates -f
создать файл сертификата, а затем:
sudo /var/lib/dpkg/info/ca-certificates-java.postinst configure
Я вернулся в бизнес, спасибо, ребята. Жаль, что он не включен в установку, но я попал туда в итоге.
Удаление пакета 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.
Для меня это было вызвано отсутствием trustCertEntry в хранилище доверенных сертификатов.
Чтобы проверить, используйте:
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>
Теперь у него есть trustCertEntry, и Tomcat запустится успешно.
В windows10 и openjdk было вызвано наличие пустого файла cacerts, распространяемого вместе с двоичным файлом. Ошибка объясняется здесь: 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
У меня было много проблем с безопасностью после обновления до OS X v10.9 (Mavericks):
- Проблема SSL с Amazon AWS
- Пир не аутентифицирован с Maven и Eclipse
trustAnchorsпараметр должен быть не пустым
Я применил это обновление Java, и оно исправило все мои проблемы: http://support.apple.com/kb/DL1572?viewlocale=en_US
Я ожидал таких вещей, потому что я использую альтернативную 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, он имеет другое имя параметра, но ищет тот же файл хранилища ключей.
Если вы испытываете это в Ubuntu с JDK9 и Maven, вы можете добавить эту опцию JVM - сначала проверьте, существует ли путь:
-Djavax.net.ssl.trustStore=/etc/ssl/certs/java/cacerts
Если файл отсутствует, попробуйте установить CA-Certificates-Java, как кто-то заметил:
sudo apt install ca-certificates-java
Вы также можете столкнуться с этой ошибкой после обновления до 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 конфигурации, если вы не знаете, что вам это нужно, в этом случае обратитесь к ссылкам ниже.
Следующие проблемы содержат более подробную информацию о проблеме:
У меня было это сообщение об ошибке на 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
Я фанат переносимости, поэтому я не устанавливаю java, просто загружаю tar.gz и экспортирую некоторые значения в путь, и все работает.
Я боролся с этой проблемой, и ни одно решение (установка или обновление сертификатов операционных систем) не помогло мне.
Ошибка в моем случае была очевидна: пустые файлы cacerts внутри моего jdk.
Не знаю почему, но у моего jdk.tar.gz был пустой файл cacerts
/../some_openjdk/jre/lib/security/cacerts: 32 байта
Загружено с:
- https://download.java.net/openjdk/jdk8u41/ri/openjdk-8u41-b04-linux-x64-14_jan_2020.tar.gz
- https://download.java.net/java/GA/jdk9/9/binaries/openjdk-9_linux-x64_bin.tar.gz
Исправить
После нескольких попыток я нашел правильный jdk.tar.gz с файлом cacerts размером 101 КБ.
Я загрузил этот открытый jdk с https://github.com/AdoptOpenJDK/openjdk8-upstream-binaries/releases
Я нашел этот URL в этом Dockerfile:
В моем случае файл JKS, используемый в клиентском приложении, был поврежден. Я создал новый и импортировал в него SSL-сертификаты конечного сервера. Затем я использовал новый JKS-файл в клиентском приложении в качестве хранилища доверия, например:
System.setProperty("javax.net.ssl.trustStore",path_to_your_cacerts_file);
Источник: Java SSL и хранилище ключей сертификатов
Я использую инструмент (KeyStore Explorer) для создания нового JKS. Вы можете скачать его по этой ссылке, KeyStore Explorer.
У меня была эта проблема при попытке использовать 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и это решило проблему.
Я столкнулся с этой проблемой с SDK Android SDKManager. Для меня это решение сработало:
- Перейдите в /usr/lib/jvm/java-8-oracle/jre/lib/security/
- Заменить "cacert" на "cacert.original"
Файл cacert был крошечным (22B). Я установил oracle-java8-installer из ppa:webupd8team/java (согласно этому руководству: https://docs.nativescript.org/start/ns-setup-linux).
Я также столкнулся с этим в OS X после обновления OS X v10.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
Ответ Маркиза Лорна точен, я добавляю информацию для отладки:
Чтобы отладить эту проблему (я писал об этом подробнее здесь) и понять, какой доверенный магазин используется (или пытается его использовать), вы можете добавить свойство javax.net.debug=all, а затем отфильтровать журналы о доверенном магазине. Вы также можете поиграть со свойством javax.net.ssl.trustStore, чтобы указать конкретное хранилище доверенных сертификатов. Например:
java -Djavax.net.debug=all -Djavax.net.ssl.trustStore=/Another/path/to/cacerts -jar test_get_https-0.0.1-SNAPSHOT-jar-with-dependencies.jar https://www.calca.com.py 2>&1| grep -i truststore
System.setProperty("javax.net.ssl.trustStore", "C:\\Users\\user-id\\Desktop\\tomcat\\cacerts");
System.setProperty("javax.net.ssl.trustStorePassword", "passwd");
Вы должны добавить две вышеупомянутые строки в свой код. Не удается найти склад доверенных сертификатов.
В Red Hat Linux я решил эту проблему, импортировав сертификаты в /etc/pki/java/cacerts,
Для справки, ни один из ответов здесь не работал для меня. Моя сборка Gradle стала таинственной сбоем из-за этой ошибки, из-за которой я не смог извлечь HEAD из Maven central для определенного файла POM.
Оказалось, что JAVA_HOME настроен на мою личную сборку OpenJDK, которую я создал для отладки проблемы с javac. Установка его обратно в JDK, установленный в моей системе, исправила это.
Небольшой шанс, что это поможет кому угодно, но... для всех, кто запускает Java 8 из образа Docker на Raspberry Pi (с использованием процессора AMD), у меня есть следующий файл Dockerfile, который будет успешно создан и запущен для меня
FROM hypriot/rpi-java
USER root
WORKDIR /usr/build/
RUN /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
RUN update-ca-certificates -f
RUN /var/lib/dpkg/info/ca-certificates-java.postinst configure
EXPOSE 8080
ARG JAR_FILE=target/app-0.0.1-SNAPSHOT.jar
ADD ${JAR_FILE} app.jar
ENTRYPOINT ["java", "-Djavax.net.ssl.trustStorePassword=changeit", "-Djavax.net.ssl.trustStore=/etc/ssl/certs/java/cacerts", "-jar", "app.jar"]
В 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
Попасть в это можно с помощью Amazon SDK v2, Windows 10 и JDK8.
Amazon SDK жаловался на загрузку учетных данных.
Я решил это, заменивsecurity/cacert файл JDK8 на файл JDK11.