Fehler - Der Parameter trustAnchors darf nicht leer sein

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

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

Ich habe online eine gute Menge an Informationen über den Fehler gesehen, aber ich habe keine zum Arbeiten gebracht. Ich verwende Suns JDK unter Fedora Linux (nicht OpenJDK).

Hier sind einige Dinge, die ich versucht habe. Ich habe versucht, den Ratschlägen aus diesem Beitrag zu folgen, aber das Kopieren der Cacerts von Windows auf meine Fedora-Box mit Jenkins hat nicht funktioniert. Ich habe versucht, diesem Handbuch zu folgen , als ich versuchte, Google Mail als meinen SMTP-Server zu konfigurieren, aber es hat auch nicht funktioniert. Ich habe auch versucht, diese Cacert-Dateien manuell herunterzuladen, zu verschieben und mithilfe einer Variation der Befehle in diesem Handbuch in meinen Java-Ordner zu verschieben .

Ich bin offen für Vorschläge, da ich gerade nicht weiterkomme. 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 wie folgt lautete:

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

Siehe auch die Antwort von @ AdamPlumb unten .

Um dieses Problem zu debuggen (ich habe hier darüber geschrieben ) und zu verstehen, welcher Truststore verwendet wird, können Sie die Eigenschaft javax.net.debug = all hinzufügen und dann die Protokolle über den Truststore filtern. Sie können auch mit der Eigenschaft javax.net.ssl.trustStore spielen, um einen bestimmten Truststore anzugeben. Beispielsweise :

    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

In Ubuntu 18.04 hat dieser Fehler eine andere Ursache (JEP 229, Wechseln vom jksKeystore-Standardformat zum pkcs12Format und Generieren der Debian-Cacerts-Datei unter Verwendung der Standardeinstellung für neue Dateien) und Problemumgehung :

# 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

Status (2018-08-07) , 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 führen Sie ca-certificates-java 20180413 (main) von Debian unstable (main) zusammen.

🗹 Ubuntu 1739631: Bei einer Neuinstallation mit JDK 9 kann die generierte PKCS12-Cacerts-Keystore-Datei nicht verwendet werden

🗹 Docker-Bibliothek 145: 9-JDK-Image weist SSL-Probleme auf

🗹 Debian 894979: ca-certificates-java: funktioniert nicht mit OpenJDK 9, Anwendungen schlagen mit InvalidAlgorithmParameterException fehl: Der Parameter trustAnchors darf nicht leer sein

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

🖺 JEP 229: Standardmäßig PKCS12-Keystores erstellen

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

$ which java
/usr/bin/java

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

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

Sie können die von Ihnen ausgeführte Java-Version ü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 zukünftige Wartung erfordern, ohne dass sich dies auszahlt.

Die nächstbeste Problemumgehung besteht darin, die Zeile hinzuzufügen

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 drittniedrigste problematische 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

Entfernen Sie die cacertsDatei und generieren Sie sie auf die in der letzten Zeile des Workaround-Skripts oben im Beitrag beschriebene Weise neu.

Dies hat das Problem für mich unter Ubuntu behoben:

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

