Fehler - Der Parameter trustAnchors darf nicht leer sein

492

Ich versuche, meine E-Mail auf Jenkins / Hudson zu konfigurieren, und erhalte ständig die folgende Fehlermeldung:

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

Ich habe online eine gute Menge an Informationen über den Fehler gesehen, aber ich habe keine zum Arbeiten gebracht. Ich verwende Suns JDK unter Fedora Linux (nicht OpenJDK).

Hier sind einige Dinge, die ich versucht habe. Ich habe versucht, den Ratschlägen aus diesem Beitrag zu folgen, aber das Kopieren der Cacerts von Windows auf meine Fedora-Box mit Jenkins hat nicht funktioniert. Ich habe versucht, diesem Handbuch zu folgen , als ich versuchte, Google Mail als meinen SMTP-Server zu konfigurieren, aber es hat auch nicht funktioniert. Ich habe auch versucht, diese Cacert-Dateien manuell herunterzuladen, zu verschieben und mithilfe einer Variation der Befehle in diesem Handbuch in meinen Java-Ordner zu verschieben .

Ich bin offen für Vorschläge, da ich gerade nicht weiterkomme. Ich habe es von einem Windows Hudson-Server zum Laufen gebracht, aber ich habe Probleme mit Linux.

David Gill
quelle

Antworten:

513

Diese bizarre Nachricht bedeutet, dass der von Ihnen angegebene Truststore wie folgt lautete:

  • leeren,
  • nicht gefunden, oder
  • konnte nicht geöffnet werden (z. B. aufgrund von Zugriffsberechtigungen).

Siehe auch die Antwort von @ AdamPlumb unten .

Um dieses Problem zu debuggen (ich habe hier darüber geschrieben ) und zu verstehen, welcher Truststore verwendet wird, können Sie die Eigenschaft javax.net.debug = all hinzufügen und dann die Protokolle über den Truststore filtern. Sie können auch mit der Eigenschaft javax.net.ssl.trustStore spielen, um einen bestimmten Truststore anzugeben. Beispielsweise :


    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
Marquis von Lorne
quelle
1
Vielen Dank, EJP. Ich habe Ihren Beitrag hier gesehen , war mir aber nicht sicher, wie ich überprüfen soll, ob der Truststore vorhanden ist. Ich habe auch meine Datei server.xml aufgerufen, war mir aber nicht sicher, wie ich überprüfen soll, ob der Truststore vorhanden ist. Überprüfe ich nur die Voreinstellung keystoreFile = "conf / .keystore" (keystoreFile war in dieser Datei nicht vorhanden)?
David Gill
2
Die Antwort war, wie ich es importierte. Ich schien einen entscheidenden Schritt verpasst zu haben. Siehe [Java Error InvalidAlgorithmParameterException] [1] [1]: jyotirbhandari.blogspot.com/2011/09/…
David Gill
2
Bestätigt, dass diese Antwort korrekt ist. Ich habe den Fehler unter Tomcat erhalten. Ich hatte meinen Truststore in ${CATALINA_HOME}\conf, CATALINA_HOMEwurde aber nicht eingerichtet, sodass Tomcat nach \confdem Truststore suchte.
SingleShot
4
@BubblewareTechnology Nein, der Fehler lag im Dateinamen und nicht darin, wie Sie das Zertifikat in die Datei importiert haben. Dein Blog ist nicht korrekt. Sie sollten auch nicht empfehlen, die JRE $ / cacerts-Datei zu ändern. Das nächste Java-Upgrade wird geändert. Sie benötigen einen Prozess, der es kopiert, der Kopie Ihr eigenes Zertifikat hinzufügt und die Kopie als Truststore verwendet. Wiederholen Sie jedes Java-Upgrade. Und Sie müssen Java überhaupt nicht von seinem eigenen Truststore erzählen, sondern nur von Ihrem eigenen, wenn es anders ist.
Marquis von Lorne
3
Ich werde eine Wendung hinzufügen: Selbst wenn der Truststore existiert, zugänglich ist, das richtige Format hat, wenn er VOLLSTÄNDIG LEER ist, ist dies der Fehler, den Sie bei verschiedenen Bibliotheken (einschließlich Apache HttpClient) erhalten können.
Alan Franzoni
265

In Ubuntu 18.04 hat dieser Fehler eine andere Ursache (JEP 229, Wechseln vom jksKeystore-Standardformat zum pkcs12Format und Generieren der Debian-Cacerts-Datei unter Verwendung der Standardeinstellung für neue Dateien) und Problemumgehung :

# 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) , der Fehler wurde in Ubuntu Bionic LTS 18.04.1 und Ubuntu Cosmic 18.10 behoben.


🗹 Ubuntu 1770553: [SRU] backport ca-certificates-java von cosmic (20180413ubuntu1)

