Sichere Kommunikation mit Secure Sockets Layer (SSL)

Das Protokoll Secure Sockets Layer (SSL) bietet Sicherheit auf Transportebene (d. h. Authentizität, Datensignatur, Datenverschlüsselung) für sichere Verbindungen zwischen Clients und Servern, die WebSphere Application Server verwenden. Die zugrunde liegende Technologie für SSL ist die Public-Key-Verschlüsselung, die sicherstellt, dass die von einer Entität mit ihrem öffentlichen Schlüssel verschlüsselten Daten nur von Entitäten entschlüsselt werden können, die über den entsprechenden privaten Schlüssel verfügen.

WebSphere Application Server verwendet JSSE (Java™ Secure Sockets Extension) als SSL-Implementierung für sichere Verbindungen. JSSE ist Teil der J2SE-Spezifikation (Java 2 Standard Edition) und ist in der IBM® Implementierung der JRE-Spezifikation (Java Runtime Extension) enthalten. JSSE stellt durch die Handshakevereinbarung und die von SSL bereitgestellten Schutzfunktionen sicher, dass über die meisten Protokolle eine sichere Konnektivität möglich ist. JSSE greift für den Schutz sicherer Verbindungen und einen Teil der Datenverschlüsselung auf asymmetrische Schlüsselpaare zurück, die auf X.509-Zertifikaten basieren. Mit Schlüsselpaaren können sitzungsbasierte geheime Schlüssel für größere Datenblocke effektiv verschlüsselt werden. Die SSL-Implementierung verwaltet die X.509-Zertifikate.

WebSphere Application Server wird mit Java SE7 ausgeliefert. Standardmäßig wird mit Java SE 7 SNI (Server Name Indication) aktiviert. SNI ist eine Erweiterung des Protokolls TLS. Mit SNI kann ein Client den Hostnamen angeben, zu dem er eine Verbindung herstellen möchte. Wenn das zurückgegebene Zertifikat nicht mit dem erwarteten Hostnamen übereinstimmt, werden Ausnahmen ausgelöst.

In einigen Proxy-Umgebungen führt dies zu Fehlern. Der Client erwartet das Zertifikat vom Proxy, stattdessen empfängt er jedoch das Zertifikat des Endpunktservers.

X.509-Zertifikate verwalten

WebSphere Application Server erfordert für eine sichere Kommunikation digital signierte X.509-Zertifikate. Der Inhalt eines X.509-Zertifikats, z. B. der definierte Name und das Verfallsdatum des Zertifikats, ist entweder von einer Zertifizierungsstelle, einem Stammzertifikat in NodeDefaultRootStore oder DmgrDefaultRootStore oder selbst signiert. WebSphere Application Server erkennt, ob ein X.509-Zertifikat von einer anerkannten Zertifizierungsstelle (CA, Certificate Authority) signiert ist, und verteilt ein solche Zertifikat ohne Vorbehalt. Ein Zertifikat repräsentiert die Identität einer Entität gegenüber der allgemeinen Öffentlichkeit und muss daher von einer CA signiert sein. Serverseitige Ports, die Verbindungen aus der allgemeinen Öffentlichkeit akzeptieren, müssen von einer CA signierte Zertifikate verwenden. Die meisten Clients oder Browser haben bereits ein Unterzeichnerzertifikat, mit dem das X.509-Zertifikat validiert werden kann. In diesem Fall ist für eine erfolgreiche Verbindung kein Austausch von Unterzeichnern erforderlich.

Sie können der Identität eines selbst signierten X.509-Zertifikats nur dann vertrauen, wenn das Unterzeichnerzertifikat von einem Peer in einer kontrollierten Umgebung akzeptiert wird (z. B. bei der Kommunikation im internen Netz). Für einen anerkannten Handshake müssen Sie zunächst an jeden Peer, der eine Verbindung zu einer Entität herstellen möchte, eine Kopie des Zertifikats dieser Entität senden.

