SSL-Zertifikate erstellen und installieren

Die folgenden Abschnitte beschreiben, wie Sie SSL-Zertifikate zur Verwendung mit WebSphere Partner Gateway erstellen und installieren. Außerdem ist eine Übersicht des SSL-Handshake-Prozesses enthalten. Wenn Ihre Community SSL nicht verwendet, benötigen weder Sie noch Ihre Teilnehmer ein eingehendes oder ausgehendes SSL-Zertifikat.

SSL-Handshake

Jede SSL-Sitzung beginnt mit einem Handshake.

Wenn ein Client (der Teilnehmer oder Community Manager) einen Nachrichtenaustausch initiiert, treten folgende Schritte auf:

  1. Der Client sendet eine Clientnachricht "hello", die die verschlüsselten Funktionen des Clients (sortiert in der vom Client bevorzugten Reihenfolge) auflistet, wie z. B. die Version von SSL, die vom Client unterstützten Cipher Suites und die vom Client unterstützten Datenkomprimierungsmethoden. Die Nachricht enthält außerdem eine 28-Byte-Zufallszahl.
  2. Der Server antwortet mit einer Servernachricht "hello done" (erledigt), die die verschlüsselte Methode (Cipher Suite) und die vom Server ausgewählte Datenkomprimierungsmethode, die Sitzungs-ID und eine weitere Zufallszahl enthält.
    Anmerkung: Der Client und der Server müssen mindestens eine gemeinsame Cipher Suite unterstützen, ansonsten schlägt der Handshake fehl. Der Server wählt im Allgemeinen die stärkste gemeinsame Cipher Suite aus.
  3. Der Server sendet sein digitales Zertifikat.

    Serverauthentifizierung geschieht in diesem Schritt.

  4. Der Server sendet eine Nachricht "digital certificate request" (Anforderung für digitales Zertifikat). In der Nachricht "digital certificate request" sendet der Server eine Liste mit den unterstützten digitalen Zertifikattypen und die definierten Namen von akzeptablen Zertifizierungsstellen.
  5. Der Server sendet eine Servernachricht "hello done" und wartet auf die Clientantwort.
  6. Nach Empfang der Servernachricht "hello done" prüft der Client die Gültigkeit des digitalen Zertifikats vom Server und überprüft, ob die Serverparameter für "hello" akzeptabel sind.
  7. Wenn der Server ein digitales Zertifikat vom Client angefordert hat, sendet der Client ein digitales Zertifikat oder falls kein passendes digitales Zertifikat verfügbar ist, sendet der Client einen Alert "no digital certificate" (kein digitales Zertifikat). Dieser Alert ist nur eine Warnung, aber die Serveranwendung kann in der Sitzung fehlschlagen, wenn die Clientauthentifizierung obligatorisch ist.
  8. Der Client sendet eine Nachricht "client key exchange" (Clientschlüsselaustausch). Diese Nachricht enthält einen geheimen Pre-Master-Secret-Wert (Pre-Master Secret), eine 46-Byte-Zufallszahl, die bei der Generierung der symmetrischen Verschlüsselungsschlüssel und der MAC-Schlüssel (MAC - Message Authentication Code - Nachrichtenauthentifizierungscode) verwendet wird, welche mit dem öffentlichen Schlüssel des Servers verschlüsselt sind.
  9. Wenn der Client ein digitales Zertifikat an den Server sendet, sendet der Client eine Nachricht "digital certificate verify" (digitales Zertifikat prüfen), die mit dem privaten Schlüssel des Clients unterzeichnet ist. Indem der Server die Unterschrift dieser Nachricht prüft, kann er explizit das Eigentumsrecht des digitalen Zertifikats vom Client prüfen.
    Anmerkung: Ein zusätzlicher Prozess, um das digitale Zertifikat vom Server zu prüfen, ist nicht notwendig. Wenn der Server nicht über den privaten Schlüssel verfügt, der zum digitalen Zertifikat gehört, kann er den Pre-Master Secret nicht entschlüsseln und die richtigen Schlüssel für den symmetrischen Verschlüsselungsalgorithmus nicht erstellen und der Handshake schlägt fehl.
  10. Der Client verwendet eine Reihe von verschlüsselten Operationen, um den geheimen Pre-Master-Secret-Wert in einen geheimen Master-Secret-Wert zu konvertieren, von dem alles Schlüsselmaterial abgeleitet wird, das zur Verschlüsselung und Nachrichtenauthentifizierung erforderlich ist. Der Client sendet dann eine Nachricht "change cipher spec" (Verschlüsselungsspezi- fikation ändern), damit der Server zur neu festgelegten Cipher Suite wechselt. Die nächste vom Client gesendete Nachricht "finished" (fertig) ist die erste Nachricht, die mit dieser Verschlüsselungsmethode und den Verschlüsselungsschlüsseln verschlüsselt ist.
  11. Der Server antwortet mit einer Nachricht "change cipher spec" und einer eigenen Nachricht "finished".

