Ошибка - параметр 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.

Это странное сообщение означает, что указанное вами хранилище доверенных сертификатов было:

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

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

Чтобы устранить эту проблему (я писал об этом здесь ) и понять, какое хранилище доверенных сертификатов используется, вы можете добавить свойство 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

В 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

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

🗹 Ubuntu 1770553: [SRU] backport ca-Certificates-Java из космического пространства (20180413ubuntu1)

🗹 Ubuntu 1769013: пожалуйста, объедините ca-certificate-java 20180413 (main) с нестабильным Debian (main)

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

Cker docker-library 145: образ 9-jdk имеет проблемы с SSL

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

🗹 JDK-8044445: JEP 229: создание хранилищ ключей PKCS12 по умолчанию

🖺 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, который использует 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 .

Я побежал

sudo update-ca-certificates -f

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

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

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

Ошибка говорит о том, что система не может найти склад доверенных сертификатов по пути, указанному в параметре 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

Удаление пакета 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 .

У меня было много проблем с безопасностью после обновления до 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, он имеет другое имя параметра, но ищет тот же файл хранилища ключей.

Для меня это было вызвано отсутствием 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 запустится успешно.

Некоторые релизы поставщиков 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

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

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

Если файл отсутствует, попробуйте установить CA-Certificates-Java, как кто-то заметил:

sudo apt install ca-certificates-java

У меня было это сообщение об ошибке на 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

У меня была эта проблема при попытке использовать 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, и это решило проблему.

Я также столкнулся с этим в 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

В моем случае файл 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конфигурацию, если вы не знаете, что она вам нужна, и в этом случае обратитесь по ссылкам ниже.

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

• Разъем HTTPS Tomcat не запускается с 1.4.1 # 7069
• Перестал работать SSL-client-auth с самоподписанным сертификатом # 7406
• Обновление до Tomcat 8.5.5 # 6703

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

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

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

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

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

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

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

Вы должны добавить две вышеупомянутые строки в свой код. Не удается найти склад доверенных сертификатов.

Я столкнулся с этой проблемой при запуске определенного набора 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, установленная на 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опция для 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

Небольшой шанс, что это поможет кому-то, но ... для всех, кто работает под управлением 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"]