Von einer Zertifizierungsstelle (CA) verkettete und selbst signierte X.509-Zertifikate befinden sich in Java-Keystores. JSSE stellt eine Referenz auf den Keystore bereit, in dem ein Zertifikat enthalten ist. Es stehen verschiedene Arten von Keystores zur Auswahl, z. B. JCE-basierte (Java Cryptographic Extension) und hardwarebasierte Keystores. Jede JSSE-Konfiguration enthält in der Regel Referenzen auf zwei Java-Keystores, von denen einer ein Truststore ist. Die Keystore-Referenz ist ein Java-Keystore-Objekt, das persönliche Zertifikate enthält. Die Truststore-Referenz ist ein Java-Keystore-Objekt, in dem Unterzeichnerzertifikate enthalten sind.

Ein persönliches Zertifikat ohne privaten Schlüssel ist ein X.509-Zertifikat, das den Eigner während eines Handshake repräsentiert. Persönliche Zertifikate enthalten sowohl öffentliche als auch private Schlüssel. Ein Unterzeichnerzertifikat ist ein X.509-Zertifikat, das eine Peerentität oder sich selbst repräsentiert. Unterzeichnerzertifikate enthalten nur den öffentlichen Schlüssel und prüfen die bei einem Handshake zwischen Peers empfangene Signatur der Identität.

Weitere Informationen enthält der Artikel Richtige SSL-Unterzeichnerzertifikate dem Plug-in-Keystore hinzufügen.

Nähere Informationen zu Keystores finden Sie im Artikel Keystore-Konfigurationen für SSL.

Austausch von Unterzeichnern

Wenn Sie eine SSL-Verbindung konfigurieren, können Sie Unterzeichner austauschen, um Vertrauen zu einem persönlichen Zertifikat für eine bestimmte Entität aufzubauen. Beim Austausch von Unterzeichnern können Sie das X.509-Zertifikat aus dem Peer-Keystore extrahieren und zum Truststore einer anderen Entität hinzufügen, damit die beiden Peerentitäten eine Verbindung zueinander herstellen können. Ein Unterzeichnerzertifikat kann auch ein von einer CA ausgestelltes Stammunterzeichnerzertifikat, ein Stammunterzeichnerzertifikat eines verketteten Zertifikats oder ein temporäres Unterzeichnerzertifikat sein. Ein Unterzeichnerzertifikat können Sie auch direkt aus einem selbst signierten Zertifikat extrahieren, das das X.509-Zertifikat mit dem öffentlichen Schlüssel ist.

Abbildung 1 veranschaulicht eine hypothetische Keystore- und Truststore-Konfiguration. Eine SSL-Konfiguration ermittelt, welche Entitäten Verbindungen zu anderen Entitäten herstellen können und welche Peerverbindungen durch einen SSL-Handshake vertrauenswürdig sind. Wenn Sie das notwendige Unterzeichnerzertifikat nicht haben, scheitert der Handshake, weil der Peer nicht vertrauenswürdig ist.
Abbildung 1. Austausch von Unterzeichnern
Eine SSL-Konfiguration ermittelt, welche Entitäten Verbindungen zu anderen Entitäten herstellen können und welche Peerverbindungen durch einen SSL-Handshake vertrauenswürdig sind.

In diesem Beispiel enthält der Truststore für Entität A drei Unterzeichner. Entität A kann Verbindungen zu allen Peers herstellen, sofern einer der drei Unterzeichner sein persönliches Zertifikat validiert. Entität A kann beispielsweise Verbindungen zu Entität B oder C herstellen, weil die Unterzeichner beiden signierten persönlichen Zertifikaten vertrauen können. Der Truststore für Entität B enthält einen Unterzeichner. Entität B kann nur Verbindungen zu Entität C herstellen und dies auch nur dann, wenn der Peerendpunkt als Identität das Zertifikat Zert 1 von Entität C verwendet. Die Ports, die die anderen persönlichen Zertifikate für Entität C verwenden, werden von Entität B nicht anerkannt. Entität C kann nur eine Verbindung zur Entität A herstellen.

