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

Это странное сообщение означает, что указанный вами траст-сервер:

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

См. Также ответ @ 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)

🗹 Ubuntu 1769013: Пожалуйста, объедините ca-certificates-java 20180413 (main) из Debian unstable (main)

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

🗹 docker-library 145: 9-jdk image имеет проблемы с SSL

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

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

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

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

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

В 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 

Я столкнулся с этим решением из сообщения в блоге Исправлена ​​проблема 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, который использует JDK 1.6 от Apple:

 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-certificates-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 

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

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

• Проблема с SSL с Amazon AWS
• Peer не аутентифицирован 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 ie TOS_DI...ini) Djavax.net.ssl.trustStore=/etc/ssl/certs/java/cacerts 

Для меня вторая работа. Я думаю, в зависимости от версии Talend Open Studio / TEnt + JVM у нее есть другое имя параметра, но она ищет тот же файл хранилища ключей.

Ошибка говорит о том, что система не может найти 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 

Для меня это было вызвано отсутствием 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):  root-ca1, 04-Aug-2017, trustedCertEntry, Certificate fingerprint (SHA1):  

Теперь у него есть trustedCertEntry, и Tomcat начнется успешно.

Удаление пакета 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: Комментарий 1 для ошибки 983302, Re: ca-certificates-java не может установить Java cacerts в Oneiric Ocelot .

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

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

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

В моем случае файл 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.key-store=classpath:server.jks server.ssl.trust-store=classpath:server.jks 

Просто удалите конфигурацию server.ssl.trust-store если вы не знаете, что она вам нужна, и в этом случае обратитесь к ссылкам ниже.

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

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

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

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

Файл «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"); 

Вы должны добавить две вышеуказанные строки в свой код. Он не может найти траст-магазин.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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