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


492

Я пытаюсь настроить свою электронную почту на 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.

Ответы:


513

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

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

Смотрите также ответ @ 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

1
Спасибо, EJP, я видел твой пост здесь, но я не был уверен, как проверить, есть ли доверенное хранилище. Также я поднял свой файл server.xml, но я не был уверен, как проверить хранилище доверенных сертификатов. Должен ли я просто проверить параметр keystoreFile = "conf / .keystore" (keystoreFile в этом файле не было)?
Дэвид Гилл

2
Ответ был с тем, как я импортировал это. Казалось, я пропустил важный шаг. См. [Ошибка Java InvalidAlgorithmParameterException] [1] [1]: jyotirbhandari.blogspot.com/2011/09/…
Дэвид Гилл,

2
Подтвердил, что этот ответ правильный. Я получал ошибку под Tomcat. У меня был свой склад доверенных сертификатов, ${CATALINA_HOME}\confно CATALINA_HOMEон не был установлен, поэтому Tomcat искал \confхранилище доверенных сертификатов.
SingleShot

4
@BubblewareTechnology Нет, ошибка была в имени файла, а не в том, как вы импортировали сертификат в файл. Ваш блог не правильный. Вы также не должны рекомендовать изменять файл JRE $ / cacerts. Это изменится при следующем обновлении Java. Вам нужен процесс, который копирует его, добавляет свой собственный сертификат в копию и использует копию в качестве хранилища доверенных сертификатов. Повторите каждое обновление Java. И вам вообще не нужно рассказывать Java о собственном хранилище доверенных сертификатов, только о своем собственном, если оно отличается.
Маркиз Лорн

3
Я добавлю завихрение: даже когда хранилище доверенных сертификатов существует, доступно, имеет правильный формат, если оно ПОЛНОСТЬЮ ПУСТО, это ошибка, которую вы можете получить с различными библиотеками (включая Apache HttpClient).
Алан Францони

265

В 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файл и создайте его заново, как описано в последней строке сценария обхода в верхней части сообщения.


50
Ubuntu 18 пользователей, прочитайте это! это сэкономит много часов вашей жизни! Спасибо!
Вак

5
Этот ответ помог мне исправить ту же ошибку с maven в Ubuntu 18.04. Мне пришлось сменить владельца файла / etc / ssl / certs / java / cacerts с корневого на себя, чтобы иметь возможность писать в него. Затем я переключил его обратно.
Юрий Гор

77
Я запустил sudo rm / etc / ssl / certs / java / cacerts, а затем sudo update-ca-сертификаты -f, и это исправило мою проблему в kubuntu 18.04.
JSN

2
@jsn, спасибо за решения, работает и на Linux Mint 19, который основан на Ubuntu 18.04
Самрат

2
Решение @ jsn также сработало для Debian Stretch + openjdk8
HRJ

105

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


2
Спасибо, это исправило проблему, когда я столкнулся с ней в Ubuntu 15.04.
Macil

Работал над Raspbian на Raspberry Pi
Defozo

1
Столкнулся с этой проблемой со стабильными бэкпортами Debian jesse с OpenJDK8, и это решило проблему. Использовал это при создании образов Docker. :)
Tuxdude

9
К сожалению, не работает на Ubuntu MATE 18.04. Я попробую переустановить Java.
Пранав А.

1
@codefx - я сделал то, что вы предлагаете, и это не работает - на Ubuntu 18.x с Java 10 (по умолчанию).
mzedeler

69

В 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

Это описание фактически неверно и устраняет проблему только в том смысле, в котором переустановка Windows может решить проблему. Нет необходимости удалять все пакеты Java. Если вы хотите пойти по этому пути, вам нужно только установить openjdk-8-jdkпакет, удалить /etc/ssl/certs/java/cacertsфайл и запустить, sudo update-ca-certificates -fчто является окольным способом переключения с pkcs12отформатированного файла Cacerts на jksотформатированный, как описано в другом месте в этой теме.
Микаэль Гек

1
@MikaelGueck Хотя логика, кажется, на вашей стороне, я здесь, чтобы заверить вас, что ранее я сделал именно то, что описано в вашем комментарии и в большинстве других проголосовавших ответов, и в 18.04 это единственный ответ, который сработал . Я думаю, что ваш отрицательный голос должен превратиться в повышенный или, по крайней мере, исчезнуть, поскольку он совершенно не заслужен.
Андреа Лигиос