In diesem Beispiel scheint die Konfiguration mit dem selbst signierten Zertifikat eine 1:1-Beziehung zwischen dem Unterzeichner und dem Zertifikat zu darzustellen. Eine CA signiert jedoch in der Regel nicht nur ein Zertifikat. Die Verwendung nur eines CA-Unterzeichners hat den Vorteil, dass dieser von der CA für Peers generierte persönliche Zertifikate validieren kann. Wenn der Unterzeichner allerdings eine öffentliche CA ist, besteht die Möglichkeit, dass die signierten Zertifikate für ein von Ihrer Zielentität abweichendes Unternehmen generiert wurden. Für Ihre interne Kommunikation sollten Sie privaten Zertifizierungsstellen und selbst signierten Zertifikaten den Vorrang geben, denn mit diesen können Sie Ihre Verbindungen auf das gewünschte Maß beschränken und unerwünschte Verbindungen verhindern.

SSL-Konfigurationen

Eine SSL-Konfiguration umfasst eine Reihe von Konfigurationsattributen, die Sie einem Endpunkt oder mehreren Endpunkten in der WebSphere Application Server-Topologie zuordnen können. Mit der SSL-Konfiguration können Sie ein SSLContext-Objekt erstellen. Dies ist das grundlegende JSSE-Objekt, mit dem der Server SSL-Socket-Factorys anfordert. Sie können die folgenden Konfigurationsattribute verwalten:
  • einen Aliasnamen für das SSLContext-Objekt
  • eine Version des Handshakeprotokolls
  • eine Keystore-Referenz
  • eine Truststore-Referenz
  • einen Key Manager
  • einen oder mehrere Trust Manager
  • eine Cipher-Suite-Gruppe für eine bestimmte Sicherheitsstufe oder eine bestimmte Cipher-Suite-Liste
  • einen ausgewählten Zertifikatsalias für Client- und Serververbindungen
Die Spezifikationen der einzelnen SSL-Konfigurationsattribute sind im Artikel SSL-Konfigurationen beschrieben.
Anmerkung: WebSphere lässt keine RC4-Cipher-Suite in der Cipher-Liste HIGH zu, damit der Server standardmäßig besser geschützt ist. Es ist möglich, dass RC4-Chiffrierwerte vor dieser Änderung standardmäßig in SSL-Handshakes verwendet wurden. Dadurch, dass RC4-Chiffrierwerte entfernt wurden, wird stattdessen möglicherweise ein AES-Chiffrierwert verwendet. Benutzer stellen möglicherweise einen Leistungsrückgang bei der Verwendung der sichereren AES-Chiffrierwerte fest.

SSL-Konfigurationen auswählen

In früheren Releases von WebSphere Application Server konnten Sie eine SSL-Konfiguration nur durch die direkte Auswahl eines Konfigurationsalias referenzieren. Jeder sichere Endpunkt hatte ein Aliasattribut, das auf eine gültige SSL-Konfiguration innerhalb eines Konfigurationsrepertoires verwies. Bei nur einer Konfigurationsänderung mussten viele Aliasreferenzen für verschiedene Prozesse rekonfiguriert werden. Die direkte Auswahl wird nicht mehr empfohlen, obwohl sie vom aktuellen Release noch unterstützt wird.

Das aktuelle Release stellt eine verbesserte Funktionalität für die Verwaltung von SSL-Konfigurationen bereit und ermöglicht eine flexiblere Auswahl von SSL-Konfigurationen. In diesem Release können Sie folgende Strategien auswählen:
Programmgesteuerte Auswahl
Sie können vor einer abgehenden Verbindung eine SSL-Konfiguration für den aktiven Thread festlegen. WebSphere Application Server stellt sicher, dass die Konfiguration von den meisten Systemprotokollen, einschließlich IIOP (Internet Inter-ORB Protocol), JMS (Java Message Service), HTTP (Hyper Text Transfer Protocol) und LDAP (Lightweight Directory Access Protocol), akzeptiert wird. Nähere Informationen hierzu finden Sie im Artikel SSL-Konfiguration für abgehende Verbindungen programmgesteuert mit der API "JSSEHelper" angeben.
Dynamische Auswahl
Sie können einem bestimmten Zielhost, Port oder abgehenden Protokoll durch vordefinierte Auswahlkriterien dynamisch eine SSL-Konfiguration zuordnen. Wenn WebSphere Application Server die Verbindung aufbaut, wird überprüft, ob der Zielhost und Port vordefinierten Kriterien entsprechen. Zu diesen Kriterien gehört der Domänenabschnitt des Hostnamens. Zusätzlich können Sie vorab das Protokoll für eine bestimmte SSL-Konfiguration für abgehende Verbindungen und eine bestimmte Zertifikatsaliasauswahl definieren. Nähere Informationen enthält der Artikel Dynamische Auswahl abgehender Verbindungen für SSL-Konfigurationen.

