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

Diese bizarre Nachricht bedeutet, dass die trustStore die Sie angegeben haben, war:

• leer,
• nicht gefunden, oder
• konnte nicht geöffnet werden
  • (wegen falscher/fehlender trustStorePassword , oder
  • Dateizugriffsberechtigungen, zum Beispiel).

Siehe auch @AdamPlumb's Antwort unten .

Answer 2

Unter Ubuntu 18.04 hat dieser Fehler eine andere Ursache (JEP 229, Wechsel vom jks Keystore-Standardformat auf das pkcs12 Format und die Debian cacerts-Dateierzeugung unter Verwendung des Standards für neue Dateien) und Abhilfe :

# 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

---

Stand (07.08.2018) 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 ca-certificates-java 20180413 (main) von Debian unstable zusammenführen (main)

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-certificates-java: funktioniert nicht mit OpenJDK 9, Anwendungen scheitern mit InvalidAlgorithmParameterException: der trustAnchors-Parameter muss nicht-leer sein

JDK-8044445 : JEP 229: PKCS12-Schlüsselspeicher standardmäßig erstellen

JEP 229: PKCS12-Schlüsselspeicher standardmäßig erstellen

---

Wenn das Problem nach dieser Abhilfe weiterhin besteht, sollten Sie sicherstellen, dass Sie tatsächlich die Java-Distribution ausführen, die Sie gerade repariert haben.

$ which java
/usr/bin/java

Mit können Sie die Java-Alternativen auf 'auto' setzen:

$ sudo update-java-alternatives -a
update-alternatives: error: no alternatives for mozilla-javaplugin.so

Sie können die Java-Version, die Sie ausführen, ü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 Umgehungsmöglichkeiten, aber diese haben ihre eigenen Nebenwirkungen, die zusätzliche künftige Wartung erfordern, ohne dass sich dies in irgendeiner Weise auszahlt.

Die nächstbeste Abhilfe 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, am wenigsten problematische Abhilfemaßnahme ist die Änderung des Wertes von

keystore.type=pkcs12

zu

keystore.type=jks

in den Dateien

/etc/java-9-openjdk/security/java.security
/etc/java-11-openjdk/security/java.security

was auch immer vorhanden ist, und entfernen Sie dann die cacerts Datei und generieren Sie sie neu, wie in der letzten Zeile des Skripts zur Umgehung des Problems oben im Beitrag beschrieben.

Answer 3

Damit ist das Problem bei mir unter Ubuntu behoben:

sudo /var/lib/dpkg/info/ca-certificates-java.postinst configure

(gefunden hier: https://bugs.launchpad.net/ubuntu/+Quelle/ca-zertifikate-java/+bug/1396760 )

ca-certificates-java ist keine Abhängigkeit im Oracle JDK/JRE, so dass es explizit installiert werden muss.

Answer 4

Unter Ubuntu 18.04 ist die Ursache ein Konflikt zwischen openjdk-11-jdk (das standardmäßig installiert ist) und anderen Paketen, die davon abhängig sind. Er wurde bereits in Debian behoben und wird in Kürze auch in Ubuntu enthalten sein. In der Zwischenzeit ist die einfachste Lösung, Ihr Java auf Version 8 zu degradieren. Andere Lösungen unter Verwendung von ca-certificates-java 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 wird Sie auffordern es ist kein Java zur Konfiguration verfügbar , ansonsten diese Abhilfe scheitert .

Installieren Sie dann die erforderlichen Pakete neu:

sudo apt-get install openjdk-8-jdk

Answer 5

EJP hat die Frage im Grunde beantwortet (und mir ist klar, dass es eine akzeptierte Antwort darauf gibt), aber ich habe mich gerade mit diesem Grenzfall beschäftigt und wollte meine Lösung verewigen.

Ich hatte die InvalidAlgorithmParameterException Fehler bei einem gehosteten Jira Server, den ich zuvor für den reinen SSL-Zugang eingerichtet hatte. Das Problem bestand darin, dass ich meinen Keystore im PKCS#12-Format eingerichtet hatte, mein Truststore aber im JKS-Format.

In meinem Fall hatte ich meine server.xml Datei, um den KeystoreType auf PKCS festzulegen, aber ich habe den TruststoreType nicht angegeben, so dass er standardmäßig den KeystoreType verwendet. Die explizite Angabe des TruststoreTyps als JKS löste das Problem für mich.