SSL-Fehler zur Sicherheit

Dieser Artikel beschreibt verschiedene Probleme, die nach dem Konfigurieren oder Aktivieren von Secure Sockets Layer (SSL) auftreten können. Es kann sein, dass Sie den Deployment Manager nach der Konfiguration von SSL nicht mehr stoppen können. Möglicherweise können Sie nicht mehr mit HTTPS auf Ressourcen zugreifen. Es besteht auch die Möglichkeit, dass der Client und der Server nicht die richtige Sicherheitsstufe vereinbaren können. Die hier aufgeführten Probleme stellen lediglich eine Auswahl dar. Die Lösung dieser Probleme ist für den Betrieb von WebSphere Application Server unbedingt erforderlich.

Welches Problem liegt vor?

Deployment Manager nach dem Konfigurieren von Secure Sockets Layer stoppen

Wenn Sie nach dem Konfigurieren der SSL-Repertoires den Deployment Manager stoppen, ohne die Node Agents zu stoppen, kann beim erneuten Starten des Deployment Manager die folgende Fehlernachricht angezeigt werden:

CWWMU0509I: Der Server "nodeagent" kann nicht erreicht werden. Er scheint gestoppt zu sein.
CWWMU0211I: Einzelheiten zu dem Fehler finden Sie in der folgenden Datei:
           /opt/WebSphere/AppServer/logs/nodeagent/stopServer.log

Dieser Fehler tritt auf, weil der Deployment Manager das neue SSL-Zertifikat nicht an die Node Agents weitergegeben hat. Die Node Agents verwenden also eine ältere Zertifikatdatei als der Deployment Manager, und deshalb sind die Zertifikatdateien nicht kompatibel. Zur Vermeidung dieses Fehlers müssen Sie die Node-Agent- und Deployment-Manager-Prozesse stoppen.

[Windows]Verwenden Sie zum Beenden der Prozesse den Task-Manager.

[AIX HP-UX Solaris]Führen Sie den Befehl zum Beenden des Prozesses aus.

[z/OS]Verwenden Sie zum Beenden der Prozesse auf der Plattform z/OS die MVS-Konsole, und geben Sie c Prozessname ein.

[AIX Solaris HP-UX Linux Windows][z/OS]Sie müssen bestimmte Faktoren beachten, wenn Sie den zu stoppenden Prozess angeben. WebSphere Application Server speichert für jeden Prozess, der gestoppt wird, die Prozess-ID in einer pid-Datei. Sie müssen also diese *.pid-Dateien suchen. Beispielsweise könnte die Datei server1.pid für eine eigenständige Installation im Pfad Installationsstammverzeichnis/logs/server1.pid enthalten sein.

[IBM i]Sie müssen bestimmte Faktoren beachten, wenn Sie den zu stoppenden Prozess angeben. WebSphere Application Server speichert für jeden Prozess, der gestoppt wird, die Prozess-ID in einer pid-Datei. Sie müssen also diese *.pid-Dateien suchen. Beispielsweise könnte die Datei server1.pid für eine eigenständige Installation im Pfad Stammverzeichnis_des_Anwendungsservers/logs/server1.pid enthalten sein.

[AIX Solaris HP-UX Linux Windows][z/OS]

Mit HTTPS auf Ressourcen zugreifen

Wenn Sie mit SSL-URLs (beginnen mit https:) nicht auf Ressourcen zugreifen können oder Fehlernachrichten angezeigt werden, die auf SSL-Probleme hinweisen, müssen Sie prüfen, ob Ihr HTTP-Server korrekt für SSL konfiguriert ist. Rufen Sie die Begrüßungsseite des HTTP-Server über SSL mit dem folgenden URL auf: https://Hostname.

Wenn die Seite mit HTTP, nicht jedoch mit HTTPS aufgerufen werden kann, liegt ein Fehler des HTTP-Servers vor.
  • Die Dokumentation zum HTTP-Server enthält Anweisungen zur Aktivierung von SSL. Wenn Sie IBM® HTTP Server oder Apache verwenden, rufen Sie die Webseite http://www.ibm.com/software/webservers/httpservers/library.html auf. Klicken Sie auf Frequently Asked Questions > SSL.
  • Verwenden Sie das Tool IBM Key Management (IKeyman), um Zertifikate und Schlüssel zu erstellen. Denken Sie daran, das Kennwort in eine Stash-Datei zu stellen, wenn Sie die KDB-Datei (Key Database, Schlüsseldatenbank) mit dem Tool IBM Key Management erstellen.
    1. Wechseln Sie in das Verzeichnis, in dem die KDB-Datei erstellt wurde, und stellen Sie fest, ob eine Datei mit der Erweiterung .sth vorhanden ist.
    2. Wenn dies nicht der Fall ist, gehen Sie wie folgt vor: Öffnen Sie die KDB-Datei mit dem Tool IBM Key Management, und wählen Sie Schlüsseldatenbankdatei > Stash-Kennwort aus. Eine Nachricht wie Das Kennwort wurde verschlüsselt und in der Datei gespeichert erscheint.