🗹 Ubuntu 1769013: Bitte führen Sie ca-certificates-java 20180413 (main) von Debian unstable (main) zusammen.

🗹 Ubuntu 1739631: Bei einer Neuinstallation mit JDK 9 kann die generierte PKCS12-Cacerts-Keystore-Datei nicht verwendet werden

🗹 Docker-Bibliothek 145: 9-JDK-Image weist SSL-Probleme auf

🗹 Debian 894979: ca-certificates-java: funktioniert nicht mit OpenJDK 9, Anwendungen schlagen mit InvalidAlgorithmParameterException fehl: Der Parameter trustAnchors darf nicht leer sein

🗹 JDK-8044445: JEP 229: Standardmäßig PKCS12-Schlüsselspeicher erstellen

🖺 JEP 229: Standardmäßig PKCS12-Keystores erstellen


Wenn das Problem nach dieser Problemumgehung weiterhin besteht, möchten Sie möglicherweise sicherstellen, dass Sie die gerade reparierte Java-Distribution tatsächlich ausführen.

$ which java
/usr/bin/java

Sie können die Java-Alternativen auf 'auto' setzen mit:

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

Sie können die von Ihnen ausgeführte Java-Version überprüfen:

$ 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)

Es gibt auch alternative Problemumgehungen, aber diese haben ihre eigenen Nebenwirkungen, die eine zusätzliche zukünftige Wartung erfordern, ohne dass sich dies auszahlt.

Die nächstbeste Problemumgehung besteht darin, die Zeile hinzuzufügen

javax.net.ssl.trustStorePassword=changeit

zu den Dateien

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

was auch immer existiert.

Die drittniedrigste problematische Problemumgehung besteht darin, den Wert von zu ändern

keystore.type=pkcs12

zu

keystore.type=jks

in den Dateien

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

Entfernen Sie die cacertsDatei und generieren Sie sie auf die in der letzten Zeile des Workaround-Skripts oben im Beitrag beschriebene Weise neu.

Mikael Gueck
quelle
50
Ubuntu 18 Benutzer, lesen Sie dies! Dies wird viele Stunden Ihres Lebens retten! Vielen Dank!
Vak
5
Diese Antwort hat mir geholfen, den gleichen Fehler mit maven unter Ubuntu 18.04 zu beheben. Ich musste den Besitzer der Datei / etc / ssl / certs / java / cacerts von root auf mich selbst ändern, um darauf schreiben zu können. Dann habe ich es zurückgeschaltet.
Yuri Gor
77
Ich habe sudo rm / etc / ssl / certs / java / cacerts und dann sudo update-ca-certificates -f ausgeführt und dies hat mein Problem in kubuntu 18.04 behoben.
jsn
2
@jsn, danke für die Lösungen, funktioniert auch unter Linux Mint 19, das auf Ubuntu 18.04
Samrat
2
@ jsn Lösung funktionierte auch für Debian Stretch + openjdk8
HRJ
105

Dies hat das Problem für mich unter Ubuntu behoben:

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

(hier zu finden: https://bugs.launchpad.net/ubuntu/+source/ca-certificates-java/+bug/1396760 )

ca-certificates-java ist keine Abhängigkeit im Oracle JDK / JRE, daher muss dies explizit installiert werden.

Michael Condouris
quelle
2
Vielen Dank, dies hat das Problem für mich behoben, als ich unter Ubuntu 15.04 darauf gestoßen bin.
Macil
Arbeitete an Raspbian auf Raspberry Pi
Defozo
1
Ist auf dieses Problem mit Debian Jesse Stable Backports mit OpenJDK8 gestoßen und dies hat das Problem behoben. Verwendete dies beim Erstellen von Docker-Images. :)
Tuxdude
9
Funktioniert unter Ubuntu MATE 18.04 leider nicht. Ich werde versuchen, Java neu zu installieren.
Pranav A.
1
@codefx - Ich habe getan, was Sie vorschlagen, und es funktioniert nicht - unter Ubuntu 18.x mit Java 10 (Standard).
mzedeler
69

Unter Ubuntu 18.04 ist die Hauptursache ein Konflikt zwischen openjdk-11-jdk (Standardeinstellung) und anderen davon abhängigen Paketen. Es wurde bereits in Debian behoben und wird in Kürze in Ubuntu enthalten sein. In der Zwischenzeit besteht die einfachste Problemumgehung darin, Java auf Version 8 herabzustufen. Andere Lösungen ca-certificates-javasind viel komplizierter.

Entfernen Sie zuerst widersprüchliche Pakete:

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

Überprüfen Sie, ob Sie alle zugehörigen Pakete erfolgreich entfernt haben, indem Sie:

sudo update-alternatives --config java

