Ответ 1
Это странное сообщение означает, что указанный вами траст-сервер:
- пусто,
- не найдено, или
- не удалось открыть (из-за, например, прав доступа).
См. Также @AdamPlumb ответ ниже.
Я пытаюсь настроить электронную почту на 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.
Это странное сообщение означает, что указанный вами траст-сервер:
См. Также @AdamPlumb ответ ниже.
В 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)
🗹 docker-library 145: 9-jdk image имеет проблемы с SSL
🗹 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
и регенерировать его описанным выше способом.
Это исправило проблему для меня на 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, что и 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 могут добавить это в свои установочные скрипты.
В 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 версии 10.9 (Mavericks). Исправление, которое сработало для меня, было просто переустановить версию Java для Java, доступную по адресу http://support.apple.com/kb/DL1572.
Я побежал
sudo update-ca-certificates -f
для создания файла сертификата, а затем:
sudo /var/lib/dpkg/info/ca-certificates-java.postinst configure
Я вернулся в бизнес, спасибо, ребята. Жаль, что он не включен в установку, но я попал туда, в конце концов.
Ошибка говорит о том, что система не может найти 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
У меня было много проблем с безопасностью после обновления до OS X v10.9 (Mavericks):
trustAnchors
должен быть непустымЯ применил это обновление Java и исправил все мои проблемы: http://support.apple.com/kb/DL1572?viewlocale=en_US
Удаление пакета 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.
Я ожидал таких вещей, потому что я использую альтернативную 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 у нее есть другое имя параметра, но она ищет тот же файл хранилища ключей.
Для меня это было вызвано отсутствием 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 начнется успешно.
Если вы испытываете это на Ubuntu с JDK9 и Maven, вы можете добавить эту опцию JVM - сначала проверьте, существует ли путь:
-Djavax.net.ssl.trustStore=/etc/ssl/certs/java/cacerts
Если файл отсутствует, попробуйте установить ca-certificates-java, как заметил кто-то:
sudo apt install ca-certificates-java
У меня была эта проблема при попытке использовать 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
, и это исправило проблему.
В некоторых выпусках 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
Я также столкнулся с этим на 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
В моем случае файл JKS, используемый в клиентском приложении, был поврежден. Я создал новую и импортировал в нее SSL-сертификаты целевого сервера. Затем я использовал новый файл JKS в клиентском приложении в качестве хранилища доверия, например:
System.setProperty("javax.net.ssl.trustStore",path_to_your_cacerts_file);
Источник: Java SSL и хранилище сертификатов
Я использую инструмент (KeyStore Explorer) для создания нового JKS. Вы можете скачать его по этой ссылке, KeyStore Explorer.
Вы также можете столкнуться с этой ошибкой после обновления до 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
Я столкнулся с этой проблемой с Android SDK sdkmanager. Для меня это решение сработало:
Файл "cacert" был крошечным (22B). Я установил oracle-java8-installer из ppa: webupd8team/java (в соответствии с этим руководством: https://docs.nativescript.org/start/ns-setup-linux).
System.setProperty("javax.net.ssl.trustStore", "C:\\Users\\user-id\\Desktop\\tomcat\\cacerts");
System.setProperty("javax.net.ssl.trustStorePassword", "passwd");
Вы должны добавить две вышеуказанные строки в свой код. Он не может найти траст-магазин.
Для записи ни один из ответов здесь не работал для меня. Моя сборка Gradle начала таинственно с этой ошибкой, неспособная извлечь HEAD из центра Maven для конкретного файла POM.
Оказалось, что у меня JAVA_HOME установлен в мою личную сборку OpenJDK, которую я создал для отладки javac-проблемы. Вернувшись к JDK, установленному на моей системе, это исправлено.
Я столкнулся с этой проблемой при запуске определенного пакета Android для тестирования на Ubuntu 14.04 (Trusty Tahr). Две вещи работали для меня, как предложил шахин:
sudo update-ca-certificates -f
sudo /var/lib/dpkg/info/ca-certificates-java.postinst configure
Ни один из решений, которые я нашел в Интернете, не работал, но модифицированная версия ответа Питера Кринса, похоже, выполняет эту работу.
Сначала найдите свою папку 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),
на 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
В 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
Я столкнулся с проблемой при импорте проекта Gradle в IntelliJ IDEA 14. Решение использовало локальную копию Gradle вместо оболочки из каталога проекта.
В Red Hat Linux я решил эту проблему решить, импортировав сертификаты в /etc/pki/java/cacerts
.