Wenn der HTTP-Server SSL-verschlüsselte Anforderungen ordnungsgemäß verarbeitet oder nicht an der Verarbeitung beteiligt ist (z. B., wenn der Datenverkehr von einer Java™-Clientanwendung direkt an eine Enterprise-Bean in WebSphere Application Server weitergeleitet wird oder der Fehler nur nach dem Aktivieren der Sicherheit von WebSphere Application Server auftritt), welche Art von Fehler wird angezeigt?

[z/OS]System SSL: Informationen zur Verwendung der verfügbaren SSL-Schnittstellen für für Serviceprogrammierung finden Sie in der Veröffentlichung z/OS System Secure Sockets Layer Programming SC24-5901.

[AIX Solaris HP-UX Linux Windows][IBM i]Fehler org.omg.CORBA.INTERNAL: EntryNotFoundException or NTRegistryImp E CWSCJ0070E: Für ... wurde Berechtigungs-ID konfiguriert beim Erstellen eines Berechtigungsnachweises über das Programm.

Allgemeine Hinweise zur Diagnose und Behebung sicherheitsbezogener Fehler enthält der Abschnitt Tipps zur Fehlerbehebung bei Sicherheitskomponenten.

Wenn der angezeigte Fehler nicht in ähnlicher Form dokumentiert ist oder wenn Sie den Fehler anhand der bereitgestellten Informationen nicht beheben können, lesen Sie den Artikel Hilfe von IBM zur Fehlerbehebung.

javax.net.ssl.SSLHandshakeException - Client und Server konnten die gewünschte Sicherheitsstufe nicht vereinbaren. Ursache: Handshake-Fehler

Es wird ein Java-Ausnahme-Stack wie der folgende angezeigt:
[Root exception is org.omg.CORBA.TRANSIENT:  CAUGHT_EXCEPTION_WHILE_CONFIGURING_
SSL_CLIENT_SOCKET: CWWJE0080E:   javax.net.ssl.SSLHandshakeException
- Client und Server konnten die gewünschte Sicherheitsstufe nicht vereinbaren.
Ursache:
Handshake-Fehler:host=MYSERVER,port=1079 minor code: 4942F303 completed: No]   at
com.ibm.CORBA.transport.TransportConnectionBase.connect (TransportConnectionBase.java:NNN)
Einige mögliche Ursachen sind:
  • Der Client und der Server verwenden keine gemeinsamen Cipher.
  • Es wurde nicht das richtige Protokoll angegeben.
Gehen Sie wie folgt vor, um diesen Fehler zu beheben:
  1. [AIX Solaris HP-UX Linux Windows][z/OS]Überprüfen Sie die SSL-Einstellungen. Klicken Sie in der Administrationskonsole auf Sicherheit > Verwaltung von SSL-Zertifikaten und Schlüsseln. Klicken Sie unter "Konfigurationseinstellungen" auf Sicherheitskonfigurationen für Endpunkte verwalten > Name_der_Endpunktkonfiguration. Klicken Sie unter "Zugehörige Elemente" auf SSL-Konfigurationen > Name_der_SSL-Konfiguration. Sie können die Datei auch manuell über den Pfad Installationsstammverzeichnis/properties/sas.client.props anzeigen.
  2. [IBM i]Überprüfen Sie die SSL-Einstellungen. Klicken Sie in der Administrationskonsole auf Sicherheit > Verwaltung von SSL-Zertifikaten und Schlüsseln. Klicken Sie unter "Konfigurationseinstellungen" auf Sicherheitskonfigurationen für Endpunkte verwalten > Name_der_Endpunktkonfiguration. Klicken Sie unter "Zugehörige Elemente" auf SSL-Konfigurationen > Name_der_SSL-Konfiguration. Sie können die Datei auch manuell über den Pfad Stammverzeichnis_des_Anwendungsservers/properties/sas.client.props anzeigen.
  3. Überprüfen Sie die Eigenschaft, die in der Datei com.ibm.ssl.protocol angegeben ist, um festzustellen, welches Protokoll angegeben ist.
  4. Prüfen Sie die von der Schnittstelle com.ibm.ssl.enabledCipherSuites angegebenen Cipher Suites. Möglicherweise möchten Sie der Liste weitere Verschlüsselungstypen hinzufügen. Wenn Sie überprüfen möchten, welche Cipher Suites derzeit aktiv sind, rufen Sie wie zuvor beschrieben die Einstellungen für das Datenschutzniveau auf, und suchen Sie die Eigenschaft Cipher Suites.
  5. Verwenden Sie ein anderes Client- oder Serverprotokoll und/oder eine andere Cipher-Option, um den Fehler zu beheben. Normale Protokolle sind SSL oder SSLv3.
  6. [AIX Solaris HP-UX Linux Windows][IBM i]Verwenden Sie die Cipher-Option mit 40 Bit und nicht mit 128 Bit. Für CSIv2 (Common Secure Interoperability Version 2) müssen Sie in den Einstellungen der Administrationskonsole security level=medium angeben oder die beiden folgenden Eigenschaften in der Datei sas.client.props auf false setzen:
    • com.ibm.CSI.performMessageConfidentialityRequired=false
    • com.ibm.CSI.performMessageConfidentialitySupported=false