@AndreaLigios, вы можете сами прочитать сценарии, они довольно короткие. У них есть жестко заданный набор путей JAVA_HOME от 8 до 10, они пробуют их по одному, они вызывают генератор файлов Debian CA, который вы также можете прочитать, который использует существующий формат файла, потому что код обработчика ключевого файла JDK, который Вы можете прочитать, есть режим совместимости резервный. Если ваш компьютер запускает это простое программное обеспечение по-другому, у вас могут быть другие проблемы с ним. Вы изменили свои альтернативы Java и вызвали какую-то другую JVM, потому что тогда удаление могло сбросить альтернативы?
Микаэль Гек

1
@MikaelGueck да, в одной из предыдущих попыток я изменил свои альтернативы java, так что, вероятно, так оно и было. Я первый, кто любит копаться в исходном коде и узнавать, как все работает, но сегодня это не было моей целью, это было всего лишь одно из 5-6 различных неожиданных препятствий, которые я встретил на пути к своей настоящей цели. Этот ответ позволил мне решить проблему менее чем за 2 минуты! Сколько времени я должен уделить изучению сценариев и поиску лучшего решения? И для чего, чтобы сэкономить несколько мегабайт? Это радикально, но работает (и неважно, в чем проблема), поэтому большое спасибо ОП за тех, кто занят адом
Андреа Лигиос

1
Я искал решение в течение 2 дней, и ваш ответ решил мою проблему, спасибо. Я просто перехожу на Kubuntu 18.04, это сработало.
Гепардомар

55

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

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

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


ну, я помогу вам увековечить решение вашей проблемы. вот где это становится интересным.
n611x007,

2
Это была именно моя проблема. Я использовал Spring Boot 1.4.2.RELEASE и имел аппаратное хранилище ключей и программное доверенное хранилище. Я указал провайдера и тип хранилища ключей, но не хранилище доверенных сертификатов. В результате неправильный поставщик и тип использовались складом доверенных сертификатов. Указание тех (SUN и JKS) решило проблему.
Кенко

12
как именно ты это сделал? (окна здесь)
Тацу

2
Познакомьтесь с моим Android-грандиозом сегодня, я почти понимаю, что вы говорите, но вы не говорите, как это решить. Бесполезный ответ
Лотар

52

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


1
Моя команда "ln" (в OSX 10.6.8) не имеет опции "h"; что это значит делать?
Эндрю Свон

1
У меня было две команды "ln", одна в / usr / bin (по умолчанию) и одна в / bin; последний имел вариант «h» и работал.
Эндрю Свон

Я исправил сломанную установку 1.6, связанную с установками из системы 1.8, используя эту технику ln. Спасибо!
A21z

1
Для читателей в будущем: кажется , что вы также должны другие 3 файлов , которые находятся в securityпапке ( blacklisted.certs, local_policy.jarи US_export_policy.jar) для Java , чтобы быть счастливыми.
awksp

@Peter Кринса, почему связанно cacertsпод jreкаталогом?
BAE

45

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


54
Я обнаружил, что мне нужно запустить update-ca-certificates -fвручную, чтобы заполнить файл cacerts
Portablejim

4
@Portablejim Спасибо. Ваш комментарий решил первую проблему, с которой я столкнулся при сборке Apache Spark в Ubuntu 15.04beta.
Пол

1
Спасибо тебе @Portablejim, твой комментарий работал на меня в Ubuntu 15.04.
Дэвид Берг

Спасибо. Это исправило мою проблему с исправленным PhpStrom + JDK. Я записал этот ключ в файл "phpstorm64.vmoptions".
Виджит

У меня не работает в Ubuntu 18.04 и JDK 1.8.0_62
Devendra Singraul

34

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


Я столкнулся с этим с Java 6, используемой Grails на OSX. У меня также была установлена ​​Java 7 от Oracle, а также обновлен до Mavericks. Переустановка Java 6 с сайта Apple также устранила проблему для меня.
pm_labs

Столкнулся с этим при установке open jdk 6 на облачный ящик Ubuntu. Приятно видеть знакомое лицо, кстати
Бен Хатчисон

30

Я побежал

sudo update-ca-certificates -f

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

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

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


Когда я бегу, sudo /var/lib/dpkg/info/ca-certificates-java.postinst configure**я получаюsudo: /var/lib/dpkg/info/ca-certificates-java.postinst: command not found
Magick

Достаточно просто sudo update-ca-certificates -fна Debian jessie with openjdk-8-jre-headlessиз jessie-backports, если ca-certificates-javaон установлен. Я думаю, порядок установки имеет значение (JRE после ca-certificates-javaможет вызвать это, так как последний не имеет никаких триггеров для бэкпортируемой Java 8).
Мирабилось

