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
Mit HTTPS auf Ressourcen zugreifen
- javax.net.ssl.SSLHandshakeException - Client und Server konnten die gewünschte Sicherheitsstufe nicht vereinbaren. Ursache: Handshake-Fehler
- javax.net.ssl.SSLHandshakeException: Unbekanntes Zertifikat
- javax.net.ssl.SSLHandshakeException: Ungültiges Zertifikat
org.omg.CORBA.INTERNAL: EntryNotFoundException or NTRegistryImp E CWSCJ0070E: No privilege id configured for: error when programmatically creating a credential
- Die Anzeigetafel für den Katalog im GUI-Anwendungsclient ist leer (kein Eintrag angezeigt)
- Nach der Migration mit "-scriptCompatibility true" SSL-Konfigurationen abrufen
- Eigenständige Konfiguration scheitert, wenn digitale Zertifikate mit der Option NOTRUST definiert werden
- Problem bei der Konfiguration eines LDAP-Repositorys mit SSL
- Problem beim Erstellen eines verketteten Zertifikats für SHA384withECDSA
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.
Verwenden Sie zum Beenden der Prozesse den Task-Manager.
Führen Sie den Befehl zum Beenden des Prozesses aus.
Verwenden Sie zum Beenden der Prozesse auf der Plattform z/OS die MVS-Konsole,
und geben Sie c Prozessname ein.
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.
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]](../images/dist.gif)
![[z/OS]](../images/ngzos.gif)
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.
- 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.
- 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.
- 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?
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.
- javax.net.ssl.SSLHandshakeException - Client und Server konnten die gewünschte Sicherheitsstufe nicht vereinbaren. Ursache: Handshake-Fehler
- javax.net.ssl.SSLHandshakeException - Client und Server konnten die gewünschte Sicherheitsstufe nicht vereinbaren. Ursache: Unbekanntes Zertifikat
- javax.net.ssl.SSLHandshakeException - Client und Server konnten die gewünschte Sicherheitsstufe nicht vereinbaren. Ursache: Ungültiges Zertifikat
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
[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)
- Der Client und der Server verwenden keine gemeinsamen Cipher.
- Es wurde nicht das richtige Protokoll angegeben.
Ü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.
Ü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.
- Überprüfen Sie die Eigenschaft, die in der Datei com.ibm.ssl.protocol angegeben ist, um festzustellen, welches Protokoll angegeben ist.
- 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.
- Verwenden Sie ein anderes Client- oder Serverprotokoll und/oder eine andere Cipher-Option, um den Fehler zu beheben. Normale Protokolle sind SSL oder SSLv3.
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
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]
- 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.
- Fügen Sie das signierte Serverzertifikat dem Client-Truststore hinzu.
javax.net.ssl.SSLHandshakeException: Ungültiges Zertifikat
- 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.
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]](../images/dist.gif)
![[IBM i]](../images/iseries.gif)
org.omg.CORBA.INTERNAL: EntryNotFoundException or NTRegistryImp E CWSCJ0070E: No privilege id configured for: error when programmatically creating a credential
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)
[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.
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.