web-dev-qa-db-de.com

Fehler - Der Parameter trustAnchors darf nicht leer sein

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

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

Ich habe eine Menge Informationen online über den Fehler gesehen, aber ich habe keine zur Arbeit bekommen. Ich verwende das Sun-JDK unter Fedora Linux (nicht OpenJDK).

Hier sind ein paar Dinge, die ich ausprobiert habe. Ich habe versucht, den Ratschlägen in diesem post zu folgen, aber das Kopieren der Cacerts von Windows in meine Fedora-Box, die Jenkins hostet, funktionierte nicht. Ich habe versucht, this guide zu folgen, da ich versuche, Google Mail als SMTP-Server zu konfigurieren, aber es hat auch nicht funktioniert. Ich habe auch versucht, diese cacert-Dateien manuell herunterzuladen und zu verschieben und sie mithilfe einer Variation der Befehle in this guide in meinen Java-Ordner zu verschieben.

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

406
David Gill

Diese bizarre Nachricht bedeutet, dass der von Ihnen angegebene Truststore Folgendes war:

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

Siehe auch @ AdamPlumbs Antwort unten .

429
user207421

In Ubuntu 18.04 hat dieser Fehler eine andere Ursache (JEP 229, wechseln Sie vom jks-Keystore-Standardformat zum pkcs12-Format und verwenden Sie die Standardeinstellung für neue Dateien für die Debian-Cacerts-Datei) und Workaround :

# 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

https://git.mikael.io/mikaelhg/broken-docker-jdk9-cacerts


Status (2018-08-07), der Fehler wurde in Ubuntu Bionic LTS 18.04.1 und Ubuntu Cosmic 18.10 behoben. 


???? Ubuntu 1770553: [SRU] Rückport-CA-Zertifikate-Java von Cosmic (20180413ubuntu1)

???? Ubuntu 1769013: Bitte mischen Sie ca-certificate-Java 20180413 (main) von Debian instabil (main) zusammen

???? Ubuntu 1739631: Neuinstallation mit JDK 9 kann die generierte PKCS12-Cacerts-Keystore-Datei nicht verwenden

???? docker-library 145: 9-jdk-Image hat SSL-Probleme

???? Debian 894979: CA-Zertifikate-Java: funktioniert nicht mit OpenJDK 9, Anwendungen schlagen mit InvalidAlgorithmParameterException fehl: Der Parameter trustAnchors darf nicht leer sein

???? JDK-8044445: JEP 229: PKCS12-Keystores standardmäßig erstellen

???? JEP 229: PKCS12-Keystores standardmäßig erstellen


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

$ which Java
/usr/bin/Java

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

$ Sudo update-Java-alternatives -a
update-alternatives: error: no alternatives for mozilla-javaplugin.so

Sie können die Java-Version, die Sie ausführen, noch einmal ü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 Wartung in der Zukunft erfordern werden, ohne dass sich dies auszahlt.

Die nächstbeste Lösung ist das Hinzufügen der Zeile

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 dritte problematischste 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

welche vorhanden ist, entfernen Sie dann die cacerts-Datei und erstellen Sie sie auf die zuvor beschriebene Weise neu.

230
Mikael Gueck

Das Problem für mich unter Ubuntu wurde behoben:

Sudo /var/lib/dpkg/info/ca-certificates-Java.postinst configure