javax.net.ssl.SSLHandshakeException: Unbekanntes Zertifikat

Wird ein Java-Ausnahme-Stack wie der folgende angezeigt, liegt dies möglicherweise daran, dass das persönliche Zertifikat für den Server sich nicht im Client-Truststore befindet:
Fehler: Der Anfangskontext konnte nicht abgerufen werden oder der Startkontext wurde nicht gefunden. Die Operation wird abgebrochen.  Ausnahme empfangen: javax.naming.ServiceUnavailableException: Beim Versuch, einen Ausgangskontext mit dem Provider-URL:
"corbaloc:iiop:localhost:2809" abzurufen, ist ein Übertragungsfehler aufgetreten. Vergewissern Sie sich, dass der Host und der Port richtig angegeben wurden und dass der vom Provider-URL angegebene Server ein aktiver Namensserver ist. Wurde keine Portnummer
angegeben, wird die Standardportnummer 2809 verwendet. Andere mögliche
Fehlerursachen liegen in der Konfiguration der Netzumgebung oder des
Workstation-Netzes. [Root exception is org.omg.CORBA.TRANSIENT: 
CAUGHT_EXCEPTION_WHILE_CONFIGURING_SSL_CLIENT_SOCKET: CWWJE0080E: 
javax.net.ssl.SSLHandshakeException
- Client und Server konnten die gewünschte Sicherheitsstufe nicht vereinbaren. Ursache:
Unbekanntes Zertifikat:host=MYSERVER,port=1940 minor code: 4942F303 completed: No]
Gehen Sie wie folgt vor, um diesen Fehler zu beheben:
  1. Prüfen Sie den Client-Truststore, und stellen Sie fest, ob das signierte Zertifikat des persönlichen Zertifikats des Servers vorhanden ist. Bei einem selbst signierten persönlichen Serverzertifikat ist das signierte Zertifikat der öffentliche Schlüssel des persönlichen Zertifikats. Bei einem von einer CA signierten persönlichen Serverzertifikat ist das signierte Zertifikat das Stammzertifikat der CA, die das persönliche Zertifikat signiert hat.
  2. Fügen Sie das signierte Serverzertifikat dem Client-Truststore hinzu.

javax.net.ssl.SSLHandshakeException: Ungültiges Zertifikat

Wenn die folgenden Situationen eintreten, kann ein Java-Ausnahme-Stack angezeigt werden:
  • Der Client-Keystore enthält ein persönliches Zertifikat, das für die gegenseitige SSL-Authentifizierung verwendet wird.
  • Das Unterzeichnerzertifikat wurde nicht in die Truststore-Datei des Servers extrahiert. Deshalb kann der Server das Zertifikat während des SSL-Handshake nicht anerkennen.
