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.
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 .
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)
???? docker-library 145: 9-jdk-Image hat SSL-Probleme
???? 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.
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.
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
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.
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.
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.
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.
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.
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
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.
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
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.
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.
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
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.
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
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:
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
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 .
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.
Dieses Problem ist beim Android SDK sdkmanager aufgetreten. Für mich hat diese Lösung funktioniert:
- Gehen Sie zu/usr/lib/jvm/Java-8-Oracle/jre/lib/security /
- 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 ).
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).
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
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
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.
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).
Auf Ubuntu:
Sudo kann ca-certificates-Java installieren
oder
Sudo apt-get installiert ca-certificates-Java
hat es für mich sortiert.
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.
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.
Eigentlich musst du nur Folgendes ausführen:
Sudo chmod +x ./gradlew(your script)
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
Unter Red Hat Linux wurde dieses Problem durch Importieren der Zertifikate in /etc/pki/Java/cacerts behoben.
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
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)
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
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.
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