Das System fordert Sie auf, kein Java für die Konfiguration verfügbar zu machen . Andernfalls schlägt diese Problemumgehung fehl .

Installieren Sie dann die erforderlichen Pakete neu:

sudo apt-get install openjdk-8-jdk
Shvahabi
quelle
Diese Beschreibung ist sachlich falsch und behebt das Problem nur in dem Sinne, wie eine Neuinstallation von Windows ein Problem beheben könnte. Es ist nicht erforderlich, alle Java-Pakete zu entfernen. Wenn Sie diesen Weg gehen möchten, müssen Sie nur das openjdk-8-jdkPaket installieren , die /etc/ssl/certs/java/cacertsDatei entfernen und ausführen. Dies sudo update-ca-certificates -fist der Umweg, um von einer pkcs12formatierten Cacerts-Datei zu einer jksformatierten zu wechseln , wie an anderer Stelle in diesem Thread beschrieben.
Mikael Gueck
1
@MikaelGueck Obwohl die Logik auf Ihrer Seite zu sein scheint, bin ich hier, um Ihnen zu versichern, dass ich zuvor genau das getan habe, was in Ihrem Kommentar und in den meisten anderen Antworten beschrieben wurde, und in 18.04 ist dies die einzige Antwort, die funktioniert hat . Ich denke, Ihre Ablehnung sollte sich in eine positive Bewertung verwandeln oder zumindest verschwinden, da sie höchst unverdient ist.
Andrea Ligios
@AndreaLigios, Sie können die Skripte selbst lesen, sie sind ziemlich kurz. Sie haben einen fest codierten Satz von JAVA_HOME-Pfaden von 8 bis 10, sie versuchen diese nacheinander, sie rufen den Debian CA-Dateigenerator auf, den Sie auch lesen können, der das vorhandene Dateiformat verwendet, weil der JDK-Keyfile-Handler-Code, der Sie können durchlesen, hat einen Kompatibilitäts-Fallback-Modus. Wenn Ihr Computer diese einfache Software anders ausführt, haben Sie möglicherweise andere Probleme damit. Haben Sie Ihre Java-Alternativen geändert und eine andere JVM aufgerufen, weil durch das Entfernen die Alternativen möglicherweise zurückgesetzt wurden?
Mikael Gueck
1
@MikaelGueck ja, in einem der vorherigen Versuche habe ich meine Java-Alternativen geändert, also war es wahrscheinlich so. Ich bin der erste, der sich gerne mit Quellcode befasst und herausfindet, wie Dinge funktionieren, aber das war heute nicht mein Ziel, es war nur eines von 5-6 verschiedenen unerwarteten Hindernissen, die ich auf dem Weg zu meinem eigentlichen Ziel hatte. Mit dieser Antwort konnte ich das Problem in weniger als 2 Minuten lösen! Wie viel Zeit hätte ich investieren müssen, um in Skripten zu suchen und eine bessere Lösung zu finden? Und wofür, um ein paar Megabyte zu sparen? Das ist drastisch, funktioniert aber (und egal was das Problem ist), also ein großes Dankeschön an OP für die verdammt
Beschäftigten
1
Ich habe 2 Tage lang nach einer Lösung gesucht und Ihre Antwort hat mein Problem gelöst, danke. Ich gehe gerade zu Kubuntu 18.04, das hat funktioniert.
Guepardomar
55

EJP hat die Frage im Grunde genommen beantwortet (und mir ist klar, dass dies eine akzeptierte Antwort ist), aber ich habe mich nur mit diesem Randfall befasst und wollte meine Lösung verewigen.

Ich hatte den InvalidAlgorithmParameterExceptionFehler auf einem gehosteten Jira- Server, den ich zuvor für den Nur-SSL-Zugriff eingerichtet hatte. Das Problem war, dass ich meinen Keystore im PKCS # 12-Format eingerichtet hatte, mein Truststore jedoch im JKS-Format.

In meinem Fall hatte ich meine server.xmlDatei bearbeitet , um den KeystoreType für PKCS anzugeben, aber ich habe den TruststoreType nicht angegeben, sodass standardmäßig der KeystoreType verwendet wird. Wenn Sie den truststoreType explizit angeben, während JKS ihn für mich gelöst hat.

Adam Plumb
quelle
Nun, ich helfe Ihnen, die Lösung für Ihre Randfall-Gotcha zu verewigen. dort wird es interessant.
n611x007
2
Das war genau mein Problem. Ich habe Spring Boot 1.4.2.RELEASE verwendet und hatte einen Hardware-Keystore und einen Software-Truststore. Ich habe den Anbieter und den Typ für den Keystore angegeben, aber nicht den Truststore. Infolgedessen wurden vom Truststore der falsche Anbieter und Typ verwendet. Die Angabe dieser (SUN und JKS) löste das Problem.
Kenco
12
Wie genau hast du das gemacht? (Fenster hier)
Tatsu
2
Wenn ich heute mit meinem Android-Enkel darauf stoße, verstehe ich fast, was Sie sagen, aber Sie sagen nicht, wie Sie es lösen sollen. Nicht hilfreiche Antwort
Lothar
52