Die dynamische Auswahl von SSL-Konfigurationen (Secure Sockets Layer) für abgehende Verbindungen basiert auf den für den Server verfügbaren Verbindungsinformationen, sodass der Server das abgehende Protokoll, den Host oder den Port abgleichen kann, wenn die Erstellung des Clientsockets in com.ibm.websphere.ssl.protocol.SSLSocketFactory stattfindet. Für WebSphere-Verwaltungsverbindungen wie SOAP und Remote Method Invocation (RMI) werden die Informationen in den Thread eingefügt und können für die dynamische Auswahl für abgehende Verbindungen verwendet werden. Die dynamische Auswahl einer SSL-Konfiguration für abgehende Verbindungen stützt sich auf Verbindungsinformationen, die konfiguriert werden, wenn SSL-Eigenschaften abgerufen. Dieser Vorgang gleicht dem Prozess, der im Artikel SSL-Konfiguration für abgehende Verbindungen programmgesteuert mit der API "JSSEHelper" angeben beschrieben ist.

Wenn die abgehende Verbindung über benutzerdefinierte Anwendungen vorgenommen wird, sind Teile der Verbindungsinformationen unter Umständen nicht verfügbar. Einige dieser Anwendungen setzen API-Aufrufe an ein Protokoll ab, um die Verbindung herzustellen. Schließlich ruft die API eine der Methoden "createSocket()" in com.ibm.websphere.ssl.protocol.SSLSocketFactory auf, um den Prozess abzuschließen. Es sind möglicherweise nicht alle Verbindungsinformationen für die dynamische abgehende Auswahl verfügbar, und möglicherweise müssen Sie den Verbindungsfilter für die dynamische abgehende Auswahl anpassen und einen Stern (*) für den fehlenden Teil der Verbindungsinformationen angeben. Der Aufruf von "openConnection()" in einem URL-Objekt ist letztendlich ein Aufruf von createSocket(java.net.Socket socket, String host, int port, boolean autoClose). Die Verbindungsinformationen können unter Verwendung der angegebenen Host- und Portinformationen erstellt werden, aber es ist kein Protokoll angegeben. In diesem Fall muss ein Platzhalterzeichen (der Stern (*)) für den Protokollteil der Verbindungsinformationen für die dynamische Auswahl verwendet werden.

Die meisten Methoden "createSocket()" akzeptieren einen Host oder eine IP-Adresse und einen Port als Parameter. Der Verbindungsfilter für die dynamische Auswahl für abgehende Verbindungen kann mit dem Host und dem Port erstellt werden. Die Standardmethode "createSocket()" ohne Parameter enthält keine Informationen für die Erstellung des Verbindungsfilters für abgehende Verbindungen, sofern die Socket-Factory nicht mit Verbindungsinformationen instanziiert wurde. Wenn keine Verbindungsinformationen verfügbar sind, sollten Sie eine der anderen in diesem Artikel beschriebenen Methoden für die Auswahl einer SSL-Konfiguration verwenden. Die programmgesteuerte Auswahl kann beispielsweise eine geeignete Option sein.