Die Clientauthentifizierung erfordert die Schritte 4, 7 und 9.

Der SSL-Handshake wird beendet und die verschlüsselten Anwendungsdaten können gesendet werden.

Eingehende SSL-Zertifikate

Dieser Abschnitt beschreibt, wie Sie die Serverauthentifizierung und die Clientauthentifizierung für eingehende Verbindungsanforderungen von Teilnehmern konfigurieren.

Serverauthentifizierung

WebSphere Application Server verwendet das SSL-Zertifikat, wenn er Verbindungsanforderungen von Teilnehmern über SSL empfängt. Es ist das Zertifikat, das der Empfänger präsentiert, um dem Teilnehmer den Hub anzugeben. Dieses Serverzertifikat kann selbst unterzeichnet oder von einer Zertifizierungsstelle (CA) unterzeichnet sein. In den meisten Fällen verwenden Sie ein CA-Zertifikat, um die Sicherheit zu erhöhen. Sie könnten ein selbst unterzeichnetes Zertifikat in einer Testumgebung verwenden. Verwenden Sie iKeyman, um ein Zertifikat und ein Schlüsselpaar zu generieren. Weitere Informationen entnehmen Sie der von IBM verfügbaren Dokumentation zur Verwendung von iKeyman.

Nachdem Sie das Zertifikat und das Schlüsselpaar generiert haben, verwenden Sie das Zertifikat für den eingehenden SSL-Datenverkehr aller Teilnehmer. Wenn Sie über mehrere Empfänger oder Konsolen verfügen, kopieren Sie den generierten Keystore auf jede Instanz. Wenn das Zertifikat selbst unterzeichnet ist, stellen Sie dieses Zertifikat den Teilnehmern zur Verfügung. Um dieses Zertifikat zu erhalten, extrahieren Sie mit iKeyman das öffentliche Zertifikat in eine Datei.

Selbst unterzeichnetes Zertifikat verwenden

Wenn Sie selbst unterzeichnete Serverzertifikate verwenden, führen Sie die folgende Prozedur aus.

  1. Starten Sie das Dienstprogramm iKeyman, welches sich in /<Produktverz>/was/bin befindet. Wenn Sie iKeyman zum ersten Mal verwenden, löschen Sie das Zertifikat "dummy", das sich im Keystore befindet.
  2. Generieren Sie mit iKeyman ein selbst unterzeichnetes Zertifikat und ein Schlüsselpaar für den Keystore des Empfängers bzw. der Konsole.
  3. Extrahieren Sie mit iKeyman das Zertifikat in eine Datei, das Ihren öffentlichen Schlüssel enthalten wird.

    Speichern Sie den Keystore in einer JKS-, PKCS12- oder JCEK-Datei.

  4. Installieren Sie die Datei in den Keystore des Empfängers bzw. der Konsole, für den sie erstellt worden ist.
  5. Verteilen Sie das Zertifikat an Ihre Teilnehmer. Die bevorzugte Verteilungsmethode ist das Senden des Zertifikats in einer kennwortgeschützten komprimierten Datei per E-Mail. Ihre Teilnehmer müssen sich an Sie wenden und das Kennwort für die komprimierte Datei anfordern.
Von Zertifizierungsstelle generiertes Zertifikat verwenden

Wenn Sie ein von einer Zertifizierungsstelle (CA) unterzeichnetes Zertifikat verwenden, führen Sie die folgende Prozedur aus.

  1. Starten Sie das Dienstprogramm iKeyman, welches sich im Verzeichnis /<Produktverz>/was/bin befindet.
  2. Generieren Sie mit iKeyman eine Zertifikatsanforderung und ein Schlüsselpaar für den Empfänger.
  3. Übergeben Sie eine Zertifikatsunterzeichungsanforderung (CSR - Certificate Signing Request) an eine Zertifizierungsstelle.
  4. Wenn Sie das unterzeichnete Zertifikat von der Zertifizierungsstelle empfangen, stellen Sie das unterzeichnete Zertifikat mit iKeyman in den Keystore.
  5. Verteilen Sie das CA-Zertifikat an alle Teilnehmer.

