Informationen zu diesem Vorgang
Die SSL-Clientauthentifizierung findet während des Verbindungshandshakes
unter Verwendung von SSL-Zertifikaten statt. Der SSL-Handshake ist eine Folge von Nachrichten, die über das SSL-Protokoll ausgetauscht werden, um einen
verbindungsspezifischen Schutz auszuhandeln. Während des Handshakes fordert der Sicherheitsserver vom Client die Rücksendung eines Zertifikats oder einer Reihe von Zertifikaten zwecks Authentifizierung an. Fügen Sie zum Aktivieren von SSL in Liberty das Liberty-Feature ssl-1.0 der Konfigurationsstammdokumentdatei server.xml zusammen mit dem Code der Keystore-Informationen für die Authentifizierung hinzu.
Standardmäßig werden für die Konfigurationsstammdokumentdatei der folgende Pfad und der folgende Dateiname verwendet: Liberty-Pfad/wlp/usr/servers/Servername/server.xml. Liberty-Pfad ist die Position, die Sie Liberty auf Ihrem Betriebssystem installiert haben, und Servername ist der Name Ihres Servers.Sie können
den Pfad jedoch ändern. Informationen hierzu finden Sie unter Liberty-Umgebung anpassen.
- Aktivieren Sie das Liberty-Feature ssl-1.0 in der Datei server.xml.
<featureManager> <feature>ssl-1.0</feature>
</featureManager>
Anmerkung: Wenn Anwendungssicherheit erforderlich ist und Sicherheitsinformationen an einen sicheren Port weitergeleitet werden, müssen Sie das
Liberty-Feature appSecurity-2.0 der Datei server.xml hinzufügen.
Wenn das Feature ssl-1.0 aktiviert ist, erstellt der Liberty-Server einen SSL-Kontext aus der
SSL-Standardkonfiguration und übernimmt diesen SSL-Kontext als Standardeinstellung für den Server, indem er die Java-API
SSLContext.setDefault() aufruft. Auf diese Weise wird der SSL-Standardkontext des Liberty-Servers zum SSL-Standardkontext des Prozesses. Beim Absetzen des Java-API-Aufrufs
SSLContext.getDefault() gibt die Methode den SSL-Kontext von
Liberty zurück. Dasselbe gilt insofern auch für die Java-API
SSLSocketFactory.getDefault(), als die Standard-Socket-Factory des SSL-Standardkontextes zurückgegeben wird.
Alternativ kann die SSL-Kommunikation durch Hinzufügen des
Liberty-Features "transportSecurity-1.0" in der Datei
server.xml aktiviert werden. <featureManager>
<feature>transportSecurity-1.0</feature>
</featureManager>
Das Feature transportSecurity-1.0 ersetzt das Feature ssl-1.0
und fügt Funktionen hinzu, die im Feature ssl-1.0 nicht enthalten sind. Sie können eine
SSL-Konfiguration, die als Standardkonfiguration für abgehende Verbindungen verwendet werden soll, angeben und Filter für eine
SSL-Konfiguration konfigurieren, sodass die SSL-Konfiguration für einen abgehenden SSL-Aufruf basierend auf einem Zielhost und Zielport verwendet werden kann.
Weitere Informationen zu SSL-Optionen für abgehende Verbindungen finden Sie in den Abschnitten SSL-Einstellungen für abgehende Kommunikation konfigurieren und Filter für abgehende Verbindungen für SSL-Konfigurationen.
Wenn das Feature transportSecurity-1.0 aktiviert ist, legt der Liberty-Server eine angepasste SSL-Socket-Factory
fest, die die Java-Sicherheitseigenschaft ssl.SocketFactory.provider verwendet. Diese Sicherheitseigenschaft
wird automatisch gesetzt, wenn das Feature transportSecurity-1.0 aktiviert wird.
Wenn Sie das Feature transportSecurity-1.0 verwenden, verwendet der Prozess standardmäßig
den SSL-Standardkontext von Java Secure Socket Extension (JSSE). Beim Aufruf von
SSLContext.getDefault() wird der SSL-Standardkontext von
JSSE zurückgegeben. Beim Aufruf von SSLSocketFactory.getDefault()
wird eine SSL-Socket-Factory zurückgegeben, die auf dem angepassten Socket-Factory-Provider des Liberty-Servers basiert, der den
SSL-Kontext von Liberty verwendet.
Das Attribut outboundSSLRef und das Element outboundConnection werden für abgehende SSL-Verbindungen nur verwendet, wenn das Feature
transportSecurity-1.0 angegeben ist.
Wenn das Feature ssl-1.0 angegeben ist, das Feature
transportSecurity-1.0 aber nicht, werden das Attribut outboundSSLRef
und das Element outboundConnection ignoriert.
Anmerkung: Wenn Sie eine Umstellung von Feature ssl-1.0 auf das Feature
transportSecurity-1.0 oder vom Feature transportSecurity-1.0 auf das Feature ssl-1.0 vornehmen,
muss der Liberty-Server aufgrund der Spezifik von JDK erneut gestartet werden, damit das Feature in vollem Umfang genutzt werden kann.
- Nehmen Sie das Keystore-Serviceobjekt in die Datei
server.xml auf.
Das Element
keyStore hat den Namen defaultKeyStore und enthält das Keystore-Kennwort. Das Kennwort kann in Klartext oder verschlüsselt angegeben werden. Zum Verschlüsseln des Kennworts kann die Option
securityUtility
encode verwendet werden.
<keyStore id="defaultKeyStore" password="yourPassword" />
Ein Beispiel für eine SAF-Schlüsseldatei in der Minimalkonfiguration:<keyStore id="defaultKeyStore" location="safkeyring:///WASKeyring"
type="JCERACFKS" password="password" fileBased="false"
readOnly="true" />
Der RACF-Schlüsselring muss konfiguriert werden, bevor
er vom Liberty-Server verwendet werden kann. Der Server erstellt keine Zertifikate und fügt diese auch nicht RACF hinzu.
Der einzelne Keystore-Eintrag für eine SSL-Minimalkonfiguration kann so erweitert werden,
dass er auch die Position und den Typ enthält.
<keyStore id="defaultKeyStore" location="myKeyStore.p12" password="yourPassword" type="PKCS12" />
Diese Konfiguration ist die Mindestkonfiguration, die zum Erstellen einer SSL-Konfiguration erforderlich ist.
In dieser Konfiguration erstellt der Server den Keystore und das Zertifikat automatisch, falls diese
während der SSL-Initialisierung nicht vorhanden sind. Das angegebene Kennwort muss mindestens sechs Zeichen lang sein.
Als Keystore wird ein JKS-Keystore mit dem Namen "key.jks" im Verzeichnis "Serverausgangsverzeichnis/resources/security" vorausgesetzt. Wenn die Datei
nicht vorhanden ist, erstellt sie der Server automatisch. Wenn der Server die Keystore-Datei erstellt, erstellt er auch das Zertifikat in diesem Keystore.
Das Zertifikat ist ein selbst signiertes Zertifikat mit einem Gültigkeitszeitraum
von 365 Tagen. Der Wert "CN" von
subjectDN ist der Hostname der Maschine, auf der der Server
ausgeführt wird, und hat den Signaturalgorithmus "SHA256withRSA".
Anmerkung: Wenn die Verwendung eines Verbundcontrollers nicht sinnvoll erscheint, weil es beispielsweise nur einen oder zwei Liberty-Server gibt, kann ein selbst signiertes Zertifikat verwendet werden, um die Anzahl von Clients zu beschränken, die eine Verbindung zum Liberty-Member-Server herstellen können. Es wird empfohlen, einen IHS-Server zu verwenden, der dem Liberty vorgeschaltet wird und für den ein entsprechendes unterzeichnetes Zertifikat einer Zertifizierungsstelle, zusammen mit CN-Whitelisting verwendet werden kann, um zu steuern, welche Clients eine Verbindung zu IHS herstellen können. Sie können einen vertrauenswürdigen Kanal zwischen IHS und dem Liberty-Member-Server verwalten, indem Sie das selbst signierte Zertifikat verwenden.