Direkte Auswahl
Sie können wie in früheren Releases eine SSL-Konfiguration auswählen, indem Sie einen bestimmten Aliasnamen verwenden. Diese Methode der Auswahl wird aus Gründen der Abwärtskompatibilität beibehalten, denn viele Anwendungen und Prozesse greifen auf Aliasreferenzen zurück.
Bereichsauswahl
Sie können eine SSL-Konfiguration und den zugehörigen Zertifikatsalias im Keystore der SSL-Konfiguration einem Verwaltungsbereich von WebSphere Application Server zuordnen. Diese Herangehensweise wird für eine zentrale Verwaltung von SSL-Konfigurationen empfohlen. Sie können Endpunkte effizienter verwalten, weil sie sich in einer Topologieansicht der Zelle befinden. Durch die Vererbungsbeziehung zwischen den Bereichen müssen nicht mehr so viele SSL-Konfigurationszuordnungen definiert werden.
Jedes Mal, wenn Sie eine SSL-Konfiguration einem Zellenbereich zuordnen, übernimmt der Knotenbereich innerhalb der Zelle die Konfigurationseinstellungen automatisch. Wenn Sie eine SSL-Konfiguration jedoch einem Knoten zuordnen, setzt die Konfiguration des Knotens die von der Zelle übernommene Konfiguration außer Kraft. In ähnlicher Weise übernehmen die Anwendungsserver eines Knotens automatisch die SSL-Konfiguration dieses Knotens, sofern Sie diese Zuordnungen nicht außer Kraft setzen. Die Topologie greift auf die Vererbungsregeln zurück, nach denen die Zelle die Ausgangsebene bildet, von der alle untergeordneten Ebenen bis hin zu den Endpunkten für jeden Anwendungsserver die Konfigurationseinstellungen übernehmen, sofern Sie nicht eine bestimmte Konfiguration außer Kraft setzen.
Anmerkung: Wenn sich Ihre Anwendungen auf SSL-Konfigurationen stützen, die als individuelle Einstellungen für jede SSL-Konfiguration in der Topologie definiert wurden, aber Ihre Anwendungsserver die SSL-Konfiguration so übernommen haben, wie sie von der Zellenebene bis hin zur Endpunktebene implementiert wurden, können Kommunikationsfehler zwischen den Servern auftreten (z. B. Handshake-Fehler). Sie müssen sicherstellen, dass Ihre Anwendungen einheitlich über die zentrale Verwaltung von SSL-Konfigurationen betrieben werden.
Die Topologieansicht enthält eine Baumstruktur für eingehende Verbindungen und eine für abgehende Verbindungen. Sie können ausgehend von Art und Partner der abgehenden und eingehenden Verbindungen für beide Seiten der SSL-Verbindung verschiedene SSL-Konfigurationen auswählen. Nähere Informationen enthält der Artikel Zentrale Verwaltung von SSL-Konfigurationen.
Da es für die Auswahl von SSL-Konfigurationen viele Möglichkeiten gibt, legt die Laufzeit nach bestimmten Prioritäten fest, welche SSL-Konfiguration ausgewählt wird. Berücksichtigen Sie bei der Auswahl der Herangehensweise die folgenden Prioritätskriterien:
  1. Programmgesteuerte Auswahl. Wenn eine Anwendung mit der API com.ibm.websphere.ssl.JSSEHelper eine SSL-Konfiguration für einen aktiven Thread festlegt, hat diese Konfiguration die höchste Priorität.
  2. Dynamische Auswahlkriterien für den abgehenden Host und Port oder das abgehende Protokoll.
  3. Direkte Auswahl.
  4. Bereichsauswahl. Durch die Vererbung innerhalb eines Bereichs wird garantiert, das dem ausgewählten Endpunkt eine SSL-Konfiguration zugeordnet ist, die von allen untergeordneten Bereichen übernommen und von diesen nicht außer Kraft gesetzt werden kann.

Konfiguration eines verketteten Standardzertifikats

Standardmäßig erstellt WebSphere Application Server ein eindeutigees verkettetes Zertifikat für jeden Knoten. Das verkettete Zertifikat wird mit einem selbst signierten Stammzertifikat unterzeichnet, das im DmgrDefaultRootStore oder NodeDefaultRootStore gespeichert ist. WebSphere Application Server greift nicht mehr auf ein selbst signiertes Zertifikat oder das Standard- bzw. Pseudozertifikat zurück, das mit dem Produkt bereitgestellt wird. Der Standard-Keystore key.p12 und der Standardtruststore trust.p12 sind im Konfigurationsrepository innerhalb des Knotenverzeichnisses gespeichert. Das Standardstammzertifikat wird in der Datei "root-key.p12" im Konfigurationsrepository unter dem Knotenverzeichnis gespeichert.

Alle Knoten legen ihre Unterzeichnerzertifikate aus dem Standardstammzertifikat in diesem allgemeinen Truststore (trust.p12) ab. Nach der Einbindung des Knotens wird die Standard-SSL-Konfiguration automatisch so modifiziert, dass sie auf den gemeinsamen Truststore im Zellenverzeichnis zeigt. Der Knoten kann dann mit allen anderen Servern in der Zelle kommunizieren.

