keytool meldet Erfolg, Java vertraut dem Zertifikat nicht
Certificate was added to keystore – und die Verbindung scheitert weiter. Ohne -cacerts legt keytool das Zertifikat in .keystore im Heimverzeichnis ab.
Aufwand:
ca. 20 Min.
Gilt für:
JDK 9 und neuer, JDK 21, JDK 25
Das Symptom
Eine Java-Anwendung erreicht einen internen Server nicht, weil dessen Zertifikat von
einer firmeneigenen Zertifizierungsstelle stammt. Man besorgt sich das
CA-Zertifikat, ruft keytool -importcert auf, bestätigt die Rückfrage mit yes und
bekommt die Bestätigung Certificate was added to keystore.
Dann startet man die Anwendung neu – und sie scheitert an genau derselben Stelle wie
vorher. Kein Unterschied, keine neue Meldung.
Die „Layer 8“-Wahrheit
Der Import war erfolgreich. Nur eben nicht dort, wo jemand nachsieht. keytool
kennt zwei völlig verschiedene Dateien, und wer keine Zieloption angibt, bekommt
automatisch die falsche. Ohne -keystore oder -cacerts arbeitet das Werkzeug auf
der Standarddatei .keystore im Heimverzeichnis des aufrufenden Benutzers – und
legt sie laut Dokumentation sogar an, falls sie noch nicht existiert. Das ist der
gemeine Teil: Es gibt keinen Fehler, keine Warnung, nicht einmal ein „diese Datei
kannte ich noch nicht“. Nur eine frisch erzeugte Datei, die niemand liest, mit einem
sauber importierten Zertifikat darin.
Die Vertrauensanker der Laufzeitumgebung stehen dagegen in cacerts im
Sicherheitsverzeichnis der Installation, unter Linux und macOS in
JAVA_HOME/lib/security. Genau diese Datei adressiert die Option -cacerts, und
ihr Anfangspasswort lautet changeit – ein Detail, das Oracle so dokumentiert und
das seit Jahrzehnten unverändert die Runde macht, weil es praktisch nie geändert
wird.
Der eigentliche Konstruktionsfehler sitzt aber eine Ebene höher, nämlich bei
JAVA_HOME. Auf einer Maschine mit drei installierten JDKs gibt es drei cacerts,
und die Anwendung benutzt keineswegs zwingend dasselbe wie das keytool, das gerade
im Pfad liegt. Wer statt -cacerts einen ausgeschriebenen Pfad verwendet, sollte
ihn deshalb aus der JVM ableiten, die die Anwendung wirklich startet – und nicht aus
der, die der eigene Shell-Prompt zufällig kennt.
Die echte, verifizierte Lösung
1000 % faktenbasiert. Jeder Befehl ist real, jeder Pfad existiert. Schritt für Schritt:
1.
Herausfinden, wohin der Import wirklich ging
Zuerst die Standarddatei ansehen, die keytool ohne Zieloption benutzt: .keystore im Heimverzeichnis. Taucht der eigene Alias dort auf, ist die Diagnose fertig – das Zertifikat liegt in einem Keystore, den die JVM beim Verbindungsaufbau nie befragt.
keytool -list -v -keystore ~/.keystore
2.
Den echten Truststore der JVM auflisten
Der Truststore der Installation heißt cacerts und liegt unter JAVA_HOME/lib/security. Statt den Pfad von Hand zu tippen und dabei die falsche von drei installierten JVMs zu erwischen, adressiert die Option -cacerts genau diese Datei. Das Anfangspasswort ist changeit.
keytool -list -cacerts -alias meine-firmen-ca
3.
Das Zertifikat an die richtige Stelle importieren
Erst jetzt der eigentliche Import, mit -cacerts als Ziel und -trustcacerts, damit das Zertifikat als Vertrauensanker eingetragen wird. Der Alias sollte sprechend sein: In cacerts stehen hunderte Einträge, und ein Alias namens mycert findet in zwei Jahren niemand wieder.
Den Erfolg nachprüfen, statt der Meldung zu glauben
Genau die Auflistung wiederholen, die vorher leer war. Kommt der Alias jetzt zurück, ist der Vertrauensanker gesetzt. Diese Gegenprobe ist der ganze Punkt der Übung – der erste Anlauf ist ja auch mit einer Erfolgsmeldung gescheitert.
keytool -list -cacerts -alias meine-firmen-ca
5.
Bei alten Anleitungen auf den Keystore-Typ achten
Seit JDK 9 ist PKCS12 die Standard-Implementierung für Keystores, vorher war es das JDK-eigene jks. Ältere Anleitungen setzen deshalb -storetype jks oder erzeugen JKS-Dateien. Das funktioniert weiter, ist aber nicht mehr das, was die Voreinstellung liefert – und erklärt manche Warnung beim Öffnen alter Dateien.
Häufige Fragen (FAQ)
?keytool sagt „Certificate was added to keystore“. Wieso ändert sich nichts?
Weil die Meldung nur bestätigt, dass irgendein Keystore geschrieben wurde – nicht welcher. Ohne -keystore oder -cacerts nimmt keytool die Standarddatei .keystore im Heimverzeichnis und legt sie sogar an, falls sie fehlt. Die JVM prüft ihre Vertrauensanker aber gegen cacerts im Sicherheitsverzeichnis der Installation. Der Import war erfolgreich, nur eben am Zielort vorbei.
?Nach welchem Passwort fragt keytool bei cacerts?
Nach dem Keystore-Passwort. Für cacerts lautet das Anfangspasswort laut Oracle changeit. Wer es nie geändert hat – also fast jeder – kommt damit durch. Bei einem selbst angelegten Keystore gilt das eigene Passwort, und das muss mindestens sechs Zeichen haben.
Belege
Diese Seite ist gegen die folgenden Primärquellen geprüft – Hersteller, Standard oder Gesetzestext. Wer es nicht glaubt, muss es nicht: Da steht, wo es nachzulesen ist.
Liegen mehrere HTTPS-Namen auf einer IP, entscheidet die SNI-Erweiterung, welches Zertifikat kommt. Fehlt sie, liefert der Server das Standardzertifikat.