Die folgende Nachricht ist ein Beispiel für einen Java-Ausnahme-Stack:
Fehler: Der Anfangskontext konnte nicht abgerufen werden oder der Startkontext wurde nicht gefunden. Die Operation wird abgebrochen.  
Ausnahme empfangen: javax.naming.ServiceUnavailableException: Beim Versuch, einen Ausgangskontext mit dem Provider-URL:
"corbaloc:iiop:localhost:2809" abzurufen, ist ein Übertragungsfehler aufgetreten. 
Vergewissern Sie sich, dass der Host und der Port richtig angegeben wurden und dass der vom Provider-URL angegebene Server ein aktiver Namensserver ist. Wurde keine Portnummer
angegeben, wird die Standardportnummer 2809 verwendet. Andere mögliche
Fehlerursachen liegen in der Konfiguration der Netzumgebung oder des
Workstation-Netzes. 
[Root exception is org.omg.CORBA.TRANSIENT: CAUGHT_EXCEPTION_WHILE_CONFIGURING_SSL_
CLIENT_SOCKET: CWWJE0080E: javax.net.ssl.SSLHandshakeException - Client und Server konnten die gewünschte Sicherheitsstufe nicht vereinbaren.
Ursache: 
Ungültiges Zertifikat: host=MYSERVER,port=1940 minor code: 4942F303 completed: No]

Prüfen Sie den Server-TrustStore, und stellen Sie fest, ob das signierte Zertifikat des persönlichen Zertifikats des Clients vorhanden ist. Bei einem selbst signierten persönlichen Clientzertifikat ist das signierte Zertifikat der öffentliche Schlüssel des persönlichen Zertifikats. Bei einem von einer CA signierten persönlichen Clientzertifikat ist das signierte Zertifikat das Stammzertifikat der CA, die das persönliche Zertifikat signiert hat.

Fügen Sie das signierte Clientzertifikat dem Server-TrustStore hinzu, um diesen Fehler zu beheben.

[AIX Solaris HP-UX Linux Windows][IBM i]

org.omg.CORBA.INTERNAL: EntryNotFoundException or NTRegistryImp E CWSCJ0070E: No privilege id configured for: error when programmatically creating a credential

Möglicherweise wird die folgende Ausnahme in einer Clientanwendung angezeigt, die versucht, einen Berechtigungsnachweis von einem WebSphere Application Server anzufordern, und dabei die gegenseitige SSL-Authentifizierung verwendet:
Fehler: Der Anfangskontext konnte nicht abgerufen werden oder der Startkontext wurde nicht gefunden. Die Operation wird abgebrochen. Ausnahme empfangen: org.omg.CORBA.INTERNAL: Trace vom Server: 1198777258
at host MYHOST on port 0 >>org.omg.CORBA.INTERNAL: EntryNotFoundException minor 
code: 494210B0 completed: 
No at com.ibm.ISecurityLocalObjectBaseL13Impl.PrincipalAuthFailReason.
map_auth_fail_to_minor_code(PrincipalAuthFailReason.java:99)
Möglicherweise empfangen Sie gleichzeitig einen Fehler wie den folgenden von WebSphere Application Server:
[7/31/02 15:38:48:452 CDT] 27318f5 NTRegistryImp
E CWSCJ0070E: Für testuser wurde keine Berechtigungs-ID konfiguriert. 

Ursache dieses Fehlers könnte sein, dass die vom Client an den Server gesendete Benutzer-ID nicht in der Benutzerregistry des Servers vorhanden ist.

Wenn Sie eine Bestätigung für die Fehlerursache wünschen, prüfen Sie, ob ein Eintrag für das persönliche Zertifikat, das an den Server gesendet wird, vorhanden ist. Je nach Verfahren für die Benutzerregistry müssen Sie die Benutzer-ID des nativen Betriebssystems oder die Einträge des LDAP-Servers (Lightweight Directory Access Protocol) prüfen.

Zur Behebung dieses Fehlers können Sie die Benutzer-ID dem Eintrag der Benutzerregistry (z. B. Betriebssystem, LDAP-Verzeichnis oder andere angepasste Registry), der für die ID des persönlichen Zertifikats vorgesehen ist, hinzufügen.

Die Anzeigetafel für den Katalog im GUI-Anwendungsclient ist leer (kein Eintrag angezeigt)

Diese Fehlernachricht erscheint, wenn Sie eine Beispielanwendung des ActiveX-Clients, die die ActiveX-EJB-Brücke von PlantsByWebSphere verwendet, installieren.

Dies liegt daran, dass das Serverzertifikat sich nicht in dem Client-Truststore befindet, der in der Datei client.ssl.props angegeben ist. Obwohl die Unterzeichnereigenschaft "com.ibm.ssl.enableSignerExchangePrompt" möglicherweise auf true gesetzt ist, unterstützt die Eingabeaufforderung für automatischen Unterzeichneraustausch nur eine Eingabeaufforderung über Befehlszeile. Wenn die Beispielanwendung auf einer grafischen Benutzeroberfläche basiert und keinen Zugriff auf eine Eingabeaufforderung bietet, z. B. mit Standardeingabe und Standardausgabe, funktioniert die Eingabeaufforderung für automatischen Unterzeichneraustausch nicht.

