it-roy-ru.com

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

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

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

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

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

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

406
David Gill

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

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

См. Также @/AdamPlumb's answer ниже .

429
user207421

В 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


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


???? Ubuntu 1770553: [SRU] обратный порт CA-Certificates-Java от космического (20180413ubuntu1)

???? Ubuntu 1769013: Пожалуйста, объедините CA-Certificates-Java 20180413 (основной) с нестабильной (основной) Debian

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

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

???? Debian 894979: ca-Certificates-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 и создайте его заново, как описано выше.

230
Mikael Gueck

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

96
Michael Condouris

В 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
57
shvahabi

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

50
Peter Kriens

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

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

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

50
Adam Plumb

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

37
yvesr

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

33
KiwiMartin

Я побежал

Sudo update-ca-certificates -f

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

Sudo /var/lib/dpkg/info/ca-certificates-Java.postinst configure

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

25
Johnny

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

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

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

10
Freddy Boucher

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

8
muttonUp

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

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

8
steveoams

Удаление пакета ca-Certificates-Java и его установка снова работали для меня ( Ubuntu MATE 17.10 (Artful Aardvark)).

Sudo dpkg --purge --force-depends ca-certificates-Java

Sudo apt-get install ca-certificates-Java

Спасибо, jdstrand: Comment 1 за ошибку 983302, Re: ca-Certificates-Java не удается установить Java cacerts на Oneiric Ocelot.

7
ericek111

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

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

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

Sudo apt install ca-certificates-Java
4
dmatej

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

4
John Deverall

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

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

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

3
Robert Hunt

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

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

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

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

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

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

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

2
Divyesh Kalbhor

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

  1. Перейдите в/usr/lib/jvm/Java-8-Oracle/jre/lib/security /
  2. Заменить «cacert» на «cacert.original»

Файл 'cacert' был крошечным (22B). Я установил Oracle-Java8-инсталлятор из ppa: webupd8team/Java (согласно этому руководству: https://docs.nativescript.org/start/ns-setup-linux ). 

2
Tyg

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

Сначала найдите вашу папку 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 10.12 (Сьерра).

1
shw

В 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

1
raisercostin

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

Sudo update-ca-certificates -f

Sudo /var/lib/dpkg/info/ca-certificates-Java.postinst configure
1
DPKGRG

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

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

1
user3562927

Еще одна причина этого - это действительная ошибка. Некоторые гнусные точки доступа Wi-Fi будут портиться с сертификатами и атака "человек посередине" вам делать, кто что знает (убегайте!).

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

0
Matt Broekhuis

На Ubuntu:

Судо может установить CA-сертификаты-Java

или же

Sudo apt-get установить ca-сертификаты-Java

отсортировал это для меня.

0
The Tomahawk

Я получил эту ошибку, когда использовал склад доверенных сертификатов, который был экспортирован с помощью инструмента ключей IBM Websphere JDK в формате # PKCS12, и пытался установить связь через SSL с помощью этого файла в Oracle JRE.

Моим решением было запустить IBM JRE или преобразовать склад доверенных сертификатов в JKS с помощью инструмента ключей IBM Websphere, поэтому я смог запустить его в Oracle JRE.

0
Maarten

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

0
Sergey Filkin

На самом деле вам нужно всего лишь выполнить:

Sudo chmod +x ./gradlew(your script)
0
Begin2Pip

на 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

0
piotrek

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

0
ak1

Я получаю ту же ошибку при отправке электронных писем, но НЕ всегда. В моем случае я изменил одну строку кода, чтобы каждый раз получать новый объект Session :

MimeMessage message = new MimeMessage(Session.getDefaultInstance(props, authenticator));

в

MimeMessage message = new MimeMessage(Session.getInstance(props, authenticator));

С тех пор отправка электронной почты работает каждый раз.

Ошибка, которую я получил:

javax.mail.MessagingException: не удалось преобразовать сокет в TLS; 
Вложенное исключение: javax.net.ssl.SSLException: 
Java.lang.RuntimeException: непредвиденная ошибка: 
Java.security.InvalidAlgorithmParameterException: trustAnchors 
параметр должен быть непустым в 
com.Sun.mail.smtp.SMTPTransport.startTLS (SMTPTransport.Java:1907) в 
com.Sun.mail.smtp.SMTPTransport.protocolConnect (SMTPTransport.Java:666) 
на javax.mail.Service.connect (Service.Java:317) на 
javax.mail.Service.connect (Service.Java:176) в 
javax.mail.Service.connect (Service.Java:125) в 
javax.mail.Transport.send0 (Transport.Java:194) в 
javax.mail.Transport.send (Transport.Java:124) 

0
marioosh

Для меня это удалось решить, просто обновив плагин Jenkins «Плагин расширения электронной почты» до последней версии (2.61).

Эти два плагина отвечают за настройку электронной почты в Jenkins:

  • Расширение электронной почты
  • Шаблон расширения электронной почты
0
himanshu vyas