Alle SSL-Standardkonfigurationen enthalten einen Keystore mit dem Namenssuffix "DefaultKeyStore", einen Truststore mit dem Namenssuffix "DefaultTrustStore" und einen Stammspeicher mit dem Namenssuffix "DefaultRootStore". Diese Standardsuffixe weisen die Laufzeitumgebung von WebSphere Application Server an, den Stammunterzeichner des persönlichen Zertifikats dem allgemeinen Truststore hinzuzufügen. Wenn ein Truststore-Name nicht mit "DefaultKeyStore" endet, werden die Stammunterzeichnerzertifikate des Keystores dem allgemeinen Truststore nicht hinzugefügt, wenn Sie den Server einbinden. Sie können die Standard-SSL-Konfiguration ändern, müssen jedoch sicherstellen, dass unter anderem für administrative Verbindungen eine ordnungsgemäße Sicherung gewährleistet ist.

Nähere Informationen hierzu finden Sie in den Artikeln Standardkonfiguration mit verkettetem Zertifikat in SSL [AIX Solaris HP-UX Linux Windows] und [AIX Solaris HP-UX Linux Windows]Standardkonfiguration von Web Server Plug-ins in SSL.

Verfallsdatum von Zertifikaten überwachen

Durch die Überwachung von Zertifikaten wird sichergestellt, dass das verkettete Standardzertifikat für die einzelnen Knoten nicht verfällt. Die Überwachungsfunktion für das Verfallsdatum von Zertifikaten setzt vor dem Verfallsdatum von Zertifikaten und Unterzeichnern eine Warnung ab. Überwacht werden können Zertifikate und Unterzeichner in Keystores, die von der WebSphere Application Server-Konfiguration verwaltet werden. Sie können den Verfallsmonitor so konfigurieren, dass ein Zertifikat automatisch ersetzt wird. Ein verkettetes Zertifikat wird auf der Basis derselben Daten erneut erstellt, die für die Ersterstellung und Signatur mit demselben Stammzertifikat verwendet wurden, mit dem das ursprüngliche Zertifikat signiert wurde. Ein selbst signiertes Zertifikat oder ein verkettetes Zertifikat wird ebenfalls auf der Basis der Daten erneut erstellt, die für die Ersterstellung verwendet wurden.

Der Monitor kann auch automatisch alte Unterzeichner durch die Unterzeichner neuer verketteter oder selbst signierter Zertifikate in Keystores ersetzen, die von WebSphere Application Server verwaltet werden. Der Austausch der Unterzeichner, der in der Laufzeit während der Einbindung und im Rahmen der Verwaltung stattfindet, bleibt erhalten. Weitere Informationen finden Sie im Artikel Überwachung des Zertifikatsablaufs in SSL.

Der Verfallsmonitor ist so konfiguriert, dass verkettete persönliche Zertifikate ersetzt werden, die mit einem Stammzertifikat im DmgrDefaultRootStore oder NodeDefaultRootStore signiert wurden. Das Zertifikat wird mit demselben Stammzertifikat erneuert, das zum Signieren des ursprünglichen Zertifikats verwendet wurde.

Der Monitor kann auch automatisch alte Unterzeichner durch die Unterzeichner neuer selbst signierter Zertifikate in Keystores ersetzen, die von WebSphere Application Server verwaltet werden. Der Austausch der Unterzeichner, der in der Laufzeit während der Einbindung und im Rahmen der Verwaltung stattfindet, bleibt erhalten. Weitere Informationen finden Sie im Artikel Überwachung des Zertifikatsablaufs in SSL.

Clients von WebSphere Application Server: Voraussetzungen für den Austausch der Sicherheitssignatur.

