Keystore-Konfigurationen für SSL

In Keystore-Konfigurationen können Sie definieren, wie die Laufzeit von WebSphere Application Server Keystore-Typen für SSL-Konfigurationen lädt und verwaltet.

Das Attribut "java.security.Security.getAlgorithms("KeyStore")" zeigt standardmäßig keine vordefinierte Liste von Keystore-Typen in der Administrationskonsole an. Stattdessen ruft WebSphere Application Server alle Keystore-Typen ab, die vom Objekt "java.security.KeyStore" referenziert werden können, einschließlich Hardwareverschlüsselungskeystores, Keystores der Plattform z/OS, Keystores der Plattform IBM® i, IBMJCE-Keystores (IBM Java™ Cryptography Extension) und Java-basierten-CMS-Provider-Keystores (CMS, Certificate Management Services). Wenn Sie in der Datei java.security einen Keystore-Provider angeben oder programmgesteuert einen Keystore-Provider zur Liste hinzufügen, ruft WebSphere Application Server auch angepasste Keystores ab. Die Abrufliste hängt von der java.security-Konfiguration für die jeweilige Plattform und den jeweiligen Prozess ab.

Dateibasierte IBMJCE-Keystores (JCEKS, JKS und PKCS12)

Der folgende Beispielcode zeigt eine typische Konfiguration für einen dateibasierten IBMJCE-Keystore:
<keyStores xmi:id="KeyStore_1" name="NodeDefaultKeyStore" 
password="{xor}349dkckdd=" provider="IBMJCE"
location="${USER_INSTALL_ROOT}/config/cells/myhostNode01Cell
/nodes/myhostNode01/key.p12" type="PKCS12" fileBased="true" 
hostList="" initializeAtStartup="true" readOnly="false" 
description="Default key store for myhostNode01" usage="SSLKeys" 
managementScope="ManagementScope_1"/>
Weitere Informationen zu Standardkeystorekonfigurationen finden Sie unter Standardkonfiguration mit verkettetem Zertifikat in SSL.
In Tabelle 1 sind die Attribute beschrieben, die im Beispielcode verwendet werden.
Tabelle 1. Keystore-Konfigurationen . In der folgenden Tabelle sind die Keystorekonfigurationen beschrieben.
Attributname Standardeinstellung Beschreibung
xmi:id veränderlich Ein Wert, der abgesetzt wird, um den Keystore von einem anderen Bereich der Konfiguration aus zu referenzieren, z. B. von einer SSL-Konfiguration aus. Dieser Wert muss innerhalb der Datei security.xml eindeutig sein.
name Für einen JSSE-Keystore: CellDefaultKeyStore. Für einen JSSE-Truststore: CellDefaultTrustStore. Ein Name, mit dem der Keystore identifiziert werden kann, wenn er sichtbar ist. Anhand der Endung des Namens auf DefaultKeyStore oder DefaultTrustStore lässt sich feststellen, ob es sich um einen Standard-Keystore handelt.
password Das Keystore-Standardkennwort ist WebAS. Sie sollten dieses Kennwort so bald wie möglich ändern. Nähere Informationen finden Sie im Artikel Mit Scripting die Standardkennwörter für die Keystores ändern. Das Kennwort für den Zugriff auf den Keystore-Namen wird auch zum Speichern von Schlüsseln im Keystore verwendet.
description Keine Eine Beschreibung des Keystores.
usage Ein Attribut, das angibt, für welchen Zweck der Keystore verwendet wird. Die gültigen Werte sind SSLKeys, KeySetKeys, RootKeys, DeletedKeys, DefaultSigners, RSATokenKeys.
provider Der Standardprovider ist IBMJCE. Der Java-Provider, der das Attribut "type" implementiert (z. B. Typ PKCS12). Sie müssen keinen Provider angeben. In diesem Fall wird der erste Provider verwendet, der den angegebenen Keystoretyp implementiert.
location Der Standardwert ist variabel, referenziert jedoch normalerweise eine Datei mit dem Namen key.p12 oder trust.p12 in den Knoten- oder Zellenverzeichnissen des Konfigurationsrepositorys. Diese Dateien sind Keystores vom Typ PKCS12. Die Referenz auf die Keystore-Position. Wenn der Keystore dateibasiert ist, kann die Position jeden Pfad im Dateisystem des Knotens mit dem Keystore referenzieren. Wenn die Position jedoch außerhalb des Konfigurationsrepositorys liegt und Sie den Keystore fern von der Administrationskonsole oder dem Dienstprogramm wsadamin aus verwalten möchten, geben Sie das Attribut hostList mit dem Namen des Knotens an, auf dem sich der Keystore befindet.
type Der Standard-Java-Keystore-Typ für Verschlüsselungseinheiten ist PKCS12. Dieser Typ gibt den Keystore an. Gültige Typen können die vom Attribut java.security.Security.getAlgorithms("KeyStore") zurückgegebenen Typen sein. Dazu gehören folgende Keystore-Typen, deren Verfügbarkeit von der Prozess- und Plattformkonfiguration in java.security abhängt:
  • JKS
  • JCEKS
  • PKCS12
  • PKCS11 (Java-Verschlüsselungseinheit)
  • CMSKS
  • IBMi5OSKeyStore
  • JCERACFKS
  • JCECCAKS-Keystores (ersetzen JCE4758KS) - (z/OS-Verschlüsselungseinheit)
