Błąd - parametr trustAnchors musi być niepusty

Próbuję skonfigurować pocztę e-mail w witrynie Jenkins / Hudson i ciągle otrzymuję błąd:

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

Widziałem sporo informacji online na temat błędu, ale nie udało mi się nic zrobić. Używam JDK firmy Sun w systemie Fedora Linux (nie w OpenJDK).

Oto kilka rzeczy, których próbowałem. Próbowałem postępować zgodnie z radami zawartymi w tym poście , ale kopiowanie cacertów z systemu Windows na moją skrzynkę Fedory obsługującą Jenkins nie działało. Próbowałem postępować zgodnie z tym przewodnikiem , próbując skonfigurować Gmaila jako mój serwer SMTP, ale też nie działał. Próbowałem także ręcznie pobrać i przenieść te pliki cacert i przenieść je do mojego folderu Java, używając różnych poleceń w tym przewodniku .

Jestem otwarty na wszelkie sugestie, ponieważ obecnie utknąłem. Mam go do pracy z serwerem Windows Hudson, ale walczę z Linuksem.

Ten dziwny komunikat oznacza, że ​​określony przez Ciebie magazyn zaufanych certyfikatów to:

• pusty,
• nie znaleziono, lub
• nie można otworzyć (na przykład ze względu na uprawnienia dostępu).

Zobacz także odpowiedź @ AdamPlumb poniżej .

Aby debugować ten problem (pisałem o tym tutaj ) i zrozumieć, jaki jest używany magazyn zaufanych certyfikatów, możesz dodać właściwość javax.net.debug = all, a następnie przefiltrować dzienniki dotyczące magazynu zaufanych certyfikatów. Możesz także grać z właściwością javax.net.ssl.trustStore, aby określić konkretny magazyn zaufanych certyfikatów. Na przykład :

    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

W Ubuntu 18.04 ten błąd ma inną przyczynę (JEP 229, przejście z jksdomyślnego formatu magazynu kluczy do pkcs12formatu, a generowanie plików Debiana przy użyciu domyślnego formatu dla nowych plików) i obejście :

# 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

Status (2018-08-07) , błąd został naprawiony w Ubuntu Bionic LTS 18.04.1 i Ubuntu Cosmic 18.10.

🗹 Ubuntu 1770553: [SRU] backport ca-certyfikaty-java z kosmicznego (20180413ubuntu1)

🗹 Ubuntu 1769013: Proszę połączyć ca-certyfikaty-java 20180413 (główne) z niestabilnej Debiana (główna)

🗹 Ubuntu 1739631: Świeża instalacja z JDK 9 nie może korzystać z wygenerowanego pliku kluczy cacerts PKCS12

🗹 docker -library 145: 9-jdk image ma problemy z SSL

🗹 Debian 894979: ca-certyfikaty-java: nie działa z OpenJDK 9, aplikacje nie działają z InvalidAlametermParameterException: parametr trustAnchors musi być niepusty

🗹 JDK-8044445: JEP 229: Domyślnie twórz magazyny kluczy PKCS12

🖺 JEP 229: Domyślnie twórz magazyny kluczy PKCS12

Jeśli problem nadal występuje po tym obejściu, możesz upewnić się, że faktycznie uruchomiłeś właśnie naprawioną dystrybucję Java.

$ which java
/usr/bin/java

Możesz ustawić alternatywy Java na „auto” za pomocą:

$ sudo update-java-alternatives -a
update-alternatives: error: no alternatives for mozilla-javaplugin.so

Możesz dokładnie sprawdzić wykonywaną wersję 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)

Istnieją również alternatywne obejścia, ale mają one swoje skutki uboczne, które będą wymagały dodatkowej konserwacji w przyszłości, bez żadnych korzyści.

Kolejnym najlepszym obejściem jest dodanie wiersza

javax.net.ssl.trustStorePassword=changeit

do plików

/etc/java-9-openjdk/management/management.properties
/etc/java-11-openjdk/management/management.properties

cokolwiek istnieje.

Trzecim najmniej problematycznym obejściem jest zmiana wartości

keystore.type=pkcs12

do

keystore.type=jks