Clientauthentifizierung

Wenn Sie Teilnehmer authentifizieren wollen, die Dokumente senden, führen Sie die Schritte in diesem Abschnitt aus.

Das Clientzertifikat installieren

Verwenden Sie für die Clientauthentifizierung die folgende Prozedur:

  1. Rufen Sie das Zertifikat Ihres Teilnehmers ab.
  2. Installieren Sie das Zertifikat bzw. die Zertifikate mit iKeyman in den Truststore.
  3. Stellen Sie die zugehörige Zertifizierungsstelle bzw. die zugehörigen Zertifizierungsstellen in den zugehörigen Keystore.

Anmerkung: Wenn Sie mehrere Teilnehmer Ihrer Hub-Community hinzufügen, können Sie mit iKeyman ihre Zertifikate dem Truststore hinzufügen. Wenn ein Teilnehmer die Community verlässt, können Sie mit iKeyman die Zertifikate des Teilnehmers aus dem Truststore entfernen.
Clientauthentifizierung konfigurieren

Nachdem Sie das Zertifikat bzw. die Zertifikate installiert haben, konfigurieren Sie WebSphere Application Server für die Verwendung der Clientauthentifizierung, indem Sie das Dienstprogrammscript bcgClientAuth.jacl ausführen.

  1. Navigieren Sie zum folgenden Verzeichnis: /<Produktverz>/bin
  2. Zum Aktivieren der Clientauthentifizierung rufen Sie das Script wie folgt auf:
    ./bcgwsadmin.sh -f /<Produktverz>/scripts/bcgClientAuth.jacl
        -conntype NONE set 
    Anmerkung: Zum Inaktivieren der Clientauthentifizierung rufen Sie das Script wie folgt auf:
    ./bcgwsadmin.sh -f /<Produktverz>/receiver/scripts/bcgClientAuth.jacl
       -conntype NONE clear

Sie müssen den Server bcgreceiver erneut starten, damit diese Änderungen wirksam werden.

Das Clientzertifikat prüfen

Es gibt eine Zusatzfunktion, die mit der SSL-Clientauthentifizierung verwendet werden kann. Diese Funktion wird über Community Console aktiviert. Für HTTPS überprüft WebSphere Partner Gateway Zertifikate anhand der Geschäfts-IDs in den eingehenden Dokumenten. Zur Verwendung dieser Funktion erstellen Sie das Teilnehmerprofil, importieren das Clientzertifikat und markieren es als SSL.

  1. Importieren Sie das Clientzertifikat.
    1. Klicken Sie auf Kontenadmin > Profile > Community-Teilnehmer, und suchen Sie nach dem Profil des Teilnehmers.
    2. Klicken Sie auf Zertifikate.
    3. Klicken Sie auf Zertifikat laden.
    4. Wählen Sie SSL-Client als Zertifikattyp aus.
    5. Geben Sie eine Beschreibung des Zertifikats ein, welches erforderlich ist.
    6. Ändern Sie den Status in Aktiviert.
    7. Klicken Sie auf Durchsuchen, und navigieren Sie zum Verzeichnis, in dem Sie das Zertifikat gespeichert haben.
    8. Wählen Sie das Zertifikat aus, und klicken Sie auf Öffnen.
    9. Wenn Sie einen anderen Gateway-Typ als Produktion (die Standardeinstellung) auswählen wollen, wählen Sie ihn in der Liste aus.
    10. Klicken Sie auf Hochladen und dann auf Speichern.
  2. Aktualisieren Sie das Clientgateway.
    1. Klicken Sie auf Kontenadmin > Profile > Community-Teilnehmer, und suchen Sie nach dem Profil des Teilnehmers.
    2. Klicken Sie auf Gateways.
    3. Wählen Sie das HTTPS-Gateway aus, das Sie vorher erstellt haben. Wenn Sie das HTTPS-Gateway noch nicht erstellt haben, lesen Sie HTTPS-Gateway konfigurieren.
    4. Klicken Sie auf das Symbol Bearbeiten, um das Gateway zu bearbeiten.
    5. Wählen Sie Ja für Client-SSL-Zertifikat prüfen aus.
    6. Klicken Sie auf Speichern.

