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 dem [z/OS]standardmäßig verwendeten Profilnamen [IBM i][AIX Solaris HP-UX Linux Windows]AppSrv01, dem Namen "myhostNode01Cell" und dem Knotennamen "myhostNode01" erstellt. Der Keystore und der Truststore befinden sich in folgenden Verzeichnissen:
  • [AIX Solaris HP-UX Linux Windows][IBM i]C:\WebSphere\AppServer\profiles\AppSrv01\config\cells\myhostNode01Cell \nodes\myhostNode01\key.p12
  • [AIX Solaris HP-UX Linux Windows][IBM i]C:\WebSphere\AppServer\profiles\AppSrv01\config\cells\myhostNode01Cell \nodes\myhostNode01\trust.p12
  • [z/OS]${WAS_INSTALL_ROOT}/profile/default/config/cells/myhostNode01Cell/nodes/myhostNode01/key.p12
  • [z/OS]${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:
  1. 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.
  2. Löschen Sie den Stamm-Keystore, die Datei "root-key.p12", um das Stammzertifikat mit den zuvor aufgelisteten Eigenschaften neu zu generieren.
  3. Starten Sie den Deployment Manager, seinen Knoten und alle Server erneut.
  4. 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: [AIX Solaris HP-UX Linux Windows][IBM i]
keytool -list -v -keystore c:\WebSphere\AppServer\profile\AppSrv01\profiles\config
\cells\myhostNode01Cell\nodes\myhostNode01\key.p12 -storetype PKCS12 -storepass *****
[z/OS]
${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. [AIX Solaris HP-UX Linux Windows][IBM i]
keytool -list -v -keystore c:\WebSphere\AppServer\profile\AppSrv01\profiles\config\cells\myhostNode01Cell
\nodes\myhostNode01\trust.p12 -storetype PKCS12 -storepass *****
[z/OS]
${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

Symbol, das den Typ des Artikels anzeigt. Konzeptartikel



Symbol für Zeitmarke Letzte Aktualisierung: 25.05.2016
http://www14.software.ibm.com/webapp/wsbroker/redirect?version=cord&product=was-nd-mp&topic=csec_7ssldefault_chainedcert_config
Dateiname:csec_7ssldefault_chainedcert_config.html