(Hier finden Sie: https://bugs.launchpad.net/ubuntu/+source/ca-certificates-Java/+bug/1396760 )

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

96

Unter Ubuntu 18.04 liegt die Hauptursache in einem Konflikt zwischen openjdk-11-jdk (standardmäßig) und anderen davon abhängigen Paketen. Es wurde bereits in Debian behoben und wird in Kürze in Ubuntu enthalten sein. In der Zwischenzeit ist es am einfachsten, Java auf Version 8 zu reduzieren. Andere Lösungen, die ca-certificates-Java verwenden, sind viel komplizierter.

Entfernen Sie zunächst in Konflikt stehende 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, es steht kein Java für config zur Verfügung, andernfalls schlägt diese Problemumgehung fehl [.

Installieren Sie dann die erforderlichen Pakete erneut:

Sudo apt-get install openjdk-8-jdk
57
shvahabi

Ich bin auf diese Lösung aus einem Blog-Beitrag gestoßen Behebung des TrustAnchors-Problems beim Ausführen von OpenJDK 7 unter OS X:

Beheben 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. Verlinken Sie einfach die gleiche 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 installierte OpenJDK-Version tun. Ändern Sie einfach -v 1.7 in die Version, die Sie korrigieren möchten. Führen Sie /usr/libexec/Java_home -V aus, um alle installierten JREs und JDKs anzuzeigen.

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

52
Peter Kriens

EJP beantwortete die Frage im Wesentlichen (und mir ist klar, dass dies eine akzeptierte Antwort ist), aber ich habe mich gerade mit diesem Fall befasst und wollte meine Lösung verewigen.

Ich hatte den InvalidAlgorithmParameterException-Fehler auf einem gehosteten Jira -Server, den ich zuvor für den Zugriff nur mit SSL 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. Ich habe jedoch nicht den TruststoreType angegeben. Daher wird standardmäßig der KeystoreType verwendet. Die Angabe des truststoreType explizit als JKS hat es für mich gelöst.

50
Adam Plumb

In Ubuntu 12.10 (Quantal Quetzal) oder höher werden die Zertifikate im ca-certificate-Java -Paket gehalten. Mit -Djavax.net.ssl.trustStore=/etc/ssl/certs/Java/cacerts werden sie unabhängig von dem verwendeten JDK abgeholt.

37
yvesr

Ich habe dieses genaue Problem unter OS X mit JDK 1.7 nach einem Upgrade auf OS X 10.9 (Mavericks) festgestellt. Die Lösung, die für mich funktionierte, bestand darin, die Apple-Version von Java, die unter http://support.Apple.com/kb/DL1572 verfügbar ist, einfach neu zu installieren.

33
KiwiMartin

Ich rannte

Sudo update-ca-certificates -f

so erstellen Sie eine Zertifikatsdatei und dann:

Sudo /var/lib/dpkg/info/ca-certificates-Java.postinst configure

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

25
Johnny

Ich hatte nach dem Upgrade auf OS X v10.9 (Mavericks) viele Sicherheitsprobleme:

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

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

10
Freddy Boucher

Für mich wurde dies durch das Fehlen eines trustedCertEntry im Truststore verursacht.

Zum Testen verwenden Sie:

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 ein CAenthält, muss es separat importiert werden:

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

Das Zertifikat wird importiert und anschließend wird keytool -list -keystore keystore.jks erneut ausgeführt.

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.

8
muttonUp

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

Unter Windows habe ich die cacerts-Datei von jre/lib/security in das Eclipse-Installationsverzeichnis kopiert (dieselbe Stelle wie die Eclipse.ini-Datei) und die folgenden Einstellungen in Eclipse.ini hinzugefügt:

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

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

Die Idee ist, einen gültigen Pfad zur Truststore-Datei anzugeben - idealerweise wäre es eine relative. Sie können auch einen absoluten Pfad verwenden.

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

keytool -list -keystore cacerts

Keystore type: JKS
Keystore provider: Sun
8
razvanone

Ich habe solche Dinge erwartet, da ich eine alternative JVM in meinem Talend Open Studio verwende (der Support besteht im Moment nur bis JDK 1.7). Ich verwende 8 aus Sicherheitsgründen ... sowieso

  • Aktualisieren Sie Ihren Zertifikatsspeicher:

    Sudo update-ca-certificates -f
    

dann

  • fügen Sie einen neuen Wert in Ihre Initialisierungsparameter ein

    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 funktionierte der zweite Eintrag. Ich denke, abhängig von der Version von Talend Open Studio/TEnt + JVM hat es einen anderen Parameternamen, sucht aber nach derselben Keystore-Datei.

8
steveoams

Das Entfernen des CA-Zertifikate-Java-Pakets und die erneute Installation funktionierten für mich ( 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-certificate-Java installiert keine Java-Zertifikate auf Oneiric Ocelot.

7
ericek111

Wenn dies bei 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 nicht vorhanden ist, installieren Sie das CA-Zertifikate-Java wie folgt:

Sudo apt install ca-certificates-Java
4
dmatej

Ich hatte dieses Problem beim Versuch, Maven 3 zu verwenden, nachdem ich ein Upgrade von Ubuntu 16.04 LTS (Xenial Xerus) auf Ubuntu 18.04 LTS (Bionic Beaver) durchgeführt hatte.

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 verweist.

Ich hatte auch eine Datei namens cacerts.original.

Ich habe cacerts.original in cacerts umbenannt, und das Problem wurde behoben.

4
John Deverall

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

Siehe den Abschnitt "Bekannte Probleme" in - JDK 9.0.1 Versionshinweise und sagt "TLS funktioniert nicht standardmäßig unter OpenJDK 9".

Unter Debian/Ubuntu (und wahrscheinlich auch anderen Derivaten) besteht eine einfache Problemumgehung darin, die Cacerts-Datei durch die Datei aus dem Paket "ca-certification-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-certificate" tun:

Sudo yum install ca-certificates
cp /etc/pki/Java/cacerts /path/to/jdk-9.0.1/lib/security/cacerts
3
Mossroy

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

Das Problem liegt in der Art und Weise, wie Tomcat mit dem Trust Store umgeht. Wenn Sie Ihren Trust Store-Speicherort in der Spring Boot-Konfiguration mit dem Keystore identisch festgelegt haben, wird beim Starten der Anwendung wahrscheinlich die Meldung trustAnchors parameter must be non-empty angezeigt.

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

Entfernen Sie einfach die server.ssl.trust-store-Konfiguration, sofern Sie nicht wissen, dass Sie sie benötigen. In diesem Fall finden Sie die Links unten.

Die folgenden Probleme enthalten weitere Details zu dem Problem:

3
Robert Hunt

Dies ist auch auf OS X nach der Aktualisierung von OS X 10.9 (Mavericks) aufgetreten, als das alte Java 6 verwendet wurde und versucht wurde, auf eine HTTPS-URL zuzugreifen. Das Update war das Gegenteil von Peter Kriens; Ich musste die cacerts aus dem 1.7-Bereich an den durch die 1.6-Version verknüpften Ort 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
3
Partly Cloudy

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 Clientanwendung als Vertrauensspeicher verwendet, z.

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

Quelle: Java SSL und Zertifikatsschlüsselspeicher

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

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

Sie müssen die beiden obigen Zeilen in Ihren Code einfügen. Der Truststore kann nicht gefunden werden.

2
Divyesh Kalbhor

Dieses Problem ist beim Android SDK sdkmanager aufgetreten. Für mich hat diese Lösung funktioniert:

  1. Gehen Sie zu/usr/lib/jvm/Java-8-Oracle/jre/lib/security /
  2. Ersetzen Sie "cacert" durch "cacert.original".

Die "cacert" -Datei war eine winzige (22B). Ich habe Oracle-Java8-Installer von ppa installiert: webupd8team/Java (gemäß diesem Handbuch: https://docs.nativescript.org/start/ns-setup-linux ). 

2
Tyg

Keine der Lösungen, die ich im Internet gefunden habe, funktionierte, aber eine modifizierte Version von Peter Kriens 'Antwort scheint die Aufgabe zu erfüllen.

Suchen Sie zunächst Ihren Java-Ordner, indem Sie /usr/libexec/Java_home ausführen. Für mich war es die 1.6.0.jdk-Version. Dann gehe in den lib/security-Unterordner (für mich /Library/Java/JavaVirtualMachines/1.6.0.jdk/Contents/Home/lib/security).

Löschen Sie anschließend die cacerts-Datei, falls bereits eine vorhanden ist, und suchen Sie mit Sudo find / -name "cacerts" nach einer im System. Es hat mehrere Artikel für mich gefunden, in Versionen von Xcode oder anderen Anwendungen, die ich installiert hatte, aber auch unter /Library/Internet Plug-Ins/JavaAppletPlugin.plugin/Contents/Home/lib/security/cacerts, die ich ausgewählt habe.

Verwenden Sie diese Datei und erstellen Sie einen symbolischen Link zu Sudo ln -fsh "/Library/Internet Plug-Ins/JavaAppletPlugin.plugin/Contents/Home/lib/security/cacerts" (während sie sich zuvor im Java-Ordner befunden hat), und es sollte funktionieren.

Ich habe beide - Java von Apples 2017-001 ( https://support.Apple.com/kb/dl1572 - ich nehme an, dass die richtigen Zertifikate von dort stammen) und Oracle auf Mac OS X v10.12 (Sierra).

1
shw

In Windows10 und OpenJDK wurde eine leere Cacerts-Datei mit der Binärdatei verteilt. Der Fehler wird hier erklärt: https://github.com/AdoptOpenJDK/openjdk-build/issues/555

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

Die fehlerhafte AdoptOpenJDK-Version ist https://github.com/AdoptOpenJDK/openjdk8-releases/releases/download/jdk8u172-b11/OpenJDK8_x64_Win_jdk8u172-b11.Zip

1
raisercostin

Dieses Problem hatte ich beim Ausführen einer bestimmten Android-Suite zum Testen auf Ubuntu 14.04 (Trusty Tahr). Zwei Dinge funktionierten für mich, wie von Shaheen vorgeschlagen:

Sudo update-ca-certificates -f

Sudo /var/lib/dpkg/info/ca-certificates-Java.postinst configure
1
DPKGRG

Für das Protokoll hat none der Antworten für mich funktioniert. Mein Gradle-Build begann mit diesem Fehler auf mysteriöse Weise und konnte HEAD nicht von Mavencentral für eine bestimmte POM -Datei abrufen.

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

1
user3562927

Ein weiterer Grund dafür ist, dass es sich tatsächlich um einen gültigen Fehler handelt. Einige schändliche Wi-Fi-Hotspots verwirren sich mit Zertifikaten und man-in-the-middle-Angriffen Sie müssen tun, wer weiß, was (läuft weg!).

Einige große Arbeitgeber wenden diesen Trick an, vor allem in sensiblen Netzwerkzonen, um den gesamten verschlüsselten Datenverkehr zu überwachen (aus Endbenutzersicht nicht besonders gut, aber es gibt gute Gründe).

0
Matt Broekhuis

Auf Ubuntu:

Sudo kann ca-certificates-Java installieren

oder

Sudo apt-get installiert ca-certificates-Java

hat es für mich sortiert.

0
The Tomahawk

Ich habe diesen Fehler erhalten, als ich einen Truststore verwendet habe, der mit einem IBM Websphere JDK-Keytool im # PKCS12-Format exportiert wurde und versuchte, über SSL mit dieser Datei auf einer Oracle JRE zu kommunizieren.

Meine Lösung bestand darin, auf einer IBM JRE zu laufen oder den Truststore mit einem IBM Websphere-Keytool in JKS zu konvertieren, sodass ich es in einer Oracle-JRE ausführen konnte.

0
Maarten

Ich habe das Problem beim Importieren eines Gradle-Projekts in IntelliJ IDEA 14 festgestellt. Eine Lösung verwendete eine lokale Kopie von Gradle anstelle eines Wrappers aus dem Projektverzeichnis.

0
Sergey Filkin

Eigentlich musst du nur Folgendes ausführen:

Sudo chmod +x ./gradlew(your script)
0
Begin2Pip

am ubuntu 14.04 mit openjdk 11 von ppa: openjdk-r/ppa das hat für mich 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 prüfen, ob es funktioniert hat, stellen Sie sicher, dass Sie keinen Dämon mit altem Java verwenden (zB --no-daemon-Option für gradle).

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

0
piotrek

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

0
ak1

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 im jre/lib/security -Ordner zu entfernen und sie dann als Symlink zur cacerts -Datei des Systems in /etc/ssl/certs/Java/ zu erstellen:

Sudo ln -s /etc/ssl/certs/Java/cacerts /path/to/downloaded/Java/jre/lib/security/cacerts

0
Mike

Ich habe beim Senden von E-Mails die gleiche Fehlermeldung erhalten, aber NICHT immer. In meinem Fall habe ich eine Codezeile geändert, um jedes Mal ein neues Session -Objekt zu erhalten:

MimeMessage message = new MimeMessage(Session.getDefaultInstance(props, authenticator));

zu

MimeMessage message = new MimeMessage(Session.getInstance(props, authenticator));

Seitdem funktioniert das Versenden von E-Mails immer.

Der Fehler, den ich bekam:

javax.mail.MessagingException: Socket konnte nicht in TLS konvertiert werden. 
verschachtelte Ausnahme ist: javax.net.ssl.SSLException: 
Java.lang.RuntimeException: Unerwarteter Fehler: 
Java.security.InvalidAlgorithmParameterException: Die TrustAnchors 
Parameter darf nicht leer sein 
com.Sun.mail.smtp.SMTPTransport.startTLS (SMTPTransport.Java:1907) um 
com.Sun.mail.smtp.SMTPTransport.protocolConnect (SMTPTransport.Java:666) 
um javax.mail.Service.connect (Service.Java:317) um 
javax.mail.Service.connect (Service.Java:176) um 
javax.mail.Service.connect (Service.Java:125) um 
javax.mail.Transport.send0 (Transport.Java:194) um 
javax.mail.Transport.send (Transport.Java:124) 

0
marioosh

Ich habe noch einen weiteren Grund für diesen Fehler gefunden, der nicht mit Ubuntu zusammenhängt.

Ich habe versucht, gegenseitiges TLS in einer Spring Boot 2-App einzurichten, und bin auf dieses Problem gestoßen, nachdem ich einen Truststore verwendet hatte, der nur einen privaten Schlüsseleintrag und keinen vertrauenswürdigen Zertifikateintrag hatte.

Dies ist meine Spring Boot TLS-Konfiguration

server.port=8443
server.ssl.key-alias=oba-tls
server.ssl.key-password=mypw
server.ssl.key-store-password=mypw
server.ssl.key-store=classpath:keys/tls-keystore.pfx
server.ssl.key-store-type=PKCS12
server.ssl.enabled=true
server.ssl.client-auth=need

server.ssl.trust-store=classpath:keys/truststore.pfx
server.ssl.trust-store-password=mypw
server.ssl.trust-store-type=PKCS12
server.ssl.ciphers=ECDHE-RSA-AES128-GCM-SHA256,ECDHE-RSA-AES256-SHA384
server.ssl.protocol=TLS
server.ssl.enabled-protocols=TLSv1.2

Zum Generieren von truststore.pfx musste ich die folgenden Befehle verwenden, damit es funktioniert.

openssl req -newkey rsa:2048 -nodes -keyout private.key -x509 -out cert.crt

keytool -importcert -alias oba-trust -file cert.crt -keystore truststore.jks

keytool -importkeystore -srckeystore truststore.jks -destkeystore truststore.pfx -srcstoretype JKS - deststoretype PKCS12 -deststorepass yourpassword
0
Julius

Ich hatte den gleichen Fehler und das Problem lag nicht in der Konfiguration des JDK, sondern in einem einfachen falschen Pfad zur JKS-Datei in der Datei application.properties unter dem Parameter 'trust-store:'. Überprüfen Sie noch einmal, ob der Pfad korrekt ist.

0

Für mich wurde das Problem gelöst, indem ein Jenkins-Plugin "Email Extension Plugin" auf die neueste Version (2.61) aktualisiert wurde.

Diese beiden Plugins sind für die E-Mail-Konfiguration in Jenkins verantwortlich:

  • E-Mail-Erweiterung
  • E-Mail-Erweiterungsvorlage
0
himanshu vyas