Ausgehende SSL-Zertifikate

Wenn Ihre Community SSL nicht verwendet, benötigen Sie kein eingehendes oder ausgehendes SSL-Zertifikat.

Serverauthentifizierung

Wenn SSL zum Senden der ausgehenden Dokumente an Ihre Teilnehmer verwendet wird, fordert WebSphere Partner Gateway ein serverseitiges Zertifikat von den Teilnehmern an. Dasselbe CA-Zertifikat kann für mehrere Teilnehmer verwendet werden. Das Zertifikat muss in X.509-DER-Format sein.

Anmerkung: Sie können das Format mit dem Dienstprogramm iKeyman konvertieren. Befolgen Sie diese Schritte, um das Format zu konvertieren:
  1. Starten Sie das Dienstprogramm iKeyman.
  2. Erstellen Sie einen neuen leeren Keystore, oder öffnen Sie einen vorhandenen Keystore.
  3. Wählen Sie in Key Database Content die Option Signer Certificates aus.
  4. Fügen Sie das ARM-Zertifikat mit der Option Add hinzu.
  5. Extrahieren Sie dasselbe Zertifikat als Binary-DER-Daten mit der Option Extract.
  6. Schließen Sie das Dienstprogramm iKeyman.

Installieren Sie das selbst unterzeichnete Zertifikat des Teilnehmers in das Profil des Hub-Operators. Wenn das Zertifikat von einer Zertifizierungsstelle unterzeichnet wurde und das Rootzertifikat der Zertifizierungsstelle und alle anderen Zertifikate, die Teil der Zertifikatkette sind, noch nicht im Profil des Hub-Operators installiert sind, installieren Sie die Zertifikate jetzt im Profil des Hub-Operators.

  1. Klicken Sie auf Zertifikate.
  2. Klicken Sie auf Zertifikat laden.
  3. Wählen Sie Root und Intermediate als Zertifikattyp aus.
  4. Geben Sie eine Beschreibung des Zertifikats ein, welches erforderlich ist.
  5. Ändern Sie den Status in Aktiviert.
  6. Klicken Sie auf Durchsuchen, und navigieren Sie zum Verzeichnis, in dem Sie das Zertifikat gespeichert haben.
  7. Wählen Sie das Zertifikat aus, und klicken Sie auf Öffnen.
  8. Klicken Sie auf Hochladen und dann auf Speichern.

Anmerkung: Sie müssen die vorherigen Schritte nicht ausführen, wenn das Zertifikat der Zertifizierungsstelle bereits installiert ist.

Clientauthentifizierung

Wenn SSL-Clientauthentifizierung erforderlich ist, wird der Teilnehmer seinerseits ein Zertifikat vom Hub anfordern. Importieren Sie mit Community Console Ihr Zertifikat in WebSphere Partner Gateway. Sie können das Zertifikat mit iKeyman generieren. Wenn das Zertifikat ein selbst unterzeichnetes Zertifikat ist, muss es dem Teilnehmer zur Verfügung gestellt werden. Wenn es ein CA-unterzeichnetes Zertifikat ist, muss das CA-Rootzertifikat den Teilnehmern gegeben werden, so dass sie es ihren vertrauenswürdigen Zertifikaten hinzufügen können.

Sie können über mehr als ein SSL-Zertifikat verfügen. Eines ist das primäre Zertifikat, welches standardmäßig verwendet wird. Das andere Zertifikat ist das sekundäre Zertifikat, welches verwendet wird, wenn das primäre Zertifikat abgelaufen ist oder andernfalls nicht verwendet werden kann.

Selbst unterzeichnetes Zertifikat verwenden

