Fehler - trustAnchors-Parameter darf nicht leer sein

Question

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

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

Ich habe im Internet zahlreiche Informationen über diesen Fehler gefunden, aber ich habe keine davon gefunden. Ich verwende das JDK von Sun auf Fedora Linux (nicht OpenJDK).

Hier sind ein paar Dinge, die ich ausprobiert habe. Ich habe versucht, den Rat aus diesem Beitrag , aber das Kopieren der Cacerts von Windows auf meine Fedora-Box, die Jenkins hostet, hat nicht funktioniert. Ich habe Folgendes versucht dieser Leitfaden da ich versuche, Gmail als meinen SMTP-Server zu konfigurieren, aber auch das hat nicht funktioniert. Ich habe auch versucht, die cacert-Dateien manuell herunterzuladen und in meinen Java-Ordner zu verschieben, indem ich eine Variation der Befehle auf dieser Leitfaden .

Ich bin für jeden Vorschlag offen, da ich im Moment nicht weiterkomme. Ich habe es von einem Windows-Hudson-Server aus zum Laufen gebracht, aber unter Linux habe ich Schwierigkeiten.

Answer 1

Ich hatte dieses Problem, als ich versuchte, die Maven 3, nach dem Upgrade von Ubuntu 16.04 LTS (Xenial Xerus) auf Ubuntu 18.04 LTS (Bionischer Biber).

Die Überprüfung von /usr/lib/jvm/java-8-oracle/jre/lib/security ergab, dass meine cacerts-Datei ein symbolischer Link war, der auf /etc/ssl/certs/java/cacerts .

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

Ich habe umbenannt cacerts.original a cacerts und damit war das Problem behoben.

Answer 2

Das Problem trat auch unter OS X auf, nachdem ich OS X v10.9 (Mavericks) aktualisiert hatte, als das alte Java 6 verwendet wurde und ich versuchte, auf eine HTTPS-URL zuzugreifen. Die Lösung war die Umkehrung von Peter Kriens; ich musste die cacerts aus dem 1.7-Speicherplatz an den mit der 1.6-Version verknüpften Ort:

(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

Answer 3

Ich bin auf dieses Problem mit dem Android SDK sdkmanager gestoßen. Für mich hat diese Lösung funktioniert:

1. Aller à /usr/lib/jvm/java-8-oracle/jre/lib/security/
2. 交換 cacert mit cacert.original

El cacert Datei war eine winzige Datei (22B). Ich habe installiert oracle-java8-installer de ppa:webupd8team/java (gemäß diesem Handbuch: https://docs.nativescript.org/start/ns-setup-linux ).

Answer 4

Marquis von Lornes Antwort korrekt ist, füge ich einige Informationen für die Fehlersuche hinzu:

Um dieses Problem zu beheben (ich schrieb darüber mit mehr Details in aquí ) und verstehen, welcher Truststore verwendet wird (oder zu verwenden versucht), können Sie die Immobilie javax.net.debug=all und filtern Sie dann die Protokolle über Truststore. Sie können auch mit der Eigenschaft javax.net.ssl.trustStore spielen, um einen bestimmten Truststore anzugeben. Zum Beispiel :

    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

Answer 5

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 ausgeführt habe, bekam ich den gleichen Fehler.

Die Lösung bestand darin, die cacerts Datei des heruntergeladenen JDK in der jre/lib/security zu erstellen und dann als Symlink zum System cacerts Datei in /etc/ssl/certs/java/ :

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