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

Wenn Sie dieses Problem unter Ubuntu mit JDK9 und Maven haben, können Sie diese JVM-Option hinzufügen - prüfen Sie zunächst, ob der Pfad existiert:

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

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

sudo apt install ca-certificates-java

Answer 2

Ich bin ein Fan von Portabilität, also installiere ich kein Java, sondern lade einfach das tar.gz herunter und exportiere einige Werte in den Pfad, und alles funktioniert.

Ich habe mit diesem Problem gekämpft, und keine Lösung (Installation oder Aktualisierung von Zertifikaten für operative Systeme) hat bei mir funktioniert.

Der Fehler in meinem Fall war: leere Cacerts in meinem JDK.

Ich weiß nicht, warum, aber meine jdk.tar.gz hatte eine leere cacerts-Datei

/../some_openjdk/jre/lib/security/cacerts Größe: 32 Bytes

Heruntergeladen von:

• https://download.java.net/openjdk/jdk8u41/ri/openjdk-8u41-b04-linux-x64-14_jan_2020.tar.gz
• https://download.java.net/java/GA/jdk9/9/binaries/openjdk-9_linux-x64_bin.tar.gz

Fix

Nach mehreren Versuchen fand ich eine korrekte jdk.tar.gz mit einer cacerts Datei mit Größe 101 KB

Ich habe dieses offene jdk heruntergeladen von https://github.com/AdoptOpenJDK/openjdk8-upstream-binaries

• https://github.com/AdoptOpenJDK/openjdk8-upstream-binaries/releases/download/jdk8u262-b10/OpenJDK8U-jdk-jfr_x64_linux_8u262b10.tar.gz

Ich habe diese Url in diesem Dockerfile gefunden:

• https://github.com/docker-library/openjdk/blob/b5d14d9165fad693901c285d6e7bbc36d1cde41f/8/jdk/Dockerfile

Answer 3

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

Siehe den Abschnitt "Bekannte Probleme" in JDK 9.0.1 Versionshinweise mit der Aussage "TLS funktioniert nicht standardmäßig unter OpenJDK 9".

Unter Debian/Ubuntu (und wahrscheinlich auch anderen Derivaten) besteht eine einfache Abhilfe darin, die cacerts-Datei durch die Datei 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 das gleiche 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

Answer 4

Dieser Fehler kann auch nach einem Upgrade auf Spring Boot 1.4.1 (oder neuer) auftreten, da es Folgendes mit sich bringt Tomcat 8.5.5 als Teil seiner Abhängigkeiten.

Das Problem liegt in der Art und Weise begründet, wie Tomcat mit dem Trust Store umgeht. Wenn Sie in der Spring Boot-Konfiguration den Speicherort Ihres Vertrauensspeichers mit dem Ihres Schlüsselspeichers identisch gemacht haben, erhalten Sie wahrscheinlich die Meldung trustAnchors parameter must be non-empty Meldung beim Starten der Anwendung.

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

Entfernen Sie einfach die server.ssl.trust-store Konfiguration, es sei denn, Sie wissen, dass Sie sie benötigen; in diesem Fall konsultieren Sie die nachstehenden Links.

In den folgenden Ausgaben finden Sie weitere Einzelheiten zu diesem Problem:

• HTTPS Tomcat-Konnektor startet nicht mit 1.4.1 #7069
• SSL-Client-Authentifizierung mit selbst signiertem Zertifikat funktioniert nicht mehr #7406
• Upgrade auf Tomcat 8.5.5 #6703

Answer 5

In meinem Fall war die in der Client-Anwendung verwendete JKS-Datei beschädigt. Ich erstellte eine neue Datei und importierte die SSL-Zertifikate des Zielservers in diese Datei. Dann habe ich die neue JKS-Datei in der Client-Anwendung als Vertrauensspeicher verwendet, etwa so:

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

Fuente: Java-SSL und Zertifikats-Keystore

Ich verwende das Tool (KeyStore Explorer), um den neuen JKS zu erstellen. Sie können es von diesem Link herunterladen, Schlüsselspeicher-Explorer .