Wenn Sie ein selbst unterzeichnetes Zertifikat verwenden, führen Sie die folgende Prozedur aus.

  1. Starten Sie das Dienstprogramm iKeyman.
  2. Verwenden Sie iKeyman, um ein selbst unterzeichnetes Zertifikat und ein Schlüsselpaar zu generieren.
  3. Extrahieren Sie mit iKeyman das Zertifikat in eine Datei, das Ihren öffentlichen Schlüssel enthalten wird.
  4. Verteilen Sie das Zertifikat an Ihre Teilnehmer. Die bevorzugte Verteilungsmethode ist das Senden des Zertifikats in einer kennwortgeschützten komprimierten Datei per E-Mail. Ihre Teilnehmer müssen sich an Sie wenden und das Kennwort für die komprimierte Datei anfordern.
  5. Verwenden Sie iKeyman, um das selbst unterzeichnete Zertifikat und das private Schlüsselpaar in Form einer PKCS12-Datei zu exportieren.
  6. Installieren Sie das selbst unterzeichnete Zertifikat und den Schlüssel über Community Console.
    1. Klicken Sie auf Kontenadmin > Profile > Zertifikate, um die Seite Zertifikatliste anzuzeigen.

      Stellen Sie sicher, dass Sie an Community Console als Hub-Operator angemeldet sind.

    2. Klicken Sie auf PKCS12 laden.
      Anmerkung: Die PKCS12-Datei, die hochgeladen wird, sollte nur einen privaten Schlüssel und das zugeordnete Zertifikat enthalten.
    3. Wählen Sie SSL-Client als Zertifikattyp aus.
    4. Geben Sie eine Beschreibung des Zertifikats ein, welches erforderlich ist.
    5. Ändern Sie den Status in Aktiviert.
    6. Klicken Sie auf Durchsuchen, und navigieren Sie zum Verzeichnis, in dem Sie das Zertifikat gespeichert haben.
    7. Wählen Sie das Zertifikat aus, und klicken Sie auf Öffnen.
    8. Geben Sie das Kennwort ein.
    9. Wenn Sie einen anderen Gateway-Typ als Produktion (die Standardeinstellung) auswählen wollen, wählen Sie ihn in der Liste aus.
    10. Wenn Sie über zwei SSL-Zertifikate verfügen, geben Sie an, welches von ihnen das primäre bzw. das sekundäre Zertifikat ist, indem Sie Primär oder Sekundär in der Liste Zertifikatverwendung auswählen.
    11. Klicken Sie auf Hochladen und dann auf Speichern.

Wenn Sie primäre und sekundäre Zertifikate für die SSL-Clientauthentifizierung und die digitale Unterschrift hochladen, und Sie die primären Zertifikate als zwei separate Einträge hochladen, stellen Sie sicher, dass die entsprechenden sekundären Zertifikate als zwei unterschiedliche Einträge hochgeladen werden.

Von Zertifizierungsstelle unterzeichnetes Zertifikat verwenden

Wenn Sie ein von einer Zertifizierungsstelle unterzeichnetes Zertifikat verwenden, führen Sie die folgende Prozedur aus:

  1. Generieren Sie mit iKeyman eine Zertifikatsanforderung und ein Schlüsselpaar für den Empfänger.
  2. Übergeben Sie eine Zertifikatsunterzeichungsanforderung (CSR - Certificate Signing Request) an eine Zertifizierungsstelle.
  3. Wenn Sie das unterzeichnete Zertifikat von der Zertifizierungsstelle empfangen, stellen Sie das unterzeichnete Zertifikat mit iKeyman in den Keystore.
  4. Verteilen Sie das unterzeichnende CA-Zertifikat an alle Teilnehmer.

Zertifikatswiderrufsliste hinzufügen

WebSphere Partner Gateway enthält eine CRL-Funktion (CRL - Certificate Revocation List - Zertifikatswiderrufsliste). Die CRL, die von einer Zertifizierungsstelle herausgegeben wird, gibt Teilnehmer an, die Zertifikate vor ihrem terminierten Ablaufdatum widerrufen haben. Teilnehmern mit widerrufenen Zertifikaten wird der Zugriff auf WebSphere Partner Gateway verweigert.

Jedes widerrufene Zertifikat wird in einer CRL durch seine fortlaufende Zertifikatsnummer angegeben. Document Manager durchsucht die CRL alle 60 Sekunden und lehnt ein Zertifikat ab, wenn es in der CRL-Liste enthalten ist.

CRLs werden an der folgenden Position gespeichert: /<gemeinsames_datenverzeichnis>/security/crl. WebSphere Partner Gateway verwendet die Einstellung bcg.CRLDir in der Datei bcg.properties, um die Position des CRL-Verzeichnisses anzugeben.

Erstellen Sie eine .crl-Datei, die die widerrufenen Zertifikate enthält, und stellen Sie diese in das CRL-Verzeichnis.

In der Datei bcg.properties würden Sie z. B. die folgende Einstellung verwenden:

