[16.0.0.3 und höher]

Verbünde mit Zertifikaten anderer Anbieter einrichten

SSL schützt die Kommunikation zwischen Controllern und Membern. Jeder Server in einem Verbund hat eine eigene Identität, die sich aus seinem Hostnamen, seinem Benutzerverzeichnis und seinem Servernamen zusammensetzt. Jeder Server in einem Verbund hat zwei Keystores, die standardmäßig die Namen serverIdentity.jks und collectiveTrust.jks haben. Der Keystore enthält die SSL-Zertifikate, die benötigt werden, um die Identität des Servers zu deklarieren und um eine sichere Kommunikation mit anderen Membern und Controllern innerhalb des Verbunds einzurichten. Damit eine Anwendung eine eingehende HTTPS-Verbindung herstellen kann, hat jeder Server zwei weitere Keystores, die standardmäßig die Namen key.jks und trust.jks haben.

Vorbereitende Schritte

Sie müssen den Liberty-Verbund erstellen. Weitere Informationen finden Sie unter Liberty-Verbund konfigurieren und Verbundsicherheit in der Produktdokumentation.

Zum Herstellen der sicheren SSL-Verbindung zwischen dem Verbundcontroller und dem Verbundmember wird vom Verbunddienstprogramm ein Satz von SSL-Zertifikaten erstellt. Die DNs (Distinguished Name) der Zertifikate enthalten entweder die Angabe OU=controllerRoot oder OU=memberRoot, je nachdem, ob das Zertifikat vom Verbundcontroller oder vom Verbundmember verwendet wird. Sie werden den entsprechenden Keystores des Controllers bzw. Verbunds hinzugefügt. Diese Zertifikate stellen sicher, dass die sichere SSL-Verbindung zwischen den verschiedenen Bestandteilen eines Verbunds hergestellt wird.

Sie können von einer unabhängigen Zertifizierungsstelle signierte SSL-Zertifikate verwenden, um zwischen den verschiedenen Liberty-Servern eines Verbunds dieselbe sichere SSL-Verbindung herzustellen.

rootkeys.jks
Der Keystore ist nur auf der Seite des Verbundcontrollers vorhanden und enthält zwei selbst signierte persönliche Zertifikate mit den Aliasnamen controllerroot und memberroot. Das System verwendet diese Zertifikate, um die persönlichen Zertifikate des Verbundcontrollers und die persönlichen Zertifikate der Verbund-Member zu signieren.
Tipp: Nachdem Sie den Controller erstellt haben, können Sie optional die Zertifikate im Keystore "rootkeys.jks" durch Ihre eigenen Zertifikate ersetzen, die von einer Zertifizierungsstelle unterzeichnet wurden.
serverIdentity.jks
Der Keystore enthält persönliche Zertifikate des Controllers auf Controllerseite und persönliche Zertifikate des Members auf der Memberseite und er wird automatisch während der Erstellung des Verbunds erstellt. Standardmäßig wird das persönliche Zertifikat des Controllers von controllerroot und das persönliche Zertifikat des Members von memberroot in der Datei rootKeys.jks unterzeichnet.
collectiveTrust.jks
Der Truststore enthält Unterzeichnerzertifikate, mit denen die persönlichen Zertifikate von Controller und Membern signiert wurden, z. B. controllerroot und memberroot.
key.jks
Der Keystore enthält persönliche Zertifikate des Controllers auf Controllerseite und persönliche Zertifikate des Members auf der Memberseite und er wird automatisch während der Erstellung des Verbunds erstellt. Standardmäßig wird das persönliche Zertifikat des Controllers von controllerroot und das persönliche Zertifikat des Members von memberroot signiert.
trust.jks
Der Truststore enthält Unterzeichnerzertifikate, mit denen die persönlichen Zertifikate von Controller und Membern signiert wurden, z. B. controllerroot und memberroot.

In der folgenden Abbildung werden die Controller- und Memberzertifikate gezeigt:

Abbildung, in der die anderen Keystores gezeigt werden.

Informationen zu diesem Vorgang

Konfigurieren und ändern Sie das Verbundsetup so, dass SSL-Zertifikate verwendet werden können, die von einer unabhängigen Zertifizierungsstelle signiert werden. Fügen Sie der Datei "server.xml" neue Konfigurationseinträge für die Unterstützung von SSL-Zertifikaten hinzu, die von einer unabhängigen Zertifizierungsstelle signiert werden. Diese Konfiguration wird verwendet, um die Zertifikate zu identifizieren, die für Verbundoperationen verwendet werden, wenn diese vom Standard abweichen.

Ihre Konfiguration enthält folgenden Eintrag:
<collectiveCertificate rdn="name=value"></collectiveCertificate>.
Name
Ein beliebiger Attributname im definierten Namen des Zertifikats.
Wert
Der rdn-Attributwert im definierten Namen.
Angenommen, der definierte Name Ihres Zertifikats wird als DN: CN=companyName,OU=WebSphere,O=IBM, EMAIL=abcd@xyz.com angezeigt und Sie möchten alle Zertifikate mit EMAIL=abcd@xyz.com als Verbundzertifikate identifizieren. In diesem Fall verwenden Sie die folgende Konfiguration:
<collectiveCertificate rdn="EMAIL=abcd@xyz.com"></collectiveCertificate>

Vorgehensweise

  1. Zertifikate anderer Anbieter beim Erstellen eines neuen Verbunds konfigurieren
  2. Zertifikate anderer Anbieter für einen vorhandenen Verbund konfigurieren

Symbol das den Typ des Artikels anzeigt. Taskartikel

Dateiname: tagt_wlp_config_collective_3rd_party_cert.html