Keystore, Truststore, JKS, PKCS#12: die Begriffe
Java-Anwendungen wie Tomcat, Spring Boot, Jira, Keycloak oder Elasticsearch speichern Zertifikate nicht als lose Dateien, sondern in einem Keystore. Das ist eine kennwortgeschützte Datei mit benannten Einträgen (Aliassen).
- Keystore: enthält den eigenen privaten Schlüssel samt Zertifikat und Zwischenzertifikaten. Damit weist sich ein Server (oder ein Client bei mTLS) aus.
- Truststore: enthält nur Zertifikate von CAs, denen vertraut wird. Der Truststore von Java heißt
cacertsund liegt unter$JAVA_HOME/lib/security/. - JKS ist das alte, Java-eigene Format. Seit Java 9 ist PKCS#12 (.p12, .pfx) Standard. Das lesen auch OpenSSL, Windows, nginx-Werkzeuge und Browser.
- JCEKS ist eine JKS-Variante mit stärkerem Schlüsselschutz, die zusätzlich geheime Schlüssel (z. B. AES) speichern kann.
Typische Fehler und was sie bedeuten
- „Keystore was tampered with, or password was incorrect“: Das Kennwort ist falsch. Hier zeigt sich das als fehlgeschlagene Integritätsprüfung.
- „Cannot recover key“ / „Given final block not properly padded“: Bei JKS hat der Schlüssel ein anderes Kennwort als der Keystore. Das Werkzeug fragt dann nach dem Schlüsselkennwort.
- „PKIX path building failed“ beim Client: Im Keystore des Servers fehlen die Zwischenzertifikate oder im Truststore des Clients die Root-CA. Das Werkzeug zeigt beides.
- Truststore wird ignoriert, obwohl das Zertifikat drin ist: PKCS#12-Dateien, die mit OpenSSL erstellt wurden, haben kein Java-Vertrauensmerkmal. Java sieht die Zertifikate nicht als vertrauenswürdige Einträge. Hier erstellte Truststores haben das Merkmal.
- „Alias name does not identify a key entry“: Der Alias in der Konfiguration zeigt auf ein reines Zertifikat statt auf den Schlüssel.
JKS in PKCS#12 umwandeln
Datei öffnen, unten „PKCS#12“ wählen, Kennwort setzen und herunterladen. In der Konfiguration dann den Typ anpassen, z. B. certificateKeystoreType="PKCS12" in Tomcat oder server.ssl.key-store-type=PKCS12 in Spring Boot. „PKCS#12 kompatibel“ nimmt ältere Verfahren (3DES, SHA-1) für Windows Server 2016, ältere Java-8-Versionen und Appliances, die AES in PKCS#12 nicht lesen.
Fehlen Zwischenzertifikate, ergänzt sie der Zertifikat-Konverter. Was der Server danach wirklich ausliefert, zeigt der SSL-Check. Ob Schlüssel, Zertifikat und CSR zusammengehören, prüft auch der Key-Match.
FAQ
Wird mein Keystore irgendwohin hochgeladen?
Nein. Die Datei wird in deinem Browser gelesen und entschlüsselt, Kennwörter und Schlüssel verlassen dein Gerät nicht. Du kannst die Seite nach dem Laden auch offline benutzen.
Wie lautet das Kennwort von cacerts?
Standardmäßig changeit. Seit Java 9 kann keytool mit der Option -cacerts direkt darauf zugreifen, ohne den Pfad anzugeben.
Kann ich ein vergessenes Keystore-Kennwort herausfinden?
Nein. Bei JKS lassen sich ohne Kennwort zwar die Zertifikate anzeigen, die privaten Schlüssel aber nicht. Bleibt nur ein neuer Schlüssel und ein neues Zertifikat.
Warum hat PKCS#12 nur ein Kennwort?
Java benutzt für PKCS#12 dasselbe Kennwort für Datei und Schlüssel. Viele Programme, etwa Tomcat, setzen das sogar voraus. Getrennte Schlüsselkennwörter gibt es praktisch nur bei JKS.
Was passiert mit geheimen Schlüsseln aus JCEKS?
Sie werden angezeigt, aber nicht übernommen, weil ihr Inhalt als serialisiertes Java-Objekt gespeichert ist. Mit keytool -importkeystore lassen sie sich in PKCS#12 übertragen.