
Ich habe ein Schlüsselpaar mit dem folgenden Befehl erstellt:
"%JAVA_HOME%\bin\keytool" -genkeypair -keysize 2048 -alias tomcat -keyalg RSA -sigalg SHA256withRSA
Mir ist aufgefallen, dass es einen Schlüsselspeicher im Ordner jdk/lib/security und einen weiteren Schlüsselspeicher im Ordner jre/lib/security gibt. Ich nahm an, dass einer dieser Speicher das Schlüsselpaar enthalten würde, das ich gerade erstellt habe. Das Schlüsselpaar wurde im Standardschlüsselspeicher erstellt, der im Verzeichnis des angemeldeten Benutzers erstellt wurde.
Meine erste Frage ist, warum sich der Standardschlüsselspeicher im Benutzerverzeichnis befindet. Das erscheint merkwürdig. Kann ich diesen Schlüsselspeicher verschieben?
Meine zweite Frage ist, warum so viele Keystores?
Meine letzte Frage ist, ob ich mein Schlüsselpaar, da es der einzige Schlüssel im Standardspeicher ist, woanders hin verschieben/kopieren soll. Ich muss es von einem ICA signieren lassen, daher erscheint es nicht richtig, es allein zu haben.
Antwort1
Java überschreibt die Standardschlüsselspeicher bei jedem Update (also meistens wird es an einem neuen Ort installiert und löscht den vorherigen). Daher würde es bei jedem Update Ihrer Pakete alle privaten Schlüssel löschen, die ein Benutzer erstellt hat (da das Update auch Änderungen an den Standard-Truststores enthalten könnte, um nicht vertrauenswürdige CAs zu löschen usw.). Daher besteht die Standardmethode (und vernünftigste Methode) darin, Dinge im Ordner des Benutzers zu speichern. Auf diese Weise wird es von den Updates isoliert. Außerdem wäre es ein Sicherheitsproblem, wenn jeder Benutzer auf derselben Maschine auf die privaten Schlüssel anderer Benutzer zugreifen oder den Standard-Truststore manipulieren könnte, um benutzerdefinierte CAs zuzulassen.
Windows-Zertifikate verhalten sich ähnlich: Standardmäßig wird der persönliche Speicher des aktuellen Benutzers angezeigt. Neue private Schlüssel oder vertrauenswürdige Zertifikate wirken sich nur auf den aktuellen Benutzer aus, aber der Computer verfügt weiterhin über die Standardeinstellungen, mit denen Windows ausgeliefert wurde (und jedes Update ändert diese Standardeinstellungen, z. B. neue oder nicht vertrauenswürdige Zertifizierungsstellen).
Die Aktionen eines Benutzers dürfen keine Auswirkungen auf andere Benutzer auf demselben Computer haben.
Was JRE und JDK betrifft, ist das erste für die running
Umgebung (d. h. für die Standardverwendung von Anwendungen) gedacht, während das letztere für development
andere Anforderungen gedacht ist und diese erfüllt. Ein Anwendungsserver benötigt das JDK, da er Seiten wie *.jsp
diese im laufenden Betrieb „kompilieren“ muss. Das JDK enthält sein eigenes JRE, sodass es eine eigene Kopie von allem hat, was das JRE zum Funktionieren benötigt. Da Sie möglicherweise für Clients (Benutzer) eine andere Unterstützung bereitstellen müssen als für den Server (d. h. JRE und JDK könnten unterschiedliche Versionen verwenden), könnte die gemeinsame Nutzung gemeinsamer Teile zu Problemen führen.
Sie können den Schlüsselspeicher (Name und Speicherort) mit -keystore file.jks
demselben Befehl ändern, den Sie eingegeben haben, aber Sie müssen in jedem anderen Befehl oder jeder anderen Konfiguration auf dieselbe Datei verweisen, damit Java denselben Schlüsselspeicher verwenden kann. Da Sie den Alias benannt haben tomcat
, gehe ich davon aus, dass Sie ihn als Schlüsselspeicher für einen Anwendungsserver verwenden werden. Daher müssen Sie in der Datei server.xml (oder catalina.xml) den Speicherort des Schlüsselspeichers konfigurieren.
Schlüsselspeicher für einen Server sollten sich in einem Verzeichnis mit eingeschränktem Zugriff (nur lesbar für den Benutzer, mit dem der Server ausgeführt wird) befinden, wie beispielsweise /etc/ssl/
und dergleichen.
Was den Inhalt der Datei selbst betrifft, da Sie sie signiert benötigen, müssen Sie zunächst ein selbstsigniertes Schlüsselpaar erstellen (wie Sie es getan haben) und dann eine CSR (Certificate Signing Request) erstellen, die an die Zertifizierungsstelle gesendet wird. Danach sollten Sie die gesamte Kette (das neu signierte Zertifikat und die Zertifikatskette Ihrer Zertifizierungsstelle) in denselben Alias im selben Schlüsselspeicher importieren. Dies wäre immer noch ein einzelner Eintrag im Schlüsselspeicher, aber er würde mehrere Zertifikate (und einen privaten Schlüssel) unter diesem Alias enthalten.
Wenn Ihr Server keine Verbindung zu einem anderen Server herstellen muss, sollte dieser Keystore kein anderes Zertifikat enthalten. Und selbst wenn dies erforderlich ist, sollten Sie stattdessen einen separaten Truststore haben (einen zweiten Keystore, aber nur mit CAs darin, genau wie die Datei cacerts) (oder sich auf den Standard-Truststore der JRE verlassen oder sogar die CA in denselben Keystore aufnehmen).