Anmerkung: Der Applet-Client in den Client Technology Samples hat keinen Zugriff auf die Eingabeaufforderung und kann die Eingabeaufforderung für automatischen Unterzeichneraustausch nicht erkennen. Daher darf der Applet-Client nicht auf die Eingabeaufforderung für automatischen Unterzeichneraustausch angewiesen sein.

Rufen Sie zur Behebung dieses Problems das Zertifikat mit dem Dienstprogramm retrieveSigners manuell ab.

Nach der Migration mit "-scriptCompatibility true" SSL-Konfigurationen abrufen

Nach der Migration mit "scriptCompatibility true" können keine Attribute der SSL-Konfigurationen über die Administrationskonsole editiert werden. Insbesondere die Verschlüsselungseinstellungen werden nicht angezeigt und sind nicht editierbar.

Die Verwendung des Flags "scriptCompatibility true" bewirkt, dass die SSL-Konfigurationen nicht in das neue Format für die Unterstützung in Version 6.1 oder höhere Releases migriert werden. Es wurden neue Funktionen hinzugefügt, die nicht unterstützt werden, wenn die Konfiguration nicht in das aktuellste Format haben. Wenn Sie eine Migration von einem früheren Release als Version 6.1 durchführen, können Sie die Task "convertSSLConfig" verwenden, um Ihre SSL-Konfigurationsdaten in das zentrale SSL-Konfigurationsformat zu konvertieren.

Eigenständige Konfiguration scheitert, wenn digitale Zertifikate mit der Option NOTRUST definiert werden

Wenn Ihre digitalen Zertifikate mit der Option NOTRUST definiert werden, kann die folgende Fehlernachricht ausgegeben werden:

Trace: 2008/06/18 16:57:57.798 01 t=8C50B8 c=UNK key=S2 (0000000A) 
Description: Log Boss/390 Error 
from filename: ./bbgcfcom.cpp 
at line: 376 
error message: BBOO0042E Function AsynchIOaccept failed with RV=-1, RC=124, RSN=050B0146, ?EDC5124I 
Too many open files. (errno2=0x0594003D)?? 

Wenn dieser Fehler angezeigt wird, geben Sie 'D OMVS,P ein. Falls ein NOTRUST-Problem vorliegt, wird unter "OPNSOCK" eine große Zahl angezeigt.

Überprüfen Sie Ihre digitalen Zertifikate, und stellen Sie sicher, dass sie nicht mit der Option NOTRUST markiert sind. Dies kann passieren, wenn die Zertifikate mit einem Datum erstellt wurden, das nach dem Verfallsdatum der Zertifizierungsstelle (CERTAUTH) liegt, die zum Erstellen des Zertifikats verwendet wurde.

Problem bei der Konfiguration eines LDAP-Repositorys mit SSL

Wenn Sie ein LDAP-Repository mit SSL konfigurieren, müssen Sie das LDAP-Repository auf dem Knoten konfigurieren, bevor der Knoten beim Verwaltungsagenten registriert wird.

Wenn Sie versuchen, das LDAP-Repository nach der Registrierung des Knotens beim Agenten zu konfigurieren, suchen die eingebundenen Repositorys das SSL-Zertifikat im Truststore des Verwaltungsagenten und nicht im Truststore des Knotens.

Problem beim Erstellen eines verketteten Zertifikats für SHA384withECDSA

Wenn Sie Zertifikate in SHA384withECDSA konvertiert haben und versuchen, über die Administrationskonsole ein verkettetes Zertifikat zu erstellen, indem Sie auf Verwaltung von SSL-Zertifikaten und Schlüsseln -> Keystores und Zertifikate -> Keystore -> Persönliches Zertifikat klicken, und dann ein neues verkettetes Zertifikat erstellen, muss die unterstützte Schlüsselgröße 384 sein. Ist sie dies nicht, kann das Zertifikat nicht erstellt werden.

Zur Behebung des Problems aktivieren Sie Javascript, um die richtige Schlüsselgröße anzuzeigen.


Symbol, das den Typ des Artikels anzeigt. Referenzartikel



Symbol für Zeitmarke Letzte Aktualisierung: 25.05.2016
http://www14.software.ibm.com/webapp/wsbroker/redirect?version=cord&product=was-nd-mp&topic=rtrb_sslprobs
Dateiname:rtrb_sslprobs.html