fileBased Die Standardeinstellung ist true. Diese Option ist für Standard-Keystores erforderlich. Sie gibt einen Keystore im Dateisystem an, den Sie mit einem FileInputStream oder FileOutputStream laden bzw. speichern können.
hostList Das Attribut hostList gibt den Namen eines fernen Hosts an, damit der Keystore fern verwaltet werden kann. Standardmäßig gibt es keine fern verwalteten Keystores. Alle Standard-Keystores werden lokal im Konfigurationsrepository verwaltet und auf allen Knoten synchronisiert. Mit dieser Option wird ein Keystore fern verwaltet. Als Hostnamen können Sie einen gültigen Knoten für einen Keystore angeben. Wenn Sie die Zertifikate für diesen Keystore mit der Administrationskonsole oder dem Dienstprogramm wsadmin verwalten, wird an den Knoten, auf dem sich der Keystore befindet, ein MBean-Aufruf für die freigegebene Operation abgesetzt. Sie können mehrere Hosts angeben, obwohl die Synchronisation der Keystore-Operationen nicht gewährleistet werden kann. Einer der aufgelisteten Hosts könnte beispielsweise heruntergefahren sein, während eine bestimmte Operation ausgeführt wird. Mehrere Hosts sollten Sie daher in dieser Liste angeben.
initializeAtStartup Die Standardeinstellung ist true. Diese Option teilt der Laufzeit mit, dass der Keystore beim Systemstart initialisiert werden soll. Sie kann für die Beschleunigung von Hardwareverschlüsselungseinheiten bedeutsam sein.
readOnly Die Standardeinstellung ist false. Diese Option teilt der Konfiguration mit, dass Sie nicht in diesen Keystore schreiben dürfen. Bestimmte Aktualisierungsoperationen für den Keystore sind damit unzulässig und können nicht ausgeführt werden. Ein Beispiel für einen schreibgeschützten Keystore-Typ der z/OS-Plattform ist JCERACFKS. Dieser Typ ist aus Sicht des WebSphere-Zertifikatmanagements schreibgeschützt, kann jedoch mit der Keystore-Verwaltungsfunktion für RACF aktualisiert werden.

[z/OS]Optional können Sie die Unterstützung beschreibbarer Schlüsselringe konfigurieren, die die Verwendung weiterer Keystore-Konfigurationen für die Zertifikatsverwaltung ermöglichen. Weitere Informationen zum Konfigurieren und Verwenden beschreibbarer Keystore-Konfigurationsobjekte finden Sie in den Artikeln Beschreibbare SAF-Schlüsselringe erstellen und Beschreibbare SAF-Schlüsselringe verwenden.

managementScope Der Standardbereich ist der Knotenbereich für eine Base Application Server-Umgebung und der Zellenbereich für eine Network Deployment-Umgebung. Diese Option referenziert einen bestimmten Verwaltungsbereich, in dem Sie diesen Keystore sehen können. Wenn sich auf einem bestimmten Knoten beispielsweise physisch eine Hardwareverschlüsselungseinheit befindet, erstellen Sie den Keystore als Link zu diesem Knoten in der Topologie. Wählen Sie dazu Sicherheit > Sichere Kommunikation > SSL-Konfigurationen aus. Mit dem Verwaltungsbereich können Sie auch eine Keystore-Referenz eingrenzen. In einigen Fällen kann es sinnvoll sein, nur einem bestimmten Anwendungsserver die Referenzierung des Keystore zu erlauben. Der Verwaltungsbereich wäre dann auf diesen spezifischen Server beschränkt.
[z/OS]

z/OS-Keystores

WebSphere Application Server unterstützt dateibasierte IBMJCE-Keystores, JCEKS (Java Cryptography Extension Key Stores), Java-Keystores (JKS) sowie PKCS12-Keystores (Public Key Cryptography Standards 12) und z/OS-spezifische Keystores. Die Unterstützung für dateibasierte IBMJCE-Keystores unter z/OS ist mit der Unterstützung auf der verteilten Plattform vergleichbar und mit dieser vollständig kompatibel.