w plikach

/etc/java-9-openjdk/security/java.security
/etc/java-11-openjdk/security/java.security

cokolwiek istnieje, a następnie usuń cacertsplik i ponownie wygeneruj go w sposób opisany w ostatnim wierszu skryptu obejścia u góry postu.

To rozwiązało problem dla mnie na Ubuntu:

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

(znaleziono tutaj: https://bugs.launchpad.net/ubuntu/+source/ca-certificates-java/+bug/1396760 )

ca-certificates-java nie jest zależnością w Oracle JDK / JRE, więc należy to jawnie zainstalować.

W Ubuntu 18.04 główną przyczyną jest konflikt między openjdk-11-jdk (który jest domyślny) i innymi pakietami zależnymi od niego. Zostało to już naprawione w Debianie i wkrótce zostanie dołączone do Ubuntu. Tymczasem najprostszym obejściem jest obniżenie java do wersji 8. Inne stosowane rozwiązania ca-certificates-javasą znacznie bardziej skomplikowane.

Najpierw usuń konfliktowe pakiety:

sudo apt-get remove --purge openjdk* java-common default-jdk
sudo apt-get autoremove --purge

Sprawdź, czy pomyślnie usunąłeś wszystkie powiązane pakiety, wykonując:

sudo update-alternatives --config java

System wyświetli monit o brak Java do skonfigurowania , w przeciwnym razie to obejście nie powiedzie się .

Następnie zainstaluj ponownie wymagane pakiety:

sudo apt-get install openjdk-8-jdk

EJP w zasadzie odpowiedział na pytanie (i zdaję sobie sprawę, że ma to zaakceptowaną odpowiedź), ale właśnie poradziłem sobie z tą przypadkową gotcha i chciałem uwiecznić moje rozwiązanie.

Miałem InvalidAlgorithmParameterExceptionbłąd na hosted Jira serwerze, który miałem wcześniej skonfigurowana dla dostępu SSL-only. Problem polegał na tym, że skonfigurowałem swój magazyn kluczy w formacie PKCS # 12, ale mój magazyn zaufania był w formacie JKS.

W moim przypadku edytowałem server.xmlplik, aby określić typ pliku kluczy do PKCS, ale nie określiłem typu pliku zaufanego certyfikatu, więc domyślnie jest to dowolny typ pliku kluczy. Określenie typu truststoreType jawnie, ponieważ JKS go dla mnie rozwiązał.

Natrafiłem na to rozwiązanie z posta na blogu Natrafiłem Naprawianie problemu trustAnchors podczas uruchamiania OpenJDK 7 na OS X :

Naprawianie problemu trustAnchors podczas uruchamiania OpenJDK 7 w OS X. Jeśli używasz OpenJDK 7 w OS X i widziałeś ten wyjątek:

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

Istnieje prosta poprawka. Wystarczy połączyć w tym samym pliku cacerts, którego używa JDK 1.6 firmy 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

Musisz to zrobić dla każdej zainstalowanej wersji OpenJDK. Po prostu zmień-v 1.7 wersję, którą chcesz naprawić. Uruchom, /usr/libexec/java_home -Vaby zobaczyć wszystkie zainstalowane środowiska JRE i JDK.

Być może faceci OpenJDK mogliby dodać to do swoich skryptów instalacyjnych.

W systemie Ubuntu 12.10 (Quetzal) lub nowszym certyfikaty są przechowywane w pakiecie ca-certyfikaty-java . Użycie -Djavax.net.ssl.trustStore=/etc/ssl/certs/java/cacertsspowoduje podniesienie ich niezależnie od używanego JDK.

Właśnie ten problem napotkałem na OS X, używając JDK 1.7 po aktualizacji do OS X 10.9 (Mavericks). Poprawką, która działała dla mnie, była po prostu ponowna instalacja Java w wersji Apple, dostępnej pod adresem http://support.apple.com/kb/DL1572 .

Pobiegłem

sudo update-ca-certificates -f

aby utworzyć plik certyfikatu, a następnie:

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

Wróciłem do biznesu, dzięki chłopaki. Szkoda, że ​​nie zostało uwzględnione w instalacji, ale w końcu tam dotarłem.

Błąd informuje, że system nie może znaleźć magazynu zaufanych certyfikatów na ścieżce dostarczonej z parametrem javax.net.ssl.trustStore .

W systemie Windows skopiowałem cacertsplik z jre/lib/securitykatalogu instalacyjnego Eclipse (to samo miejsce co eclipse.iniplik) i dodałem następujące ustawienia eclipse.ini:

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

Miałem pewne problemy ze ścieżką do cacerts (zmienna środowiskowa% java_home% jest jakoś nadpisana), więc skorzystałem z tego trywialnego rozwiązania.

Chodzi o to, aby podać poprawną ścieżkę do pliku zaufanych certyfikatów - najlepiej byłoby użyć względnego. Możesz także użyć ścieżki bezwzględnej.

Aby upewnić się, że typ sklepu to JKS, uruchom następującą komendę:

keytool -list -keystore cacerts

Keystore type: JKS
Keystore provider: SUN

Usunięcie pakietu ca-certyfikaty-java i ponowne zainstalowanie go działało dla mnie ( Ubuntu MATE 17.10 (Artful Aardvark)).

sudo dpkg --purge --force-depends ca-certificates-java

sudo apt-get install ca-certificates-java

Dziękujemy, jdstrand: Komentarz 1 do błędu 983302, Re: ca-certyfikaty-java nie instalują cacertów Java na Oneiric Ocelot .

Miałem wiele problemów z bezpieczeństwem po aktualizacji do OS X 10.9 (Mavericks):

• Problem SSL z Amazon AWS
• Peer nie został uwierzytelniony w Maven i Eclipse
• trustAnchors parametr musi być niepusty

Zastosowałem tę aktualizację Java i naprawiłem wszystkie moje problemy: http://support.apple.com/kb/DL1572?viewlocale=en_US

Oczekiwałem takich rzeczy, ponieważ używam alternatywnej JVM w moim Talend Open Studio (wsparcie w tej chwili istnieje tylko do JDK 1.7). Używam 8 do celów bezpieczeństwa ... w każdym razie

• Zaktualizuj swój magazyn certyfikatów:

  sudo update-ca-certificates -f

następnie

• dodaj nową wartość do parametrów inicjalizacji

  sudo gedit $(path to your architecture specific ini i.e. TOS_DI...ini)
  
  Djavax.net.ssl.trustStore=/etc/ssl/certs/java/cacerts

Dla mnie drugi wpis zadziałał. Myślę, że w zależności od wersji Talend Open Studio / TEnt + JVM ma inną nazwę parametru, ale szuka tego samego pliku kluczy.

Dla mnie było to spowodowane brakiem zaufanegoCertEntry w magazynie zaufania.

Aby przetestować, użyj:

keytool -list -keystore keystore.jks

To daje mi:

Keystore type: JKS
Keystore provider: SUN

Your keystore contains 1 entry

cert-alias, 31-Jul-2017, PrivateKeyEntry

Mimo że mój PrivateKeyEntry zawiera CA , musiał zostać zaimportowany osobno :

keytool -import -alias root-ca1 -file rootca.crt -keystore keystore.jks

Importuje certyfikat, a następnie ponowne uruchomienie keytool -list -keystore keystore.jksdaje teraz:

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>

Teraz ma trustCertEntry, a Tomcat rozpocznie się pomyślnie.

Niektórzy dostawcy OpenJDK spowodowali to, że pusty cacertsplik był dystrybuowany wraz z plikiem binarnym. Błąd wyjaśniono tutaj: https://github.com/AdoptOpenJDK/openjdk-build/issues/555

Możesz skopiować do adoptOpenJdk8\jre\lib\security\cacertspliku ze starej instalacji, takiej jakc:\Program Files\Java\jdk1.8.0_192\jre\lib\security\cacerts .

Wersja buggy AdoptOpenJDK to https://github.com/AdoptOpenJDK/openjdk8-releases/releases/download/jdk8u172-b11/OpenJDK8_x64_Win_jdk8u172-b11.zip

Jeśli doświadczasz tego na Ubuntu z JDK9 i Maven, możesz dodać tę opcję JVM - najpierw sprawdź, czy ścieżka istnieje:

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

Jeśli brakuje pliku, spróbuj zainstalować ca-certyfikaty-java, jak ktoś zauważył:

sudo apt install ca-certificates-java

Miałem ten komunikat o błędzie w Javie 9.0.1 w systemie Linux. Było to spowodowane znanym błędem JDK, w którym plik cacerts jest pusty w pakiecie binarnym .tar.gz (pobrany z http://jdk.java.net/9/ ).

Zobacz akapit „znane problemy” w informacjach o wersji JDK 9.0.1 , mówiąc: „TLS nie działa domyślnie w OpenJDK 9”.

W Debianie / Ubuntu (i prawdopodobnie innych pochodnych) prostym obejściem jest zastąpienie pliku cacerts plikiem z pakietu „ca-certyfikaty-java”:

sudo apt install ca-certificates-java
cp /etc/ssl/certs/java/cacerts /path/to/jdk-9.0.1/lib/security/cacerts

W Red Hat Linux / CentOS możesz zrobić to samo z pakietem „ca-certyfikaty”:

sudo yum install ca-certificates
cp /etc/pki/java/cacerts /path/to/jdk-9.0.1/lib/security/cacerts

Miałem ten problem podczas próby korzystania z Maven 3 po aktualizacji z Ubuntu 16.04 LTS (Xenial Xerus) do Ubuntu 18.04 LTS (Bionic Beaver).

Sprawdzanie / usr / lib / jvm / java-8-oracle / jre / lib / security wykazało, że mój plik cacerts był dowiązaniem symbolicznym /etc/ssl/certs/java/cacerts .

Miałem też podejrzanie nazwany plik cacerts.original.

Zmieniłem nazwę cacerts.originalna cacertsi to rozwiązało problem.

Zetknąłem się z tym również w systemie OS X po aktualizacji OS X 10.9 (Mavericks), kiedy używana była stara Java 6 i próbowałem uzyskać dostęp do adresu URL HTTPS. Naprawą była odwrotność Petera Kriena; Musiałem skopiować cacertsz przestrzeni 1.7 do lokalizacji połączonej wersją 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

W moim przypadku plik JKS użyty w aplikacji klienckiej został uszkodzony. Utworzyłem nowy i zaimportowałem w nim certyfikaty SSL serwera docelowego. Następnie użyłem nowego pliku JKS w aplikacji klienckiej jako magazynu zaufania, takiego jak:

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

Źródło: Java SSL i magazyn kluczy certyfikatów

Używam narzędzia (KeyStore Explorer) do tworzenia nowego JKS. Możesz pobrać go z tego linku, KeyStore Explorer .

Ten błąd może również wystąpić po uaktualnieniu do wersji Spring Boot 1.4.1 (lub nowszej), ponieważ przynosi on Tomcat 8.5.5 jako część jego zależności.

Problem wynika ze sposobu, w jaki Tomcat radzi sobie ze sklepem zaufania. Jeśli zdarzyło Ci się określić lokalizację magazynu zaufanych certyfikatów jako taką samą jak plik kluczy w konfiguracji Spring Boot, prawdopodobnie otrzymasz trustAnchors parameter must be non-emptykomunikat podczas uruchamiania aplikacji.

server.ssl.key-store=classpath:server.jks
server.ssl.trust-store=classpath:server.jks

Po prostu usuń server.ssl.trust-storekonfigurację, chyba że wiesz, że jej potrzebujesz, w takim przypadku zapoznaj się z poniższymi linkami.

Następujące problemy zawierają więcej szczegółów na temat problemu:

• Łącznik HTTPS Tomcat nie uruchamia się z wersją 1.4.1 # 7069
• SSL-client-auth z samopodpisanym certyfikatem przestał działać # 7406
• Uaktualnij do Tomcat 8.5.5 # 6703

Napotkałem ten problem z sdkmanager zestawu SDK systemu Android. Dla mnie to rozwiązanie zadziałało:

1. Iść do /usr/lib/jvm/java-8-oracle/jre/lib/security/
2. wymienić cacertzcacert.original

cacertPlik był malutki (22B). Zainstalowałem oracle-java8-installerz ppa:webupd8team/java(zgodnie z tym podręcznikiem: https://docs.nativescript.org/start/ns-setup-linux ).

Dla przypomnienia, żadna z odpowiedzi tutaj nie działała dla mnie. Moja kompilacja Gradle zaczęła zawodzić w tajemniczy sposób z tym błędem, nie mogąc pobrać HEAD z Maven central dla konkretnego pliku POM .

Okazało się, że JAVA_HOME ustawiłem na moją osobistą kompilację OpenJDK, którą zbudowałem do debugowania problemu z javac. Powrót do JDK zainstalowanego w moim systemie naprawił.

W systemie Red Hat Linux problem został rozwiązany przez zaimportowanie certyfikatów do /etc/pki/java/cacerts.

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

Musisz dodać powyższe dwa wiersze do swojego kodu. Nie można znaleźć magazynu zaufania.

Napotkałem ten problem podczas uruchamiania konkretnego pakietu Androida do testowania na Ubuntu 14.04 (Trusty Tahr). Dwie rzeczy działały dla mnie, jak sugeruje shaheen:

sudo update-ca-certificates -f

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

Żadne z rozwiązań, które znalazłem w Internecie, nie działało, ale zmodyfikowana wersja odpowiedzi Petera Kriena wydaje się działać.

Najpierw znajdź folder Java, uruchamiając /usr/libexec/java_home. Dla mnie była to 1.6.0.jdkwersja. Następnie przejdź do jego lib/securitypodfolderu (dla mnie /Library/Java/JavaVirtualMachines/1.6.0.jdk/Contents/Home/lib/security).

Następnie usuń cacertsplik, jeśli już istnieje, i wyszukaj go w systemie za pomocą sudo find / -name "cacerts". Znaleziono dla mnie wiele elementów, w wersjach Xcode lub innych zainstalowanych przeze mnie aplikacjach, ale także w /Library/Internet Plug-Ins/JavaAppletPlugin.plugin/Contents/Home/lib/security/cacertsktórych wybrałem.

Użyj tego pliku i stwórz do niego dowiązanie symboliczne (wcześniej w folderze Java) sudo ln -fsh "/Library/Internet Plug-Ins/JavaAppletPlugin.plugin/Contents/Home/lib/security/cacerts", i powinno działać.

Mam zarówno - Java z pobrania Apple 2017-001 ( https://support.apple.com/kb/dl1572 - Zakładam, że stąd są prawidłowe certyfikaty) i Oracle zainstalowany na Mac OS X 10.12 (Sierra) .

na Ubuntu 14.04 z openjdk 11 z ppa: openjdk-r / ppa to zadziałało dla mnie:

w java.security zmień typ magazynu kluczy na

keystore.type=jks

następnie:

sudo dpkg --purge --force-depends ca-certificates-java
sudo apt-get install ca-certificates-java

gdy sprawdzasz, czy zadziałało, upewnij się, że nie używasz demona ze starą --no-daemonjavą nadal działającą (np. opcja gradle)

ten błąd opisuje wszystko ładnie i pomoże ci zrozumieć, co się dzieje https://bugs.launchpad.net/ubuntu/+source/ca-certificates-java/+bug/1739631

W systemie Ubuntu 18.04 musiałem używać OpenJDK 1.7 do obsługi starego projektu. Pobrałem pakiet binarny. Ale kiedy wykonałem na nim skrypt, dostałem ten sam błąd.

Rozwiązaniem było usunięcie cacertspliku pobranego JDK z jre/lib/securityfolderu, a następnie utworzenie go jako dowiązania symbolicznego do cacertspliku systemowego w /etc/ssl/certs/java/:

sudo ln -s /etc/ssl/certs/java/cacerts /path/to/downloaded/java/jre/lib/security/cacerts

Niewielka szansa, że ​​pomoże to każdemu, ale .... dla każdego, kto korzysta z Java 8 z Docker Image na Raspberry Pi (przy użyciu procesora AMD) Dostałem następujący plik Docker do zbudowania i uruchomienia dla mnie pomyślnie

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"]