(hier zu finden: https://bugs.launchpad.net/ubuntu/+source/ca-certificates-java/+bug/1396760 )

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

Unter Ubuntu 18.04 ist die Hauptursache ein Konflikt zwischen openjdk-11-jdk (Standardeinstellung) und anderen davon abhängigen Paketen. Es wurde bereits in Debian behoben und wird in Kürze in Ubuntu enthalten sein. In der Zwischenzeit besteht die einfachste Problemumgehung darin, Java auf Version 8 herabzustufen. Andere Lösungen ca-certificates-javasind viel komplizierter.

Entfernen Sie zuerst widersprüchliche 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, kein Java für die Konfiguration verfügbar zu machen . Andernfalls schlägt diese Problemumgehung fehl .

Installieren Sie dann die erforderlichen Pakete neu:

sudo apt-get install openjdk-8-jdk

EJP hat die Frage im Grunde genommen beantwortet (und mir ist klar, dass dies eine akzeptierte Antwort ist), aber ich habe mich nur mit diesem Randfall befasst und wollte meine Lösung verewigen.

Ich hatte den InvalidAlgorithmParameterExceptionFehler auf einem gehosteten Jira- Server, den ich zuvor für den Nur-SSL-Zugriff 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.xmlDatei bearbeitet , um den KeystoreType für PKCS anzugeben, aber ich habe den TruststoreType nicht angegeben, sodass standardmäßig der KeystoreType verwendet wird. Wenn Sie den truststoreType explizit angeben, während JKS ihn für mich gelöst hat.

Ich bin auf diese Lösung aus dem Blogbeitrag gestoßen. Behebung des Vertrauensproblems beim Ausführen von OpenJDK 7 unter OS X :

Behebung 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. Verknüpfen Sie einfach dieselbe 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 OpenJDK-Version tun, die Sie installiert haben. Wechseln -v 1.7Sie einfach zu der Version, die Sie reparieren möchten. Führen Sie /usr/libexec/java_home -Vsehen , alle JREs und JDKs Sie installiert haben.

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

In Ubuntu 12.10 (Quantal Quetzal) oder höher werden die Zertifikate im Paket ca-certificates-java gespeichert. Mit -Djavax.net.ssl.trustStore=/etc/ssl/certs/java/cacertswird sie unabhängig vom verwendeten JDK abgerufen.

Nach dem Upgrade auf OS X 10.9 (Mavericks) bin ich unter OS X mit JDK 1.7 auf genau dieses Problem gestoßen . Die Lösung, die für mich funktioniert hat, bestand darin, einfach die Apple-Version von Java neu zu installieren, die unter http://support.apple.com/kb/DL1572 verfügbar ist .

ich rannte

sudo update-ca-certificates -f

um eine Zertifikatdatei zu erstellen, und dann:

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

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

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

Unter Windows habe ich die cacertsDatei aus jre/lib/securitydem Eclipse-Installationsverzeichnis (am selben Ort wie die eclipse.iniDatei) kopiert und die folgenden Einstellungen hinzugefügt eclipse.ini:

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

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

Die Idee ist, einen gültigen Pfad zur Truststore-Datei bereitzustellen - im Idealfall wird ein relativer Pfad verwendet. Sie können auch einen absoluten Pfad verwenden.

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

keytool -list -keystore cacerts

Keystore type: JKS
Keystore provider: SUN

Das Entfernen des ca-certificates-java-Pakets und das erneute Installieren funktionierten bei mir ( 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-certificates-java kann Java-Cacerts nicht auf Oneiric Ocelot installieren .

Nach dem Upgrade auf OS X 10.9 (Mavericks) gab es viele Sicherheitsprobleme :

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

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

Ich habe solche Dinge erwartet, da ich in meinem Talend Open Studio eine alternative JVM verwende (Unterstützung besteht derzeit nur bis JDK 1.7). Ich benutze 8 aus Sicherheitsgründen ... sowieso

• Aktualisieren Sie Ihren Zertifikatspeicher:

  sudo update-ca-certificates -f

dann

• Fügen Sie Ihren Initialisierungsparametern einen neuen Wert hinzu

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

Für mich war dies auf das Fehlen eines TrustedCertEntry im Truststore zurückzuführen.

Verwenden Sie zum Testen:

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 eine Zertifizierungsstelle enthält , musste er separat importiert werden :

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

Es importiert das Zertifikat und führt dann durch erneutes Ausführen keytool -list -keystore keystore.jksFolgendes aus:

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.

Einige OpenJDK-Anbieterversionen haben dies dadurch verursacht, dass eine leere cacertsDatei mit der Binärdatei verteilt wurde. Der Fehler wird hier erklärt: https://github.com/AdoptOpenJDK/openjdk-build/issues/555

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

Die Buggy-Version von AdoptOpenJDK lautet https://github.com/AdoptOpenJDK/openjdk8-releases/releases/download/jdk8u172-b11/OpenJDK8_x64_Win_jdk8u172-b11.zip

Wenn dies unter 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 fehlt, versuchen Sie, ca-certificates-java wie folgt zu installieren:

sudo apt install ca-certificates-java

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

Weitere Informationen finden Sie im Abschnitt "Bekannte Probleme" der JDK 9.0.1-Versionshinweise mit der Aufschrift "TLS funktioniert unter OpenJDK 9 standardmäßig nicht".

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

Ich hatte dieses Problem, als ich versuchte, Maven 3 zu verwenden, nachdem ich von Ubuntu 16.04 LTS (Xenial Xerus) auf Ubuntu 18.04 LTS (Bionic Beaver) aktualisiert hatte .

Das Überprüfen von / usr / lib / jvm / java-8-oracle / jre / lib / security ergab, dass meine cacerts-Datei ein symbolischer Link war, auf den verwiesen wurde /etc/ssl/certs/java/cacerts.

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

Ich umbenannt cacerts.originalzu cacerts, und dass das Problem behoben.

Ich habe dies auch unter OS X festgestellt, nachdem ich OS X 10.9 (Mavericks) aktualisiert hatte, als das alte Java 6 verwendet wurde und versucht wurde, auf eine HTTPS-URL zuzugreifen. Die Lösung war die Umkehrung von Peter Kriens; Ich musste das cacertsaus dem 1.7-Bereich an den durch die 1.6-Version verknüpften Speicherort 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 Client-Anwendung als Trust Store verwendet, wie zum Beispiel:

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

Quelle: Java SSL und Zertifikat-Keystore

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

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

Das Problem ist auf die Art und Weise zurückzuführen, wie Tomcat mit dem Trust Store umgeht. Wenn Sie Ihren Trust Store-Speicherort in der Spring Boot-Konfiguration mit Ihrem Keystore identisch angegeben haben, wird die trustAnchors parameter must be non-emptyMeldung wahrscheinlich beim Starten der Anwendung angezeigt.

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

Entfernen server.ssl.trust-storeSie einfach die Konfiguration, es sei denn, Sie wissen, dass Sie sie benötigen. In diesem Fall konsultieren Sie die folgenden Links.

Die folgenden Probleme enthalten weitere Details zum Problem:

• Der HTTPS Tomcat-Connector startet nicht mit 1.4.1 # 7069
• SSL-Client-Authentifizierung mit selbstsigniertem Zertifikat funktioniert nicht mehr # 7406
• Upgrade auf Tomcat 8.5.5 # 6703

Ich habe dieses Problem mit dem Android SDK sdkmanager festgestellt. Für mich hat diese Lösung funktioniert:

1. Gehe zu /usr/lib/jvm/java-8-oracle/jre/lib/security/
2. Ersetzen cacertdurchcacert.original

Die cacertDatei war winzig (22B). Ich habe installiert oracle-java8-installervon ppa:webupd8team/java(nach dieser Anleitung: https://docs.nativescript.org/start/ns-setup-linux ).

Für die Aufzeichnung hat keine der Antworten hier für mich funktioniert. Mein Gradle-Build schlug auf mysteriöse Weise mit diesem Fehler fehl und konnte HEAD für eine bestimmte POM- Datei nicht aus Maven Central abrufen .

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

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

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

Sie müssen die obigen zwei Zeilen zu Ihrem Code hinzufügen. Der Truststore kann nicht gefunden werden.

Ich hatte dieses Problem, als ich eine bestimmte Android-Suite zum Testen unter Ubuntu 14.04 (Trusty Tahr) ausführte. Zwei Dinge haben bei mir funktioniert, wie von Shaheen vorgeschlagen:

sudo update-ca-certificates -f

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

Keine der Lösungen, die ich im Internet gefunden habe, hat funktioniert, aber eine modifizierte Version von Peter Kriens 'Antwort scheint den Job zu erledigen.

Suchen Sie zuerst Ihren Java-Ordner, indem Sie ausführen /usr/libexec/java_home. Für mich war es die 1.6.0.jdkVersion. Dann gehen Sie zu seinem lib/securityUnterordner (für mich/Library/Java/JavaVirtualMachines/1.6.0.jdk/Contents/Home/lib/security ).

Löschen Sie dann die cacertsDatei, falls bereits eine vorhanden ist, und suchen Sie mit auf dem System nach einer sudo find / -name "cacerts". Es wurden mehrere Elemente für mich gefunden, in Versionen von Xcode oder anderen Anwendungen, die ich installiert hatte, aber auch bei/Library/Internet Plug-Ins/JavaAppletPlugin.plugin/Contents/Home/lib/security/cacerts denen ich mich entschieden habe.

Verwenden Sie diese Datei und stellen Sie einen symbolischen Link zu ihr her (während Sie sich zuvor im Java-Ordner befinden). sudo ln -fsh "/Library/Internet Plug-Ins/JavaAppletPlugin.plugin/Contents/Home/lib/security/cacerts" Es sollte funktionieren.

Ich habe sowohl Java von Apples Download 2017-001 ( https://support.apple.com/kb/dl1572 - ich nehme an, dass dort die richtigen Zertifikate stammen) als auch das von Oracle unter Mac OS X 10.12 (Sierra) installierte. .

am ubuntu 14.04 mit openjdk 11 von ppa: openjdk-r / ppa das hat bei mir 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 überprüfen, ob es funktioniert hat, stellen Sie sicher, dass Sie keinen Daemon verwenden, auf dem noch altes Java ausgeführt wird (z. --no-daemon Option für Gradle).

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

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 cacertsDatei des heruntergeladenen JDK aus dem jre/lib/securityOrdner zu entfernen und sie dann als Symlink zur Systemdatei zu cacertserstellen in /etc/ssl/certs/java/:

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

Geringe Chance, dass dies jedem hilft, aber ... für jeden, der Java 8 von einem Docker-Image auf einem Raspberry Pi (mit AMD-CPU) ausführt, habe ich die folgende Docker-Datei, die ich erfolgreich erstellen und ausführen kann

FROM hypriot/rpi-java
USER root

WORKDIR /usr/build/

RUN /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
RUN update-ca-certificates -f
RUN /var/lib/dpkg/info/ca-certificates-java.postinst configure

EXPOSE 8080

ARG JAR_FILE=target/app-0.0.1-SNAPSHOT.jar

ADD ${JAR_FILE} app.jar

ENTRYPOINT ["java", "-Djavax.net.ssl.trustStorePassword=changeit", "-Djavax.net.ssl.trustStore=/etc/ssl/certs/java/cacerts", "-jar", "app.jar"]