Ich bin auf diese Lösung aus dem Blogbeitrag gestoßen. Behebung des Vertrauensproblems beim Ausführen von OpenJDK 7 unter OS X :

Behebung des TrustAnchors-Problems beim Ausführen von OpenJDK 7 unter OS X. Wenn Sie OpenJDK 7 unter OS X ausführen und diese Ausnahme festgestellt haben:

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

Es gibt eine einfache Lösung. Verknüpfen Sie einfach dieselbe Cacerts-Datei, die Apples JDK 1.6 verwendet:

cd $(/usr/libexec/java_home -v 1.7)/jre/lib/security
ln -fsh /System/Library/Java/Support/CoreDeploy.bundle/Contents/Home/lib/security/cacerts

Sie müssen dies für jede OpenJDK-Version tun, die Sie installiert haben. Wechseln -v 1.7Sie einfach zu der Version, die Sie reparieren möchten. Führen Sie /usr/libexec/java_home -Vsehen , alle JREs und JDKs Sie installiert haben.

Vielleicht könnten die OpenJDK-Leute dies zu ihren Installationsskripten hinzufügen.

Peter Kriens
quelle
1
Mein "ln" -Befehl (unter OSX 10.6.8) hat keine "h" -Option. Was soll es tun?
Andrew Swan
1
Ah, ich hatte zwei "ln" -Befehle, einen in / usr / bin (Standardeinstellung) und einen in / bin; Letzterer hatte eine "h" -Option und funktionierte.
Andrew Swan
Ich habe meine defekte 1.6-Installation, die mit cacerts aus der System 1.8-Installation verknüpft ist, mit dieser ln-Technik behoben. Vielen Dank!
A21z
1
Für zukünftige Leser: es scheint , dass Sie auch die anderen 3 - Dateien benötigen , die in dem sind securityOrdner ( blacklisted.certs, local_policy.jar, und US_export_policy.jar) für Java , glücklich zu sein.
awksp
@ Peter Kriens, warum mit cacertsunter jreVerzeichnis verlinkt ?
BAE
45

In Ubuntu 12.10 (Quantal Quetzal) oder höher werden die Zertifikate im Paket ca-certificates-java gespeichert. Mit -Djavax.net.ssl.trustStore=/etc/ssl/certs/java/cacertswird sie unabhängig vom verwendeten JDK abgerufen.

yvesr
quelle
54
Ich stellte fest, dass ich update-ca-certificates -fmanuell ausführen musste , um die cacerts-Datei zu füllen
Portablejim
4
@Portablejim Danke. Ihr Kommentar hat das erste Problem gelöst, bei dem ich Apache Spark unter Ubuntu 15.04beta erstellt habe.
Paul
1
Vielen Dank an @Portablejim, Ihr Kommentar hat bei Ubuntu 15.04 für mich funktioniert.
David Berg
Vielen Dank. Dies ist mein Problem mit PhpStrom + gepatchtem JDK behoben. Ich habe diesen Schlüssel in die Datei "phpstorm64.vmoptions" geschrieben.
Vijit
Ich arbeite nicht für Ubuntu 18.04 und JDK ist 1.8.0_62
Devendra Singraul
34

Nach dem Upgrade auf OS X 10.9 (Mavericks) bin ich unter OS X mit JDK 1.7 auf genau dieses Problem gestoßen . Die Lösung, die für mich funktioniert hat, bestand darin, einfach die Apple-Version von Java neu zu installieren, die unter http://support.apple.com/kb/DL1572 verfügbar ist .

KiwiMartin
quelle
Ich bin auf Java 6 gestoßen, das von Grails unter OSX verwendet wird. Ich hatte auch Java 7 von Oracle installiert und auch auf Mavericks aktualisiert. Die Neuinstallation von Java 6 von der Apple-Website hat das Problem für mich ebenfalls behoben.
pm_labs
Dies ist bei der Installation von open jdk 6 auf einer Ubuntu-Cloud-Box aufgetreten. Schön, ein bekanntes Gesicht zu sehen, BTW
Ben Hutchison
30

ich rannte

sudo update-ca-certificates -f

um eine Zertifikatdatei zu erstellen, und dann:

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

Ich war wieder im Geschäft, danke Jungs. Schade, dass es nicht in der Installation enthalten ist, aber ich bin am Ende dort angekommen.