Wenn ein Knoten zum ersten Mal gestartet wird, wird ein neues verkettetes Zertifikat generiert. Clients benötigen die Stammunterzeichner für den Verbindungsaufbau, um das nötige Vertrauen zu gewährleisten. Die Einführung verketteter Zertifikate im aktuellen Release vereinfacht diesen Prozess. Anstatt den Unterzeichner eines selbst signierten Zertifikats mit kurzer Lebensdauer auszutauschen, können Sie den Stammunterzeichner mit langer Laufzeit austauschen. Dabei bleibt die Vertrauensbasis auch bei einer Erneuerung des persönlichen Zertifikats bestehen. Mit einer der folgenden Optionen können Sie auf die Unterzeichnerzertifikate verschiedener Knoten zugreifen, zu denen der Client eine Verbindung aufbauen muss. (Weitere Informationen hierzu enthält der Artikel Sichere Installation zum Abrufen des Clientunterzeichners in SSL.)
  • Durch eine Aufforderung zum Austausch von Unterzeichnern können Sie während einer Verbindung zu einem Server Unterzeichnerzertifikate importieren, die noch nicht in den Truststores enthalten sind. Diese Eingabeaufforderung ist für administrative Verbindungen standardmäßig aktiviert und kann für alle Client-SSL-Konfigurationen aktiviert werden. Ist diese Aufforderung aktiviert, werden bei jeder Verbindung zu einem Server, dessen Unterzeichner noch nicht vorhanden ist, der Unterzeichner des Servers sowie die Zertifikatinformationen und ein SHA-Digest (Secure Hash Algorithm) zur Prüfung vorgelegt. Der Benutzer kann entscheiden, ob er diese Berechtigungsnachweise akzeptiert. Wenn sie akzeptiert werden, wird der Unterzeichner zum Truststore des Clients hinzugefügt, wo er verbleibt, bis er explizit gelöscht wird. Die Aufforderung zum Austausch von Unterzeichnern wird nicht erneut angezeigt, wenn eine Verbindung zu demselben Server hergestellt wird, es sei denn, das persönliche Zertifikat hat sich geändert.
    Achtung: Sie sollten Ihr Vertrauen nicht allein auf die Aufforderung zum Austausch von Unterzeichnern aufbauen, sondern auch den SHA-Digest prüfen. Wenn ein Zertifikat nicht anerkannt wird, kann von einem Browser eine nicht geprüfte Eingabeaufforderung angezeigt werden.
  • Bevor Sie Verbindungen zu Servern herstellen, können Sie auf dem Client ein Verwaltungsscript retrieveSigners ausführen. Für das Herunterladen von Unterzeichnern benötigen Sie keine Administratorberechtigung. Diese ist nur für das Hochladen von Unterzeichnern erforderlich. Das Script lädt alle Unterzeichner aus dem Truststore eines angegebenen Servers in den benannten Client-Truststore. Es kann aber auch aufgerufen werden, um nur einen bestimmten Aliasnamen au einem Truststore herunterzuladen. Sie können das Script auch aufrufen, wenn Sie Unterzeichner in Server-Truststores hochladen möchten. Wenn Sie den Truststore CellDefaultTrustStore als angegebenen Server-Truststore und gemeinsamen Truststore für eine Zelle auswählen, werden alle Unterzeichner dieser Zelle in den angegebenen Client-Truststore (in der Regel ClientDefaultTrustStore) heruntergeladen. Weitere Informationen finden Sie im Artikel Befehl "retrieveSigners".
  • Den gemeinsamen Truststore "trust.p12", der sich im Zellenverzeichnis des Konfigurationsrepositorys befindet, können Sie physisch auf Clients verteilen. Dabei müssen Sie jedoch sicherstellen, dass in der Client-SSL-Konfigurationsdatei ssl.client.props das richtige Kennwort angegeben ist. Das Standardkennwort für diesen Truststore ist WebAS. Ändern Sie das Standardkennwort, bevor Sie den Truststore verteilen. Die physische Verteilung ist nicht so effektiv wie die davor beschriebenen Optionen. Wenn die persönlichen Zertifikate auf dem Server geändert werden, kann der automatisierte Austausch fehlschlagen.

Dynamische SSL-Konfigurationsänderungen

Die SSL-Laufzeitumgebung für WebSphere Application Server hält für die meisten SSL-Verbindungen Listener bereit. Wenn sich die SSL-Konfiguration ändert, erstellen die Listener für eingehende Verbindungen ein neues SSLContext-Objekt. Vorhandene Verbindungen verwenden weiter das aktuelle SSLContext-Objekt. Wird versucht, eine abgehende Verbindung aufzubauen, verwendet diese automatisch die neuen Konfigurationseigenschaften.