bcg.CRLDir=/<gemeinsames_datenverzeichnis>/security/crl

Zugriff auf CRL-Verteilungspunkte aktivieren

Zertifizierungsstellen verwalten und aktualisieren die Zertifikatswiderrufslisten (CRLs). Diese Zertifikatswiderrufslisten werden normalerweise an einem CRL-Verteilungspunkt gespeichert. Zertifikatswiderrufslisten werden während der Widerrufsüberprüfungen für die Zertifikate verwendet, um zu ermitteln, ob das Zertifikat widerrufen wurde.

Das Script bcgSetCRLDP.jacl kann verwendet werden, um die CRL-Verteilungspunktüberprüfung zu aktivieren bzw. zu inaktivieren, wenn die Widerrufsüberprüfung ausgeführt wird. Falls Sie auf die CRL-Verteilungspunkte zugreifen müssen, wenn die Widerrufsüberprüfung eines Zertifikats ausgeführt wird, aktivieren Sie die Verwendung von CRL-Verteilungspunkten. Wenn die Zertifikate, die Sie installiert haben, eine CRL DP-Erweiterung enthalten, können Sie die Verwendung von CRL-Verteilungspunkten aktivieren, so dass auf die Verteilungspunkte zugegriffen wird, wenn die Widerrufsüberprüfung ausgeführt wird. Wenn Sie alle erforderlichen Zertifikatswiderrufslisten in das Verzeichnis heruntergeladen haben, das in bcg.properties für das Merkmal bcg.CRLDir festgelegt ist, wollen Sie unter Umständen die Verwendung von CRL-Verteilungspunkten nicht aktivieren. Falls die aktuellen Zertifikatswiderrufslisten sehr wahrscheinlich nicht im Verzeichnis bcg.CRLDir verfügbar sind, sollten Sie die Verwendung von CRL-Verteilungspunkten aktivieren.

Die CRL-Verteilungspunkte, auf die über HTTP und LDAP zugegriffen werden kann, werden unterstützt. Sie können auch Proxy-Server für den Zugriff auf die CRL-Verteilungspunkte konfigurieren.

Anmerkung: Verwenden Sie für Windows-Installationen bcgwsadmin.bat anstelle von ./bcgwsadmin.sh in den Befehlen, die in diesem Abschnitt aufgelistet werden.

Führen Sie den folgenden Befehl vom Verzeichnis <Produktverz>/bin aus, um die Verwendung von CRL-Verteilungspunkten zu aktivieren:

./bcgwsadmin.sh -f <Produktverz>/scripts/bcgSetCRLDP.jacl install
  <knotenname> <servername> CRLDP

Dabei gilt Folgendes:

<serverstammverzeichnis>
Das Stammverzeichnis des Servers, z. B. /opt/ibm/receiver/was/profiles/bcgreceiver.
<servername>
Kann bcgdocmgr, bcgreceiver oder bcgconsole sein. Der Befehl muss vom entsprechenden <serverstammverzeichnis> ausgeführt werden.

Führen Sie den folgenden Befehl vom Verzeichnis <Produktverz>/bin aus, um die Verwendung von CRL-Verteilungspunkten zu inaktivieren:

./bcgwsadmin.sh -f <Produktverz>/scripts/bcgSetCRLDP.jacl uninstall
  <knotenname> <servername> CRLDP

Führen Sie den folgenden Befehl vom Verzeichnis <Produktverz>/bin aus, um die Verwendung von CRL-Verteilungspunkten mit einem Proxy-Server zu aktivieren:

./bcgwsadmin.sh -f <Produktverz>/scripts/bcgSetCRLDP.jacl install
  <knotenname> <servername> CRLDP <proxy-host> <proxy-port>

Führen Sie den folgenden Befehl vom Verzeichnis <Produktverz>/bin aus, um anzugeben, dass Sie keinen Proxy-Server verwenden wollen:

./bcgwsadmin.sh -f <Produktverz>/scripts/bcgSetCRLDP.jacl
  uninstall <knotenname> <servername> PROXY

Wenn Sie einen Empfängerbenutzerexit verwenden, und wenn der Benutzerexit die SecurityService-API verwendet, können die obigen Einstellungen auch auf den Server bcgreceiver angewendet werden. Zum Ausführen der obigen Befehle für den Empfänger, ersetzen Sie bcgdocmgr durch bcgreceiver.

Copyright IBM Corp. 2003, 2005