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.
${CATALINA_HOME}\conf
,CATALINA_HOME
wurde aber nicht eingerichtet, sodass Tomcat nach\conf
dem Truststore suchte.In Ubuntu 18.04 hat dieser Fehler eine andere Ursache (JEP 229, Wechseln vom
jks
Keystore-Standardformat zumpkcs12
Format und Generieren der Debian-Cacerts-Datei unter Verwendung der Standardeinstellung für neue Dateien) und Problemumgehung :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.
Sie können die Java-Alternativen auf 'auto' setzen mit:
Sie können die von Ihnen ausgeführte Java-Version überprüfen:
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
zu den Dateien
was auch immer existiert.
Die drittniedrigste problematische Problemumgehung besteht darin, den Wert von zu ändern
zu
in den Dateien
Entfernen Sie die
cacerts
Datei und generieren Sie sie auf die in der letzten Zeile des Workaround-Skripts oben im Beitrag beschriebene Weise neu.quelle
Dies hat das Problem für mich unter Ubuntu behoben:
(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.quelle
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-java
sind viel komplizierter.Entfernen Sie zuerst widersprüchliche Pakete:
Überprüfen Sie, ob Sie alle zugehörigen Pakete erfolgreich entfernt haben, indem Sie:
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:
quelle
openjdk-8-jdk
Paket installieren , die/etc/ssl/certs/java/cacerts
Datei entfernen und ausführen. Diessudo update-ca-certificates -f
ist der Umweg, um von einerpkcs12
formatierten Cacerts-Datei zu einerjks
formatierten zu wechseln , wie an anderer Stelle in diesem Thread beschrieben.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
InvalidAlgorithmParameterException
Fehler 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.xml
Datei 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.quelle
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:
Es gibt eine einfache Lösung. Verknüpfen Sie einfach dieselbe Cacerts-Datei, die Apples JDK 1.6 verwendet:
Sie müssen dies für jede OpenJDK-Version tun, die Sie installiert haben. Wechseln
-v 1.7
Sie einfach zu der Version, die Sie reparieren möchten. Führen Sie/usr/libexec/java_home -V
sehen , alle JREs und JDKs Sie installiert haben.Vielleicht könnten die OpenJDK-Leute dies zu ihren Installationsskripten hinzufügen.
quelle
security
Ordner (blacklisted.certs
,local_policy.jar
, undUS_export_policy.jar
) für Java , glücklich zu sein.cacerts
unterjre
Verzeichnis verlinkt ?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/cacerts
wird sie unabhängig vom verwendeten JDK abgerufen.quelle
update-ca-certificates -f
manuell ausführen musste , um die cacerts-Datei zu füllenNach 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 .
quelle
ich rannte
um eine Zertifikatdatei zu erstellen, und dann:
Ich war wieder im Geschäft, danke Jungs. Schade, dass es nicht in der Installation enthalten ist, aber ich bin am Ende dort angekommen.
quelle
sudo /var/lib/dpkg/info/ca-certificates-java.postinst configure**
bekomme ichsudo: /var/lib/dpkg/info/ca-certificates-java.postinst: command not found
sudo update-ca-certificates -f
ist genug auf Debian Jessie mitopenjdk-8-jre-headless
von Jessie-Backports, solangeca-certificates-java
installiert. Ich denke, die Reihenfolge der Installation ist wichtig (JRE nachca-certificates-java
kann dies verursachen, da letztere keine Auslöser für das zurückportierte Java 8 hat).sudo /var/lib/dpkg/info/ca-certificates-java.postinst configure
ohne Sterne **update-ca-certificates -f
ist das, was es behoben hat. Ich brauchte den 2. Befehl nichtDer 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
cacerts
Datei ausjre/lib/security
dem Eclipse-Installationsverzeichnis (am selben Ort wie dieeclipse.ini
Datei) kopiert und die folgenden Einstellungen hinzugefügteclipse.ini
: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:
quelle
Das Entfernen des ca-certificates-java-Pakets und das erneute Installieren funktionierten bei mir ( Ubuntu MATE 17.10 (Artful Aardvark)).
Vielen Dank, jdstrand: Kommentar 1 für Fehler 983302, Re: ca-certificates-java kann Java-Cacerts nicht auf Oneiric Ocelot installieren .
quelle
Nach dem Upgrade auf OS X 10.9 (Mavericks) gab es viele Sicherheitsprobleme :
trustAnchors
Parameter darf nicht leer seinIch habe dieses Java-Update angewendet und alle meine Probleme behoben: http://support.apple.com/kb/DL1572?viewlocale=de_DE
quelle
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:
dann
Fügen Sie Ihren Initialisierungsparametern einen neuen Wert hinzu
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.
quelle
javax.net.ssl.trustAnchors
? Es wird in der JSSE-Dokumentation nicht erwähnt.Für mich war dies auf das Fehlen eines TrustedCertEntry im Truststore zurückzuführen.
Verwenden Sie zum Testen:
Es gibt mir:
Obwohl mein PrivateKeyEntry eine Zertifizierungsstelle enthält , musste er separat importiert werden :
Es importiert das Zertifikat und führt dann durch erneutes Ausführen
keytool -list -keystore keystore.jks
Folgendes aus:Jetzt hat es einen TrustedCertEntry und Tomcat wird erfolgreich gestartet.
quelle
Einige OpenJDK-Anbieterversionen haben dies dadurch verursacht, dass eine leere
cacerts
Datei mit der Binärdatei verteilt wurde. Der Fehler wird hier erklärt: https://github.com/AdoptOpenJDK/openjdk-build/issues/555Sie können
adoptOpenJdk8\jre\lib\security\cacerts
von einer alten Installation wie in die Datei kopierenc:\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
quelle
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:
Wenn die Datei fehlt, versuchen Sie, ca-certificates-java wie folgt zu installieren:
quelle
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:
Unter Red Hat Linux / CentOS können Sie dasselbe mit dem Paket "ca-certificates" tun:
quelle
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.original
zucacerts
, und dass das Problem behoben.quelle
cacerts.original
Datei hatte dasjks
Format und wurde mit Java 8 von Ubuntu 16.04 generiert, das dieses Format als Standard verwendete. Diecacerts
Datei hatte daspkcs12
Format, 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 leerejks
cacerts
Datei 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.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
cacerts
aus dem 1.7-Bereich an den durch die 1.6-Version verknüpften Speicherort kopieren :quelle
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:
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 .
quelle
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-empty
Meldung wahrscheinlich beim Starten der Anwendung angezeigt.Entfernen
server.ssl.trust-store
Sie 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:
quelle
Ich habe dieses Problem mit dem Android SDK sdkmanager festgestellt. Für mich hat diese Lösung funktioniert:
/usr/lib/jvm/java-8-oracle/jre/lib/security/
cacert
durchcacert.original
Die
cacert
Datei war winzig (22B). Ich habe installiertoracle-java8-installer
vonppa:webupd8team/java
(nach dieser Anleitung: https://docs.nativescript.org/start/ns-setup-linux ).quelle
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.
quelle
Unter Red Hat Linux wurde dieses Problem durch Importieren der Zertifikate in behoben
/etc/pki/java/cacerts
.quelle
Sie müssen die obigen zwei Zeilen zu Ihrem Code hinzufügen. Der Truststore kann nicht gefunden werden.
quelle
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 zurmanagement.properties
Datei des JDK hinzu .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:
quelle
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 die1.6.0.jdk
Version. Dann gehen Sie zu seinemlib/security
Unterordner (für mich/Library/Java/JavaVirtualMachines/1.6.0.jdk/Contents/Home/lib/security
).Löschen Sie dann die
cacerts
Datei, falls bereits eine vorhanden ist, und suchen Sie mit auf dem System nach einersudo 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. .
quelle
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
dann:
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
quelle
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
cacerts
Datei des heruntergeladenen JDK aus demjre/lib/security
Ordner zu entfernen und sie dann als Symlink zur Systemdatei zucacerts
erstellen in/etc/ssl/certs/java/
:sudo ln -s /etc/ssl/certs/java/cacerts /path/to/downloaded/java/jre/lib/security/cacerts
quelle
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
quelle