Dynamische Änderungen an der SSL-Konfiguration sollten Sie in Zeiten geringer Systemauslastung durchführen, damit Probleme durch zeitliche Verzögerungen vermieden werden und eine geringe Wahrscheinlichkeit besteht, dass der Server erneut gestartet wird. Wenn die Laufzeit so konfiguriert ist, dass sie dynamische Änderungen akzeptiert, modifizieren Sie die SSL-Konfiguration, und speichern Sie die Datei security.xml. Ihre Änderungen werden wirksam, wenn alle Knoten die neue Datei security.xml empfangen haben.

Anmerkung: Falls Konfigurationsänderungen zu einem Scheitern des SSL-Handshake führen, kann es auch zu Konnektivitätsunterbrechungen und Ausfallzeiten kommen. In einem solchen Fall müssen Sie die SSL-Verbindungen rekonfigurieren und den Fehler anschließend durch manuelle Knotensynchronisation beheben. Alle dynamischen Änderungen müssen sehr sorgfältig vorgenommen werden. Es wird dringend empfohlen, Änderungen an SSL-Konfigurationen zunächst in einer Testumgebung durchzuführen, bevor diese Änderungen auf ein Produktionssystem übertragen werden. Weitere Informationen finden Sie im Artikel Dynamische Konfigurationsaktualisieren in SSL.

Integrierte Zertifikatverwaltung

Die Keystore-Verwaltungsanzeigen der Administrationskonsole stellen jetzt Funktionen für die Zertifikatverwaltung bereit, die mit der Funktionalität von iKeyMan vergleichbar sind. Mit der integrierten Zertifikatverwaltung können Sie persönliche Zertifikate, Zertifikatsanforderungen und Unterzeichnerzertifikate in Keystores verwalten. Zusätzlich können Sie Keystores über Remote-Zugriff verwalten. Sie haben beispielsweise die Möglichkeit, vom Deployment Manager aus einen dateibasierten Keystore außerhalb des Konfigurationsrepositorys auf einem beliebigen Knoten zu verwalten. Vom Deployment Manager aus können Sie über Remote-Zugriff auch Keystores für Hardwareverschlüsselung verwalten.

Mit der integrierten Zertifikatverwaltung können Sie ein verkettetes oder selbst signiertes Zertifikat und alle auf die verschiedenen Truststores verteilten Unterzeichnerzertifikate ersetzen und von einem fernen Port einen Unterzeichner abrufen. Dazu müssen Sie eine Verbindung zum fernen SSL-Host und Port herstellen und den Unterzeichner während des Handshakes abfangen. Zunächst wird das Zertifikat anhand des Zertifikat-SHA-Digest validiert. Anschließend muss der Administrator das validierte Zertifikat akzeptieren. Erst dann kann es in einen Truststore gestellt werden.

Wenn Sie ein Zertifikat anfordern, können Sie die Anforderung an eine Zertifizierungsstelle (CA, Certificate Authority) senden. Wird das Zertifikat gesendet, können Sie es in der Administrationskonsole empfangen. Weitere Informationen finden Sie im Artikel Zertifikatsmanagement in SSL.
Tipp: Die iKeyMan-Funktionen gehören nach wie vor zum Lieferumfang von WebSphere Application Server. Dennoch sollten Sie Keystores mit den integrierten Funktionen für Zertifikatverwaltung in der Administrationskonsole konfigurieren. Die Verwendung von iKeyMan sollte auf Fälle beschränkt bleiben, in denen die Nutzung der Administrationskonsole nicht erwünscht ist. Weitere Informationen finden Sie im Artikel Zertifikatsmanagement mit iKeyman vor SSL.

Konfigurationsverwaltung mit AdminTask

Die Verwaltungsanzeigen für SSL-Konfigurationen in der Administrationskonsole greifen in erster Linie auf Verwaltungstasks zurück, die zur Unterstützung der Administrationskonsole beibehalten und erweitert werden. Wenn Sie die Verwaltung von Keystores, SSL-Konfigurationen, Zertifikaten etc. automatisieren möchten, können Sie an der Eingabeaufforderung einer Java-Konsole wsadmin-Befehle absetzen.

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_sslsecurecom
Dateiname:csec_sslsecurecom.html