Der Provider IBMJCECCA erweitert und ersetzt den Provider IBMJCE4758 aus früheren Releases. Der Provider IBMJCECCA und der Provider IBMJCE4758 sind funktional gleich. Der Provider IBMJCECCA unterstützt vier Keystores: JCECCAKS (JCE4758KS) und JCECCARACFKS (JCE4758RACFKS).

Der Keystore JCECCAKS verwendet Schlüssel, die in der z/OS-Hardware gespeichert sind und von ICSF verwaltet werden. Der Keystore JCECCARACFKS verwendet Zertifikate, die in RACF-Schlüsselringen gespeichert und verwaltet werden sowie Schlüssel, die in der z/OS-Hardware gespeichert werden. Die Keystores JCE4758KS und JCE4758RACFKS werden für die Abwärtskompatibilität bereitgestellt und sind veraltet. Der Keystore JCECCAKS erweitert und ersetzt den Keystore JCE4758KS. Der Keystore JCECCARACFKS erweitert und ersetzt den Keystore JCE4758RACFKS.

Auf der z/OS-Plattform können für WebSphere Application Server drei zusätzliche Keystore-Typen verwendet werden:
  • JCECCAKS-Keystores (die JCE4758KS ersetzen) verwenden Schlüssel, die in der z/OS-Hardware gespeichert werden, und Schlüssel, die in ICSF verwaltet werden.
  • JCERACFKS-Keystores sind RACF-basierte (Resource Access Control Facility) Keystores, die zur Unterstützung von in einem RACF-Keystore enthaltenen Schlüsseln und Zertifikaten verwendet werden. In ICSF gespeicherte Schlüsseldaten werden von diesem Keystore-Typ unterstützt.
  • JCECCARACFKS-Keystores (die JCE4758RACFKS erweitern und ersetzen) sind RACF-basierte Keystores, die für die Unterstützung von in einem RACF-Keystore enthaltenen Zertifikaten und von in der z/OS-Hardware gespeicherten Schlüsseln verwendet werden. Die ICSF-Option mit RACF RACDCERT muss angegeben werden.
Anmerkungen:
  • Der Keystore-Typ JCERACFKS für den Provider IBMJCE und der Keystore-Typ JCECCARACFKS für den Provider IBMJCECCA sind nur auf der Plattform z/OS verfügbar, wenn SAF (System Authorization Facility) verfügbar ist.
  • You WebSphere Application Server können Sie die Administrationskonsole verwenden, um ein persönliches Zertifikat in HFS als Base64-verschlüsselten ASCII-Datentyp oder als binären DER-Datentyp zu extrahieren. Wenn die SSL-Konfiguration jedoch den Keystore-Typ JCERACFKS hat, wird eine Datei mit einer Größe von 0 Bytes in HFS erstellt.
  • Für die Kompatibilität mit dem JCE-Keystore, der ein Kennwort erfordert, muss JCERACFKS ein Kennwort haben, das jedoch password lauten muss. Die Sicherheit für diesen Keystore wird nicht wie bei anderen Keystore-Typen allein durch die Verwendung eines Kennworts gewährleistet. Sie basiert in diesem Fall eher auf der Identität des ausführenden Threads für den Schutz mit RACF. Dieses Kennwort ist für die Keystore-Datei bestimmt die Sie im Feld "Pfad" angegeben haben.

Ein IBMJCE-Provider kann aus der Gruppe der zuvor aufgelisteten z/OS-spezifischen Keystores nur JCERACFKS unterstützen. Der Provider IBMJCE kann die Keystores JCECCAKS und JCECCARACFKS nicht verwenden, da sie hardwarespezifisch sind.

Ein IBMJCECCA-Provider kann Softwarematerial für die Keystores JCERACFKS, JKS und JCEKS unterstützen und von der Hardwarebeschleunigung profitieren.

Den Providern IBMJCE und IBMJCECCA wurde die neue Keystore-Klasse JceRACFKeyStore hinzugefügt. Verwenden Sie diese Klasse, wenn Sie Zertifikate und Schlüssel von einem Schlüsselring abrufen, denn sie ermöglicht WebSphere Application Server, einen Schlüsselring zu lesen. Wenn der Server jedoch versucht, Daten in den Schlüsselring zu schreiben, wird eine IOException ausgelöst. Verwendet der Server einen anderen Keystore als die Klasse JceRACFKeyStore, besteht die Möglichkeit, dass in RACF gespeicherte Daten versehentlich in eine HFS-Datei geschrieben werden, da der RACFInputStream für jeden Keystore funktioniert.

Der RACFInputStream kann mit einer der folgenden Methoden auf Schlüssel und Zertifikate zugreifen, die in einer SAF-Schlüsselringimplementierung (System Authorization Facility) gespeichert sind:
  • Mit dem RACFInputStream kann direkt eine neu erstellte Instanz an die Klasse JceRACFKeyStore übergeben werden.
  • Mit dem URLStreamHandler wird der RACFInputStream aufgerufen und dann die Instanz an die Klasse JceRACFKeyStore übergeben.
