HTTP Let's Encrypt und Java Trust-Store

Maliko

Bekanntes Mitglied
Moin,

ich hab da momentan mal ein etwas nerviges Problem. Und zwar haben wir ein kleines Programm welches regelmäßig eine REST-Schnittstelle über https antriggert. Dazu musste ich das SSL-Zertifikat im Truststore hinterlegen. Das Problem daran ist aber dass das SSL-Certifikat ein Let's Encrypt-Zertifikat ist und alle 3 Monate erneuert wird. Für mich bedeutet das momentan dass ich alle 3 Monate das SSL-Zertifikat neu herunterladen muss und per Hand in den Trust-Store einfügen muss.

Daher meine Frage. Gibt es irgendeine Möglichkeit das irgendwie so zu konfigurieren dass Java sich automatisch alle 3 Monate das aktuelle Zertifikat zieht und in seinen Truststore schmeißt wenn er sieht dass das alte abgelaufen ist?

Vielen Dank schon mal im Voraus.

Viele Grüße
Maliko
 
Wie genau machst Du das denn mit der Zertifikats-Erneuerung? Wenn das bei Dir durch automatische Scripts geht / Cron aufrufe, dann kannst du da alles weiteren Schritte natürlich auch automatisieren:

So startet certbot bei mir regelmäig in einem Script. Nachdem certbot fertig ist, habe ich (für die einzelnen Zertifikate) eine Prüfung, ob das Zertifikat erneuert wurde:
/etc/letsencrypt/scripts/server.kneitzel.de.sh

Bash:
[ /etc/letsencrypt/live/server.kneitzel.de/cert.pem -nt /etc/letsencrypt/live/server.kneitzel.de/keystore.jks ] && /etc/letsencrypt/scripts/server.kneitzel.de.sh

Da kannst Du erkennen: Es liegt zusätzlich ein jks File bei den certbot Dateien des Zertifikats. Die Verarbeitung macht dann ein eigenes Shellscript:
Bash:
#!/bin/bash
# Create new jks file

cd /etc/letsencrypt/live/server.kneitzel.de
rm fullcert.pem
rm fullchain.pkcs12
rm keystore.jks

cat cert.pem chain.pem fullchain.pem privkey.pem > fullcert.pem

openssl pkcs12 -export -out fullchain.pkcs12 -in fullcert.pem -passout pass:mySecret
keytool -importkeystore -srckeystore fullchain.pkcs12 -srcstorepass mySecret -destkeystore keystore.jks -deststoretype JKS -deststorepass mySecret

openssl pkcs12 -export -out fullchain.pkcs12 -in fullcert.pem -passout pass:mySecret -name myAlias
keytool -importkeystore -srckeystore fullchain.pkcs12 -srcstorepass mySecret -destkeystore cert.jks -deststoretype JKS -deststorepass mySecret

cp keystore.jks /opt/tomcat/.../keystore.jks

Also man erkennt glaube ich die ganzen Blöcke:
- löschen alter generierter Dateien (rm Zeilen)
- Erzeugen einer pem, die alles enthält (cat)
Dann zwei Mal:
- Erzeugen pkcs12 Store (openssl) - evtl. reicht das schon so aus für Dich, falls Du nur ein pkcs12 File brauchst
- keytool um ein jks File zu bekommen.

- Am Ende dann dahin kopieren, wo diese hin gehören.

Ich habe da zwei keystore Files erzeugt, da ich das Zertifikat an mehreren Stellen brauche mit unterschiedlichen Passwörtern und einmal mit speziellem Alias ... Passwörter habe ich hoffentlich alle geändert (mySecret). Das kannst Du dann so anpassen, wie Du es brauchst / möchtest.

Also einfaches Scripting - funktioniert auch sehr gut unter Windows mit WSL 🙂
 
An sowas in der Art habe ich bereits gedacht. Das Problem ist nur dass es nicht unser Zertifikat ist. Die REST-Schnittstelle gehört einem externen Partner. Dementsprechend habe ich auch keinen Zugriff auf den Certbot. Wir bekommen bisher überhaupt nur mit, dass das Zertifikat abgelaufen ist weil der Client plötzlich nicht merh funktioniert.
 
Das Problem ist nur dass es nicht unser Zertifikat ist. Die REST-Schnittstelle gehört einem externen Partner. Dementsprechend habe ich auch keinen Zugriff auf den Certbot.
Auf dem Client musst Du normalerweise kein Zertifikat installieren. Entweder habt Ihr eine Uralt-Java-Version (vor 7u111/8u101) oder Ihr solltet mal prüfen, ob Euer Partner das Zertifikat korrekt eingebunden hat.

Wenn Du openssl laufen hast, probier mal openssl s_client -connect <server>:<port> aufrufen, wobei <server> und <port> natürlich entsprechend zu setzen sind. Ansonsten kannst Du auch mal einfach probieren, den REST-Server per Browser anzusteuern. Das sollte ohne irgendwelche Zertifikats-Warnungen funktionieren und Du kannst Dir auch mal das Zertifikat/Zertifikatskette anzeigen lassen.
 
Wenn es um den Client geht (Und nicht um den Server-Part), dann dürfte es ausreichen, wenn man sicher stellt, dass das Root Zertifikat entsprechend vorhanden ist. Bei alten Java Versionen (Java 8) habe ich gesehen, dass da die Zertifikate nicht vorhanden sind.

Das File mit den Zertifikaten der Java Installation findet sich in der Datei cacerts ($JAVA_HOME/jre/lib/security/cacerts - jre als Unterverzeichnis mag es - je nach Installationsquelle - nicht geben)

Passwort des stores ist in der Regel "changeit".

Mittels keytool lässt sich das auslesen und das root Zertifikat bei Bedarf hinzufügen.

Die Übersicht der Zertifikate findet sich unter https://letsencrypt.org/de/certificates/ (incl. Möglichkeit, die Zertifikate herunter zu laden).

Wichtig wären also das ISRG Root X1 Zertifikat. (Wenn Du da schon aktiv bist, auch gleich das ISRG Root X2 Zertifikat prüfen / hinzufügen!)
 
Hat das einen bestimmten Grund, dass Ihr eine Asbach-Version verwendet? Ansonsten würde ich Euch mal ein Update empfehlen, natürlich könnt Ihr Euch auch das Root-Zertifikat installieren, wie @kneitzel es beschrieben hat.
 

Zurück
Oben