Standardkonfiguration mit verkettetem Zertifikat in SSL
Wenn ein Prozess von WebSphere Application Server zum ersten Mal gestartet wird, intialisiert die SSL-Laufzeitumgebung (Secure Sockets Layer) die Standardkeystores und -truststores, die in der SSL-Konfiguration angegeben sind.
Die während der Profilerstellung erstellten verketteten Zertifikate haben standardmäßig eine Lebensdauer von 1 Jahr. Das Standardstammzertifikat, das zum Unterzeichnen des verketteten Standardzertifikats verwendet wird, hat eine Lebensdauer von 15 Jahren. Die Lebensdauer der Standard- und Stammzertifikate kann während der Profilerstellung angepasst werden. Der Vorteil dieses Typs eines verketteten Zertifikats besteht darin, dass nur der Unterzeichner aus dem Stammzertifikat benötigt wird, damit die Vertrauenswürdigkeit gesichert ist. Wenn das verkettete Zertifikat mit demselben Stammzertifikat erneut generiert wird, werden die Clients, die das betreffende Stammunterzeichnerzertifikat verwenden, die Vertrauenswürdigkeit nicht verlieren.
- Eigenschaften des Standard-Keystores und des Standard-Truststores
- WebSphere Application Server erstellt während der Profilerstellung die Standard-Keystore-Datei key.p12
und die Standard-Truststore-Datei trust.p12.
Außerdem wird in der Datei
key.p12 ein verkettetes Zertifikat Standardzertifikat erstellt. Der Stammunterzeichner oder
der öffentliche Schlüssel wird aus der Datei
key.p12 extrahiert und zur Datei trust.p12 hinzugefügt. Falls die Dateien beim Start des Prozesses nicht vorhanden sind, werden sie während des Starts
erstellt.
Den Standard-Keystore und den Standard-Truststore können Sie an den Suffixen DefaultKeyStore und DefaultTrustStore erkennen. In der SSL-Konfiguration müssen Sie außerdem das Attribut fileBased auf true setzen, damit die Laufzeitumgebung nur die Standard-Keystores und Standard-Truststores verwendet.
Auf einem Basisanwendungsserver werden der Standard-Keystore und der Standard-Truststore in dem Knoten Verzeichnis des Konfigurationsrepositorys gespeichert. Die Standardspeicher key.p12 und trust.p12 werden beispielsweise mit demstandardmäßig verwendeten Profilnamen
AppSrv01, dem Namen "myhostNode01Cell" und dem Knotennamen "myhostNode01" erstellt. Der Keystore und der Truststore befinden sich in folgenden Verzeichnissen:
C:\WebSphere\AppServer\profiles\AppSrv01\config\cells\myhostNode01Cell \nodes\myhostNode01\key.p12
C:\WebSphere\AppServer\profiles\AppSrv01\config\cells\myhostNode01Cell \nodes\myhostNode01\trust.p12
${WAS_INSTALL_ROOT}/profile/default/config/cells/myhostNode01Cell/nodes/myhostNode01/key.p12
${WAS_INSTALL_ROOT}/profile/default/config/cells/myhostNode01Cell/nodes/myhostNode01/trust.p12
Das Standardkennwort für alle von WebSphere Application Server generierten Standard-Keystores ist WebAS. Ändern Sie das Standardkennwort nach der Erstkonfiguration, um den Schutz Ihrer Umgebung zu verbessern.
- Verkettetes Standardzertifikat
- Das verkettete Standardzertifikat des Servers wird zusammen mit einem selbst signierten Stammzertifikat, das zum Unterzeichnen des verketteten
Stammzertifikats dient, während der Profilerstellung erstellt.
Stammzertifikateigenschaften:
Information Wert Typ self-signed (selbst signiert) Größe 2048 Signaturalgorithmus SHA256withRSA Registrierter Name des Zertifikatsinhabers cn=${Hostname},ou=Stammzertifikat, ou=<Knotenname>, ou= <Zellenname>,o=IBM,c=US Lebensdauer 15 Jahre Standardzertifikateigenschaften:Information Wert Typ chained (verkettet, vom Stammzertifikat signiert) Größe 2048 Signaturalgorithmus SHA256withRSA Registrierter Name des Zertifikatsinhabers cn=${Hostname},ou=<Knotenname>,ou=<Zellenname>,o=IBM,c=US Lebensdauer 1 Jahr Sie können die Zertifikate mit anderen Informationen neu erstellen. Löschen Sie dazu einfach die Dateien *.p12 in den Verzeichnissen /config und /etc. Ändern Sie die vier Eigenschaften im nächsten Codebeispiel in die Werte, die das Zertifikat enthalten soll, und starten Sie den Prozess erneut. Das Serverzertifikat in /config unterscheidet sich jetzt vom Clientzertifikat in /etc.
Die Zertifikatseigenschaften im nächsten Codebeispiel sind in der Datei ssl.client.props, aber nicht in der Serverkonfiguration enthalten. Sie können diese Werte jedoch in der Serverkonfiguration verwenden. Fügen Sie in der Administrationskonsole als angepasste Sicherheitseigenschaften hinzu. Klicken Sie auf Sicherheit > Globale Sicherheit > Angepasste Eigenschaften, um die folgenden Eigenschaften zu ändern:com.ibm.ssl.defaultCertReqAlias=default_alias com.ibm.ssl.defaultCertReqSubjectDN=cn=${hostname},ou=myhostNode01,ou=myhostNode01Cell,o=IBM,c=US com.ibm.ssl.defaultCertReqDays=365 com.ibm.ssl.defaultCertReqKeySize=1024 com.ibm.ssl.rootCertSubjectDN=cn=${hostname},ou=Root Certificate, ou=myhostNode01,ou=myhostNode01Cell,o=IBM,c=US com.ibm.ssl.rootCertValidDays=7300 com.ibm.ssl.rootCertAlias=root com.ibm.ssl.rootCertKeySize=1024
Führen Sie nach dem Ändern der Eigenschaften die folgenden Aktionen aus:- Löschen Sie die Standarddateien "key.p12" (Keystore) und "trust.p12" (Truststore) für den Deployment Manager, die die verketteten Standardzertifikate enthalten. Falls die Keystore- und Truststore-Dateien nicht vorhanden sind, generiert WebSphere Application Server sie automatisch und erstellt neue Standardzertifikate unter Verwendung der zuvor aufgelisteten Eigenschaftswerte.
- Löschen Sie den Stamm-Keystore, die Datei "root-key.p12", um das Stammzertifikat mit den zuvor aufgelisteten Eigenschaften neu zu generieren.
- Starten Sie den Deployment Manager, seinen Knoten und alle Server erneut.
- Signieren Sie jeden Knoten mit dem Stammzertifikat.
- Wenn die Knoten nicht eingebunden sind, binden Sie jeden einzelnen Knoten mit dem Befehl "addNode" in den Deployment Manager ein. Das Standardzertifikat für den Knoten wird mit dem Stammzertifikat für die Zelle neu generiert.
- Wenn die Knoten eingebunden sind, erneuern Sie das Zertifikat für jeden Knoten mit dem Stammzertifikat für die Zelle. Sie können das Zertifikat über die Administrationskonsole oder mit dem Befehl "renewCertificate" erneuern. Weitere Informationen finden Sie in der Dokumentation zum Erneuern eines Zertifikats und zum Befehl "renewCertificate".
Wenn bereits ein Wert für default_alias existiert, hängt die Laufzeit _# an. Das Nummernzeichen (#) steht hier für eine Nummer, die jeweils um eins erhöht wird, bis der Wert im Keystore eindeutig ist. ${hostname} ist eine Variable, die in den Namen des Hosts aufgelöst wird, auf dem sie ursprünglich erstellt wurde. Die Standardverfallszeit für verkettete Zertifikate liegt bei einem Jahr ab Erstellungsdatum.
Die Laufzeit überwacht das Verfallsdatum verketteter Zertifikate mit dem Verfallsmonitor für Zertifikate. Diese verketteten Zertifikate werden automatisch zusammen mit den Unterzeichnerzertifikaten ersetzt, wenn sie den Schwellenwert für das Verfallsdatum überschritten haben, der in der Regel 30 Tage vor dem eigentlichen Verfallsdatum liegt. Die Standardschlüsselgröße von 1024 Bits können Sie nur weiter erhöhen, wenn die Richtliniendateien der Java™-Laufzeitumgebung uneingeschränkt (nicht exportiert) sind. Weitere Informationen hierzu finden Sie im Artikel Überwachung des Zertifikatsablaufs in SSL.
- Standard-Keystore- und Standard-Truststore-Konfigurationen für neue Base Application Server-Prozesse
- Der folgende Beispielcode zeigt die Standard-SSL-Konfiguration
für einen Base Application Server.
Die Referenzen auf Standard-Keystore- und -Truststore-Dateien sind hervorgehoben.
<repertoire xmi:id="SSLConfig_1" alias="NodeDefaultSSLSettings" managementScope="ManagementScope_1"> <setting xmi:id="SecureSocketLayer_1" clientAuthentication="false" securityLevel="HIGH" enabledCiphers="" jsseProvider="IBMJSSE2" sslProtocol="SSL_TLS" keyStore="KeyStore_1" trustStore="KeyStore_2" trustManager="TrustManager_1" keyManager="KeyManager_1"/> </repertoire>
- Standard-Keystore
- Im folgenden Beispielcode ähnelt das Keystore-Objekt, das den Standard-Keystore darstellt, dem
XML-Objekt.
<keyStores xmi:id="KeyStore_1" name="NodeDefaultKeyStore" password="{xor}349dkckdd=" provider="IBMJCE" location="${WAS_INSTALL_ROOT}/config /cells/myhostNode01Cell/nodes/myhostNode01/key.p12" type="PKCS12" fileBased="true" hostList="" initializeAtStartup="true" managementScope="ManagementScope_1"/>
Der Keystore NodeDefaultKeyStore enthält das persönliche Zertifikat mit der Identität des sicheren Endpunkts. Jede Keystore-Referenz kann die Variable ${WAS_INSTALL_ROOT} verwenden, die in der Laufzeit aufgelöst wird. Der Standard-Keystore-Typ PKCS12 hat das Format mit der höchsten Interoperabilität und kann daher in die meisten Browser importiert werden. Das Kennwort für myhostNode01Cell ist codiert. Der Verwaltungsbereich bestimmt, welche Serverlaufzeit die Keystore-Konfiguration in den Speicher lädt. Schauen Sie sich dazu das folgende Codebeispiel an:<managementScopes xmi:id="ManagementScope_1" scopeName=" (cell):myhostNode01Cell:(node):myhostNode01" scopeType="node"/>
Alle in der Datei security.xml gespeicherten Konfigurationsobjekte, deren Verwaltungsbereiche außerhalb des Bereichs des aktuellen Prozesses liegen, werden nicht in den aktuellen Prozess geladen. Der Verwaltungsbereich wird stattdessen von Servern auf dem Knoten "myhostNode01" geladen. Jeder Anwendungsserver auf dem angegebenen Knoten kann die Keystore-Konfiguration sehen.
Wenn Sie den Inhalt der Datei key.p12 auflisten, um das verkettete Zertifikat anzuzeigen, beachten Sie, dass der allgemeine Name (CN, Common Name) oder der definierte Name (DN, Distinguished Name) der Hostname der residenten Maschine ist. In der Auflistung können Sie den Hostnamen anhand seiner URL-Verbindungen prüfen. Zusätzlich können Sie den Hostnamen von einem eigenen Trust Manager aus verifizieren. Weitere Informationen hierzu finden Sie im Artikel Entscheidungen über die Vertrauenswürdigkeit von X.509-Zertifikaten mit dem Trust-Manager treffen.
- Inhalt des Standard-Keystore
- Der folgende Beispielcode zeigt den Inhalt der Standarddatei
key.p12 in einer keytool-Liste:
keytool -list -v -keystore c:\WebSphere\AppServer\profile\AppSrv01\profiles\config \cells\myhostNode01Cell\nodes\myhostNode01\key.p12 -storetype PKCS12 -storepass *****
${profile_root}\config\cells\${cellname}\nodes\${nodename}> keytool -list -v -keystore ${WAS_INSTALL_ROOT}/profile/default/config/cells/myhostNode01Cell /nodes/myhostNode01/key.p12 -storetype PKCS12 -storepass *****
Keystore type: PKCS12 Keystore provider: IBMJCE Your keystore contains 1 entry Alias name: default Creation date: Dec 31, 1969 Entry type: keyEntry Certificate chain length: 2 Certificate[1]: Owner: CN=myhost.austin.ibm.com, OU=myhostNode01Cell, OU=myhostNode01, O=IBM, C=US Issuer: CN=myhost.austin.ibm.com, OU=Root Certificate, OU=myhostNode01Cell, OU=myhostNode01, O=IBM, C=US Serial number: 4e48f29aafea6 Valid from: 2/7/08 1:03 PM until: 2/6/09 1:03 PM Certificate fingerprints: MD5: DB:FE:65:DB:40:13:F4:48:A4:CE:2F:4F:60:A5:FF:2C SHA1: A1:D4:DD:4B:DE:7B:45:F7:4D:AA:6A:FC:92:38:78:53:7A:99:F1:DC Certificate[2]: Owner: CN=myhost.austin.ibm.com, OU=Root Certificate, OU=myhostNode01Cell, OU=myhostNode01, O=IBM, C=US Issuer: CN=myhost.austin.ibm.com, OU=Root Certificate, OU=myhostNode01Cell, OU=myhostNode01, O=IBM, C=US Serial number: 4e48e5fd4eae3 Valid from: 2/7/08 1:03 PM until: 2/2/28 1:03 PM Certificate fingerprints: MD5: A5:9B:05:78:CF:AB:89:94:C9:2E:F1:87:34:B3:FC:75 SHA1: 43:74:B6:C7:FA:C1:0F:19:F2:51:2B:17:60:0D:34:93:55:BF:D5:D2 ******************************************* *******************************************
Der Aliasname "default" und der Eintragstyp (Entry type) "keyEntry" zeigen an, dass der private Schlüssel mit dem öffentlichen Schlüssel gespeichert ist, was ein vollständiges persönliches Zertifikat darstellt. Eigner des Zertifikats ist CN=myhost.austin.ibm.com, OU=myhostNode01Cell, OU=myhostNode01, O=IBM, C=US. Das Zertifikat wird mit dem Standardstammzertifikat ausgestellt, dessen Eigner CN=myhost.austin.ibm.com, OU=Root Certificate, OU=myhostNode01Cell, OU=myhostNode01, O=IBM, C=US ist. Standardmäßig ist das Zertifikat für ein Jahr ab dem Erstellungsdatum gültig.
In einigen Situationen mit Austausch der Sicherheitssignatur wird zusätzlich mit dem elektronischen Fingerabdruck sicherstellt, dass das gesendete Zertifikat nicht modifiziert wurde. Der elektronische Fingerabdruck ist die Ausgabe eines Hash-Algorithmus für das Zertifikat und wird in der Laufzeit von WebSphere Application Server während eines automatisierten Austauschs der Signatur auf der Clientseite angezeigt. Der elektronische Fingerabdruck des Clients muss mit dem auf dem Server angezeigten Fingerabdruck übereinstimmen. Die Laufzeit generiert elektronische Fingerabdrücke für Zertifikate in der Regel mit dem Hash-Algorithmus SHA1.
- Standard-Truststore
- Im folgenden Beispielcode repräsentiert das Keystore-Objekt den Standard-Truststore
trust.p12. Der Truststore enthält Unterzeichnerzertifikate, die für Entscheidungen notwendig sind, die Vertrauen voraussetzen:
<keyStores xmi:id="KeyStore_2" name="NodeDefaultTrustStore" password="{xor}349dkckdd=" provider="IBMJCE" location="${WAS_INSTALL_ROOT} /config/cells/myhostNode01Cell/nodes/myhostNode01/trust.p12" type="PKCS12" fileBased="true" hostList="" initializeAtStartup="true" managementScope="ManagementScope_1"/>
- Inhalt des Standard-Truststores
- Der folgende Beispielcode zeigt den Inhalt des Standard-Truststores
trust.p12 in einer keytool-Liste. Standardmäßig wird das Stammzertifikat
für das verkettete Zertifikat in den Truststore aufgenommen.
Der Aliasname des Stammunterzeichners und der Eintragstyp (Entry type)
"trustedCertEntry" weisen darauf hin, dass das Zertifikat der öffentliche Schlüssel ist.
Der private Schlüssel ist nicht in diesem Truststore
gespeichert. Außerdem enthalten alle Truststores das
DataPower-Standardzertifikat.
keytool -list -v -keystore c:\WebSphere\AppServer\profile\AppSrv01\profiles\config\cells\myhostNode01Cell \nodes\myhostNode01\trust.p12 -storetype PKCS12 -storepass *****
${profile_root}\config\cells\${cellname}\nodes\${nodename}> keytool -list -v -keystore ${WAS_INSTALL_ROOT}/profile/default/config/cells/myhostNode01Cell /nodes/myhostNode01/trust.p12 -storetype PKCS12 -storepass *****
Keystore type: PKCS12 Keystore provider: IBMJCE Your keystore contains 2 entries Alias name: root Creation date: Dec 31, 1969 Entry type: trustedCertEntry Owner: CN=myhost.austin.ibm.com, OU=Root Certificate, OU=myhostNode01Cell, OU=myhostNode01, O=IBM, C=US Issuer: CN=myhost.austin.ibm.com, OU=Root Certificate, OU=myhostNode01Cell, OU=myhostNode01, O=IBM, C=US Serial number: 4e48e5fd4eae3 Valid from: 2/7/08 1:03 PM until: 2/2/28 1:03 PM Certificate fingerprints: MD5: A5:9B:05:78:CF:AB:89:94:C9:2E:F1:87:34:B3:FC:75 SHA1: 43:74:B6:C7:FA:C1:0F:19:F2:51:2B:17:60:0D:34:93:55:BF:D5:D2 ******************************************* ******************************************* Alias name: datapower Creation date: Dec 31, 1969 Entry type: trustedCertEntry Owner: OU=Root CA, O="DataPower Technology, Inc.", C=US Issuer: OU=Root CA, O="DataPower Technology, Inc.", C=US Serial number: 0 Valid from: 6/11/03 1:23 PM until: 6/6/23 1:23 PM Certificate fingerprints: MD5: 18:AC:86:D1:9A:90:A2:AE:8B:28:F9:A8:75:C8:A9:DB SHA1: A9:BA:A4:B5:BC:26:2F:5D:2A:80:93:CA:BA:F4:31:05:F2:54:14:17