Weitere Informationen finden Sie unter RACF-Schlüsselring konfigurieren.

Alle Java-RACF-Services, einschließlich JceRACFKeyStore und RACFInputStream, verwenden den Service R_datalib (IRRSDL00), um Zertifikate von RACF abzurufen. Wenn Sie diesen Service nutzen möchten, müssen Sie vor Verwendung von Java-RACF-Klassen eine Berechtigung für R_datalib anfordern. Weitere Informationen zum Konfigurieren der erforderlichen Berechtigungen finden Sie in der Veröffentlichung z/OS Security Server Callable Services.

CMS-Keystores

In CMS-Keystores können Sie einige providerspezifische Attribute setzen.

[z/OS][AIX Solaris HP-UX Linux Windows]Wenn der CMSKS-Provider das Attribut "createStashFileForCMS" unterstützt und Sie dieses Attribute für CMSKS-Keystores auf true setzen, erstellt WebSphere Application Server an der vom Attribut referenzierten Keystore-Position eine Datei .sth. Die Erweiterung .sth wird an den Keystore-Namen angehängt. Wenn der Keystore CMSKS beispielsweise für eine Plug-in-Konfiguration verfügbar ist und Sie createStashFileForCMS auf true setzen, wird die im folgenden Beispielcode dargestellte Stash-Datei im Pfad ${USER_INSTALL_ROOT}\profiles\AppSrv01/config/cells/myhostCell01/nodes/myhostNode01/servers/webserver1/plugin-key.sth erstellt.
<keyStores xmi:id="KeyStore_1132071489571" name="CMSKeyStore" 
password="{xor}HRYNFAtrbxEwOzpvbhw6MzM=" provider="IBMCMSProvider" 
location="${USER_INSTALL_ROOT}\profiles\AppSrv01/config/cells/myhostCell01
/nodes/myhostNode01/servers/webserver1/plugin-key.kdb" type="CMSKS"
fileBased="true" createStashFileForCMS="true" 
managementScope="ManagementScope_1132071489569"/>
Wenn Sie einen CMS-Keystore erstellen, ist der CMS-Provider IBMi5OSJSSEProvider und der CMS-Typ IBMi5OSKeyStore. Schauen Sie sich hierzu den folgenden Beispielcode an:
<keyStores xmi:id="KeyStore_1132071489571" name="CMSKeyStore" 
password="{xor}HRYNFAtrbxEwOzpvbhw6MzM=" provider="IBMi5OSJSSEProvider" 
location="${USER_INSTALL_ROOT}\profiles\AppSrv01/config/cells/myhostCell01
/nodes/myhostNode01/servers/webserver1/plugin-key.kdb" type="IBMi5OSKeyStore"
fileBased="true" createStashFileForCMS="true" 
managementScope="ManagementScope_1132071489569"/>
[IBM i]Anmerkung: Der Keystore-Typ der Plattform IBM i, IBMi5OSKeyStore, erkennt und generiert keine Kennwortstashdatei mit der Erweiterung .sth. Er speichert stattdessen einen internen Eintrag mit dem Kennwort für die Kystore-Datei (.kdb) an der Erstellungsposition dieser Datei. Wird die Datei .kdb verschoben, ist das Kennwort dem Keystore nicht mehr zugeordnet. In einem solchen Fall müssen Sie mit dem DCM (Digital Certificate Manager) den internen Eintrag mit dem Kennwort für die Keystore-Datei (.kdb) wiederherstellen. Weitere Informationen hierzu finden Sie im Artikel Internen Kennwortsatz für den Keystore .kdb erneut erstellen..
[IBM i]Achtung: Wenn Sie verkettete persönliche Zertifikate erstellt haben oder die Task "requestCACertificate" mit dem IBMi5OSKeyStore verwenden, erfordert der IBMi5OSJSSEProvider, dass der Unterzeichner für jedes Glied der Kette im Keystore vorhanden ist, bevor das neue Zertifikat erstellt wird. Deshalb müssen Sie den Unterzeichner in den Keystore "IBMi5OSKeyStore" importieren, bevor Sie das neue Zertifikat erstellen.

Keystores für Hardwareverschlüsselung

Informationen zur Konfiguration von Verschlüsselungseinheiten finden Sie im Artikel Schlüsselverwaltung für Verschlüsselung.

Einen Slot können Sie als angepasste Eigenschaft com.ibm.ssl.keyStoreSlot oder als Konfigurationsattribut slot="0" hinzufügen. Die angepasste Eigenschaft wird vor dem Attribut für Abwärtskompatibilität gelesen.


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_sslkeystoreconfs
Dateiname:csec_sslkeystoreconfs.html