Johnny
quelle
Wenn ich renne sudo /var/lib/dpkg/info/ca-certificates-java.postinst configure**bekomme ichsudo: /var/lib/dpkg/info/ca-certificates-java.postinst: command not found
Magick
Nur sudo update-ca-certificates -fist genug auf Debian Jessie mit openjdk-8-jre-headlessvon Jessie-Backports, solange ca-certificates-javainstalliert. Ich denke, die Reihenfolge der Installation ist wichtig (JRE nach ca-certificates-javakann dies verursachen, da letztere keine Auslöser für das zurückportierte Java 8 hat).
Mirabilos
2
sudo /var/lib/dpkg/info/ca-certificates-java.postinst configure ohne Sterne **
Yu Jiaao
update-ca-certificates -fist das, was es behoben hat. Ich brauchte den 2. Befehl nicht
Mark Jeronimus
17

Der Fehler weist darauf hin, dass das System den Truststore in dem mit dem Parameter angegebenen Pfad nicht finden kann javax.net.ssl.trustStore.

Unter Windows habe ich die cacertsDatei aus jre/lib/securitydem Eclipse-Installationsverzeichnis (am selben Ort wie die eclipse.iniDatei) kopiert und die folgenden Einstellungen hinzugefügt eclipse.ini:

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

Ich hatte einige Probleme mit dem Pfad zu den Cacerts (die Umgebungsvariable% java_home% wird irgendwie überschrieben), also habe ich diese triviale Lösung verwendet.

Die Idee ist, einen gültigen Pfad zur Truststore-Datei bereitzustellen - im Idealfall wird ein relativer Pfad verwendet. Sie können auch einen absoluten Pfad verwenden.

Um sicherzustellen, dass der Speichertyp JKS ist, führen Sie den folgenden Befehl aus:

keytool -list -keystore cacerts

Keystore type: JKS
Keystore provider: SUN
Razvanon
quelle
2
Dies ist die einzige Antwort, die tatsächlich funktioniert hat. Vielen Dank @razvanone
Akshar Patel
1
Ich habe es geschafft, eine kleine "Gotcha" zu treffen: Die drei Zeilen in der Datei eclipse.ini müssen sich in drei separaten Zeilen befinden. Ich habe sie zunächst alle in eine Zeile gesetzt, und Eclipse hat das nicht aufgegriffen.
SiKing
16

Das Entfernen des ca-certificates-java-Pakets und das erneute Installieren funktionierten bei mir ( Ubuntu MATE 17.10 (Artful Aardvark)).

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

sudo apt-get install ca-certificates-java

Vielen Dank, jdstrand: Kommentar 1 für Fehler 983302, Re: ca-certificates-java kann Java-Cacerts nicht auf Oneiric Ocelot installieren .

ericek111
quelle
11

Nach dem Upgrade auf OS X 10.9 (Mavericks) gab es viele Sicherheitsprobleme :

  • SSL-Problem mit Amazon AWS
  • Peer nicht mit Maven und Eclipse authentifiziert
  • trustAnchors Parameter darf nicht leer sein

Ich habe dieses Java-Update angewendet und alle meine Probleme behoben: http://support.apple.com/kb/DL1572?viewlocale=de_DE

Freddy Boucher
quelle
5
Pfui. Java 6 ist viele Jahre nach dem Ende der öffentlichen Unterstützung und sicherlich mit Sicherheitslücken behaftet. Apple stellt es zum Download zur Verfügung, damit ältere Software, die nicht mit Java 7/8 ausgeführt werden kann, weiterhin ausgeführt werden kann. Es sollte jedoch nicht zum Herstellen von SSL-Verbindungen zu Diensten im öffentlichen Internet wie 1. AWS, 2. Maven verwendet werden Zentral, 3. alles andere.
Zac Thompson
10

Ich habe solche Dinge erwartet, da ich in meinem Talend Open Studio eine alternative JVM verwende (Unterstützung besteht derzeit nur bis JDK 1.7). Ich benutze 8 aus Sicherheitsgründen ... sowieso

  • Aktualisieren Sie Ihren Zertifikatspeicher:

    sudo update-ca-certificates -f

dann

  • Fügen Sie Ihren Initialisierungsparametern einen neuen Wert hinzu

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

Für mich hat der zweite Eintrag funktioniert. Ich denke, abhängig von der Version von Talend Open Studio / TEnt + JVM hat es einen anderen Parameternamen, aber es sucht nach der gleichen Keystore-Datei.

steveoams
quelle
4
Woher haben Sie die Immobilie javax.net.ssl.trustAnchors? Es wird in der JSSE-Dokumentation nicht erwähnt.
Marquis von Lorne
10

Für mich war dies auf das Fehlen eines TrustedCertEntry im Truststore zurückzuführen.

Verwenden Sie zum Testen:

keytool -list -keystore keystore.jks

Es gibt mir:

Keystore type: JKS
Keystore provider: SUN

Your keystore contains 1 entry

cert-alias, 31-Jul-2017, PrivateKeyEntry

Obwohl mein PrivateKeyEntry eine Zertifizierungsstelle enthält , musste er separat importiert werden :

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

Es importiert das Zertifikat und führt dann durch erneutes Ausführen keytool -list -keystore keystore.jksFolgendes aus:

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>

Jetzt hat es einen TrustedCertEntry und Tomcat wird erfolgreich gestartet.

HammelUp
quelle
NB Überprüfen Sie das Baeldung-Tutorial mit einem nützlichen Makefile als Verknüpfung zum Erstellen von Keystore und Truststore (Spring-Security-x509-Projekt). Baeldung.com/x-509-authentication-in-spring-security
hello_earth
9

Einige OpenJDK-Anbieterversionen haben dies dadurch verursacht, dass eine leere cacertsDatei mit der Binärdatei verteilt wurde. Der Fehler wird hier erklärt: https://github.com/AdoptOpenJDK/openjdk-build/issues/555

Sie können adoptOpenJdk8\jre\lib\security\cacertsvon einer alten Installation wie in die Datei kopieren c:\Program Files\Java\jdk1.8.0_192\jre\lib\security\cacerts.

Die Buggy-Version von AdoptOpenJDK lautet https://github.com/AdoptOpenJDK/openjdk8-releases/releases/download/jdk8u172-b11/OpenJDK8_x64_Win_jdk8u172-b11.zip

Rosercostin
quelle
Ich denke, das war auch bei mir der Fall. In AdoptOpenJDK 202 ist dieser Fehler vorhanden und in 222 funktioniert er. Aktualisieren Sie also Ihr JDK, wenn möglich.
Marty
6

Wenn dies unter Ubuntu mit JDK9 und Maven auftritt, können Sie diese JVM-Option hinzufügen. Überprüfen Sie zunächst, ob der Pfad vorhanden ist:

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

Wenn die Datei fehlt, versuchen Sie, ca-certificates-java wie folgt zu installieren:

sudo apt install ca-certificates-java
dmatej
quelle
Wenn Sie Docker verwenden, können Sie auch "maven: 3-jdk-9-slim" anstelle von "maven: 3-jdk-9" versuchen
Konstantin Pavlov
Danke, das hat bei mir für openjdk-8-jdk in Ubuntu 18.04
Aftab Naveed
4