2
sudo /var/lib/dpkg/info/ca-certificates-java.postinst configure без звезд **
Ю Цзяо

update-ca-certificates -fэто то, что исправило это. Мне не нужно было 2-й команды
Марк Jeronimus

17

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

2
Это единственный ответ, который действительно сработал. Спасибо @razvanone
Патель

1
Мне удалось поразить одну маленькую «ошибку»: три строки в файле eclipse.ini должны быть на трех отдельных строках. Сначала я поместил их все в одну строку, и затмение не подняло это.
SiKing

16

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


11

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

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

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


5
Тьфу. Java 6 уже давно не имеет публичной поддержки и, конечно, полна дыр в безопасности. Apple делает его доступным для загрузки, так что старое программное обеспечение, которое не может быть запущено с Java 7/8, может продолжать работать, но его не следует использовать для создания соединений SSL со службами в общедоступном Интернете, такими как 1. AWS, 2. Maven Центральный, 3. все остальное.
Зак Томпсон

10

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


4
Откуда вы взяли собственность javax.net.ssl.trustAnchors? Это не упомянуто в документации JSSE.
Маркиз Лорн

10

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


Обратите внимание на учебник по Baeldung с полезным Makefile в качестве ярлыка для создания хранилища ключей и хранилища доверенных сертификатов (проект spring-security-x509) baeldung.com/x-509-authentication-in-spring-security
hello_earth

9

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


Я думаю, что это был случай и для меня. В AdoptOpenJDK 202 эта ошибка присутствует, а в 222 она работает. Так что обновите свой JDK, если это возможно.
Марти

6

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

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

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

sudo apt install ca-certificates-java

Если вы используете докер, то вы также можете попробовать изображение «maven: 3-jdk-9-slim» вместо «maven: 3-jdk-9»
Константин Павлов

Спасибо, это сработало для меня для openjdk-8-jdk в Ubuntu 18.04
Aftab Naveed

4

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

4

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


cacerts.originalФайл был в jksформате, и был создан с Ubuntu 16.04 в Java 8, в котором используется этот формат , как по умолчанию. cacertsФайл был в pkcs12формате, генерируемой Ubuntu 18.04 это Java 10, который использует этот формат , как по умолчанию. Как объяснено в другом месте в этой теме, новый формат требует, чтобы вы передали пароль исполняемому файлу. Но до тех пор, пока вы создаете новый пустой jks cacertsфайл или копируете старый, процесс генерации следующего каскаса будет очищать существующий файл и пополнять его сертификатами CA из файловой системы.
Микаэль Гек

3

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

1
Команда здесь пытается скопировать каталог в файл; не имеет никакого смысла вообще.
празеодим

Я согласен с оценкой использования обратного решения. Я обнаружил, что у jdk1.6 была сломана мягкая ссылка / Содержание / Главная / Библиотека / безопасность / cacerts. Итак, я нашел сломанную программную ссылку, а затем скопировал файлы с установкой jdk1.7.
Джеймс Уилсон

ПРИМЕЧАНИЕ: когда вы закончите, вы сможете отследить файл cacerts, который вы скопировали, чтобы проверить разрешения.
Серый

Кроме того, исправил cp, чтобы идти в правильном направлении, и добавил umask для mkdir и cp.
Серый

3

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

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

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

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


keystore-explorer сделал всю работу за меня. Вам просто нужно создать хранилище ключей по умолчанию, изучить и сохранить файл сертификата для сайта / хоста.
Шанта Кумара

3

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

Я столкнулся с этой проблемой с 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 ).


2

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

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


... что привело к тому, что склад доверенных сертификатов не был найден, как в других ответах.
Маркиз Лорн

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

Все они «происходят» как одна и та же ошибка: указанное хранилище доверенных сертификатов не может быть открыто или пусто. Существует миллион способов возникновения такой ситуации, и на SO недостаточно места, чтобы перечислить их все.
Маркиз Лорн

1

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


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

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


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

Правильный способ установить эти свойства - передать их в командной строке: java -Djavax.net.ssl.trustStore=/tmp/cacerts ...или, если вы хотите установить их глобально для всех программ, запускаемых с JDK, добавьте строку в management.propertiesфайл JDK .
Микаэль Гек

1

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

sudo update-ca-certificates -f

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

1

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

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


1

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


1

В 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


1

Небольшой шанс, что это поможет кому-то, но ... для всех, кто работает под управлением 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"]
Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.