Помилка - параметр trustAnchors повинен бути не порожнім

Я намагаюся налаштувати свою електронну пошту на Jenkins / Hudson, і я постійно отримую помилку:

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

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

Ось кілька речей, які я спробував. Я спробував дотримуватися порад з цієї публікації , але скопіювати каскадери з Windows на мій ящик Fedora, на якому розміщено Дженкінс, не вийшло. Я спробував дотримуватися цього посібника, коли я намагаюся налаштувати Gmail як мій SMTP-сервер, але він не працював. Я також намагався завантажувати та переміщувати ці файли cacert вручну та переміщувати їх у свою папку Java, використовуючи зміни команд у цьому посібнику .

Я відкритий до будь-яких пропозицій, оскільки зараз я застряг. Я змусив його працювати з сервером Хадсон Windows, але я борюся за 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-сертифікати-java від космічного (20180413ubuntu1)

🗹 Ubuntu 1769013: Об’єднайте ca-сертифікати-java 20180413 (головний) з Debian нестабільним (основним)

🗹 Ubuntu 1739631: свіжа установка з JDK 9 не може використовувати згенерований файл зберігання ключів PKCS12

🗹 -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-certificate-java/+bug/1396760 )

ca-certificates-java не є залежністю в JDK / JRE Oracle, тому це має бути явно встановлено.

У 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 в ОС X. Якщо ви працюєте з OpenJDK 7 в OS X і бачили цей виняток:

Unexpected error: java.security.InvalidAlgorithmParameterException: the trustAnchors
    parameter must be non-empty

Є просте виправлення. Просто посилання на той самий файл файлів, який використовує 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-сертифікатів-java . Якщо використовувати, ви -Djavax.net.ssl.trustStore=/etc/ssl/certs/java/cacertsотримаєте їх незалежно від того, який JDK ви використовуєте.

Я зіткнувся з цією точною проблемою на OS X, використовуючи JDK 1.7, після оновлення до OS X v10.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 .

У Windows я скопіював cacertsфайл з jre/lib/securityкаталогу Eclipse install (те саме місце, що і eclipse.iniфайл) і додав у налаштування наступні налаштування eclipse.ini:

-Djavax.net.ssl.trustStore=cacerts
-Djavax.net.ssl.trustStorePassword=changeit
-Djavax.net.ssl.trustStoreType=JKS

У мене виникли проблеми з доступом до касетів (змінна середовище% java_home% якось перезаписана), тому я використав це банальне рішення.

Ідея полягає у наданні дійсного шляху до файлу довіреного зберігання - в ідеалі було б використовувати відносний. Ви також можете використовувати абсолютний шлях.

Щоб переконатися, що тип магазину є JKS, слід виконати таку команду:

keytool -list -keystore cacerts

Keystore type: JKS
Keystore provider: SUN

Видалення пакета ca-сертифікатів-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-сертифікати-java не вдається встановити Java-касети на Oneiric Ocelot .

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

• Проблема SSL з Amazon AWS
• Peer не має автентичності Maven та Eclipse
• trustAnchors Параметр повинен бути не порожнім

Я застосував це оновлення Java, і воно вирішило всі мої проблеми: http://support.apple.com/kb/DL1572?viewlocale=uk_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, вона має іншу назву параметра, але шукає той самий файл зберігання ключів.

Для мене це було спричинене відсутністю довіреноїCertEntry в трастовому магазині.

Для тестування використовуйте:

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>

Тепер у нього надійнийCertEntry, і Tomcat почне успішно.

Деякі релізи постачальників OpenJDK спричинили це через те, що порожній cacertsфайл розподілявся з двійковим файлом. Помилка пояснюється тут: https://github.com/AdoptOpenJDK/openjdk-build/isissue/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-сертифікати-java, як хтось зазначив:

sudo apt install ca-certificates-java

У мене було повідомлення про помилку на Java 9.0.1 в Linux. Це було пов’язано з відомою помилкою JDK, де файл кесерів порожній у бінарному пакеті .tar.gz (завантажений з http://jdk.java.net/9/ ).

Дивіться пункт "відомі проблеми" Примітки до випуску JDK 9.0.1 , кажучи, що "TLS не працює за замовчуванням у OpenJDK 9".

У Debian / Ubuntu (і, мабуть, інших похідних) простий спосіб вирішити проблему - замінити файл cacerts на файл із пакету "ca-сертифікати-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-сертифікати":

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 показала, що файл моїх кекерів є символічним посиланням, що вказує на /etc/ssl/certs/java/cacerts .

У мене також був файл, підозріло названий cacerts.original.

Я перейменував cacerts.originalце cacerts, і це вирішило проблему.

Я також стикався з цим на OS X після оновлення OS X v10.9 (Mavericks), коли використовувався старий Java 6 і намагався отримати доступ до HTTPS URL. Виправленням було обернено Пітера Кріенса; Мені потрібно було скопіювати 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конфігурацію, якщо ви не знаєте, що вона вам потрібна, і в цьому випадку перегляньте посилання нижче.

Наступні випуски містять докладнішу інформацію про проблему:

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

Я зіткнувся з цією проблемою з Android SDK 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). Дві речі працювали для мене, як запропонував shaheen:

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.безпека зміни типу зберігання клавіш на

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-certificate-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 Image на 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"]