Ich hatte diese Fehlermeldung unter Java 9.0.1 unter Linux. Dies lag an einem bekannten Fehler im JDK, bei dem die cacerts-Datei im Binärpaket .tar.gz (heruntergeladen von http://jdk.java.net/9/ ) leer ist .

Weitere Informationen finden Sie im Abschnitt "Bekannte Probleme" der JDK 9.0.1-Versionshinweise mit der Aufschrift "TLS funktioniert unter OpenJDK 9 standardmäßig nicht".

Unter Debian / Ubuntu (und wahrscheinlich anderen Derivaten) besteht eine einfache Problemumgehung darin, die cacerts-Datei durch die aus dem Paket "ca-certificates-java" zu ersetzen:

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

Unter Red Hat Linux / CentOS können Sie dasselbe mit dem Paket "ca-certificates" tun:

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

Ich hatte dieses Problem, als ich versuchte, Maven 3 zu verwenden, nachdem ich von Ubuntu 16.04 LTS (Xenial Xerus) auf Ubuntu 18.04 LTS (Bionic Beaver) aktualisiert hatte .

Das Überprüfen von / usr / lib / jvm / java-8-oracle / jre / lib / security ergab, dass meine cacerts-Datei ein symbolischer Link war, auf den verwiesen wurde /etc/ssl/certs/java/cacerts.

Ich hatte auch eine Datei mit dem verdächtigen Namen cacerts.original.

Ich umbenannt cacerts.originalzu cacerts, und dass das Problem behoben.

John Deverall
quelle
Die cacerts.originalDatei hatte das jksFormat und wurde mit Java 8 von Ubuntu 16.04 generiert, das dieses Format als Standard verwendete. Die cacertsDatei hatte das pkcs12Format, das von Java 10 von Ubuntu 18.04 generiert wurde, das dieses Format als Standard verwendet. Wie an anderer Stelle in diesem Thread erläutert, müssen Sie für das neue Format das Kennwort an die ausführbare Datei übergeben. Solange Sie jedoch entweder eine neue leere jks cacertsDatei generieren oder eine alte kopieren, wird beim nächsten Cacerts-Generierungsprozess die vorhandene Datei geleert und mit den CA-Zertifikaten aus dem Dateisystem aufgefüllt.
Mikael Gueck
3

Ich habe dies auch unter OS X festgestellt, nachdem ich OS X 10.9 (Mavericks) aktualisiert hatte, als das alte Java 6 verwendet wurde und versucht wurde, auf eine HTTPS-URL zuzugreifen. Die Lösung war die Umkehrung von Peter Kriens; Ich musste das cacertsaus dem 1.7-Bereich an den durch die 1.6-Version verknüpften Speicherort kopieren :

(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
Teilweise wolkig
quelle
1
Der Befehl hier versucht, ein Verzeichnis in eine Datei zu kopieren. macht überhaupt keinen Sinn.
Praseodym
Ich stimme der Einschätzung einer umgekehrten Lösung zu. Ich habe festgestellt, dass jdk1.6 einen defekten Softlink /Library/Java/JavaVirtualMachines/1.6.0_33-b03-424.jdk/Contents/Home/lib/security/cacerts -> /System/Library/Java/Support/CoreDeploy.bundle hat / Inhalt / Home / lib / security / cacerts. Also habe ich den defekten Softlink rm'ed und dann über die cacerts aus der jdk1.7-Installation kopiert.
James A Wilson
HINWEIS: Wenn Sie fertig sind, sollten Sie in der Lage sein, die kopierte Cacerts-Datei zu kopieren, um die Berechtigungen zu überprüfen.
Grau
Korrigierte auch den cp, um in die richtige Richtung zu gehen, und fügte die umask für mkdir und cp hinzu.
Grau
3

In meinem Fall war die in der Clientanwendung verwendete JKS-Datei beschädigt. Ich habe ein neues erstellt und die SSL-Zertifikate des Zielservers darin importiert. Dann habe ich die neue JKS-Datei in der Client-Anwendung als Trust Store verwendet, wie zum Beispiel:

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

Quelle: Java SSL und Zertifikat-Keystore

Ich benutze das Tool (KeyStore Explorer), um das neue JKS zu erstellen. Sie können es von diesem Link, KeyStore Explorer , herunterladen .

Salman
quelle
Keystore-Explorer hat die Arbeit für mich erledigt. Sie müssen nur den Standard-Keystore erstellen und die Zertifikatdatei für die Site / den Host untersuchen und speichern.
Shantha Kumara
3

Dieser Fehler kann auch nach dem Upgrade auf Spring Boot 1.4.1 (oder neuer) auftreten, da Tomcat 8.5.5 als Teil seiner Abhängigkeiten mitgebracht wird.

Das Problem ist auf die Art und Weise zurückzuführen, wie Tomcat mit dem Trust Store umgeht. Wenn Sie Ihren Trust Store-Speicherort in der Spring Boot-Konfiguration mit Ihrem Keystore identisch angegeben haben, wird die trustAnchors parameter must be non-emptyMeldung wahrscheinlich beim Starten der Anwendung angezeigt.

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

Entfernen server.ssl.trust-storeSie einfach die Konfiguration, es sei denn, Sie wissen, dass Sie sie benötigen. In diesem Fall konsultieren Sie die folgenden Links.

Die folgenden Probleme enthalten weitere Details zum Problem:

Robert Hunt
quelle
3

Ich habe dieses Problem mit dem Android SDK sdkmanager festgestellt. Für mich hat diese Lösung funktioniert:

  1. Gehe zu /usr/lib/jvm/java-8-oracle/jre/lib/security/
  2. Ersetzen cacertdurchcacert.original

Die cacertDatei war winzig (22B). Ich habe installiert oracle-java8-installervon ppa:webupd8team/java(nach dieser Anleitung: https://docs.nativescript.org/start/ns-setup-linux ).

Tyg
quelle
2

Für die Aufzeichnung hat keine der Antworten hier für mich funktioniert. Mein Gradle-Build schlug auf mysteriöse Weise mit diesem Fehler fehl und konnte HEAD für eine bestimmte POM- Datei nicht aus Maven Central abrufen .

Es stellte sich heraus, dass ich JAVA_HOME auf meinen persönlichen Build von OpenJDK eingestellt hatte, den ich zum Debuggen eines Javac-Problems erstellt hatte. Durch Zurücksetzen auf das auf meinem System installierte JDK wurde das Problem behoben.

user3562927
quelle
... was dazu führte, dass der Truststore laut anderen Antworten nicht gefunden wurde.
Marquis von Lorne
1
Ja, aber zu wissen, dass der Truststore nicht gefunden werden kann, ist völlig wenig hilfreich, wenn Sie nicht herausfinden können, warum er nicht gefunden wird. Es gibt viele, viele Möglichkeiten, wie es schief gehen kann, und es ist frustrierend, wenn keiner von ihnen so ist, wie es für Ihr eigenes System fehlschlägt.
user3562927
Sie alle sind zufällig der gleiche Fehler: Der angegebene Truststore konnte nicht geöffnet werden oder war leer. Es gibt eine Million Möglichkeiten, wie diese Situation auftreten kann, und auf SO ist nicht genügend Speicherplatz vorhanden, um sie alle aufzuzählen.
Marquis von Lorne
1

Unter Red Hat Linux wurde dieses Problem durch Importieren der Zertifikate in behoben /etc/pki/java/cacerts.

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

Sie müssen die obigen zwei Zeilen zu Ihrem Code hinzufügen. Der Truststore kann nicht gefunden werden.

Divyesh Kalbhor
quelle
2
Wenn Sie dies nicht tun, wird der JRE-Truststore verwendet, und das kann er mit Sicherheit finden. Der Fehler wird durch falsche Werte in diesen Parametern verursacht, nicht durch deren Fehlen. Die in Ihrem Code angegebene Datei gilt nur für Ihre Installation, nicht generell.
Marquis von Lorne
Sie können diese Eigenschaften ordnungsgemäß festlegen, indem Sie sie in der Befehlszeile übergeben. java -Djavax.net.ssl.trustStore=/tmp/cacerts ...Wenn Sie sie global für alle mit einem JDK ausgeführten Programme festlegen möchten, fügen Sie die Zeile zur management.propertiesDatei des JDK hinzu .
Mikael Gueck
1

Ich hatte dieses Problem, als ich eine bestimmte Android-Suite zum Testen unter Ubuntu 14.04 (Trusty Tahr) ausführte. Zwei Dinge haben bei mir funktioniert, wie von Shaheen vorgeschlagen:

sudo update-ca-certificates -f

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

Keine der Lösungen, die ich im Internet gefunden habe, hat funktioniert, aber eine modifizierte Version von Peter Kriens 'Antwort scheint den Job zu erledigen.

Suchen Sie zuerst Ihren Java-Ordner, indem Sie ausführen /usr/libexec/java_home. Für mich war es die 1.6.0.jdkVersion. Dann gehen Sie zu seinem lib/securityUnterordner (für mich/Library/Java/JavaVirtualMachines/1.6.0.jdk/Contents/Home/lib/security ).

Löschen Sie dann die cacertsDatei, falls bereits eine vorhanden ist, und suchen Sie mit auf dem System nach einer sudo find / -name "cacerts". Es wurden mehrere Elemente für mich gefunden, in Versionen von Xcode oder anderen Anwendungen, die ich installiert hatte, aber auch bei/Library/Internet Plug-Ins/JavaAppletPlugin.plugin/Contents/Home/lib/security/cacerts denen ich mich entschieden habe.

Verwenden Sie diese Datei und stellen Sie einen symbolischen Link zu ihr her (während Sie sich zuvor im Java-Ordner befinden). sudo ln -fsh "/Library/Internet Plug-Ins/JavaAppletPlugin.plugin/Contents/Home/lib/security/cacerts" Es sollte funktionieren.

Ich habe sowohl Java von Apples Download 2017-001 ( https://support.apple.com/kb/dl1572 - ich nehme an, dass dort die richtigen Zertifikate stammen) als auch das von Oracle unter Mac OS X 10.12 (Sierra) installierte. .

shw
quelle
1

am ubuntu 14.04 mit openjdk 11 von ppa: openjdk-r / ppa das hat bei mir funktioniert:

Ändern Sie in java.security den Keystore-Typ in

keystore.type=jks

dann:

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

Wenn Sie überprüfen, ob es funktioniert hat, stellen Sie sicher, dass Sie keinen Daemon verwenden, auf dem noch altes Java ausgeführt wird (z. --no-daemon Option für Gradle).

Dieser Fehler beschreibt schön alles und hilft Ihnen zu verstehen , was los ist https://bugs.launchpad.net/ubuntu/+source/ca-certificates-java/+bug/1739631

Piotrek
quelle
1

Unter Ubuntu 18.04 musste ich OpenJDK 1.7 für die Wartung eines alten Projekts verwenden. Ich habe das Binärpaket heruntergeladen. Aber als ich mein Skript darauf ausführte, bekam ich den gleichen Fehler.

Die Lösung bestand darin, die cacertsDatei des heruntergeladenen JDK aus dem jre/lib/securityOrdner zu entfernen und sie dann als Symlink zur Systemdatei zu cacertserstellen in /etc/ssl/certs/java/:

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

Mike
quelle
1

Geringe Chance, dass dies jedem hilft, aber ... für jeden, der Java 8 von einem Docker-Image auf einem Raspberry Pi (mit AMD-CPU) ausführt, habe ich die folgende Docker-Datei, die ich erfolgreich erstellen und ausführen kann

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"]
Christian Bartram
quelle