Erreurs de SSL pour la sécurité

Certains problèmes peuvent survenir une fois la configuration ou l'activation de Secure Sockets Layer (SSL) effectuées. Après avoir configuré SSL, il se peut que vous ne puissiez pas arrêter le gestionnaire de déploiement. Vous ne pourrez peut-être pas accéder à la ressource via HTTPS. Il se peut que le client et le serveur ne puissent pas négocier le niveau de sécurité adéquat. Les problèmes mentionnés ici ne sont que quelques exemples. La résolution de ces incidents est nécessaire au bon fonctionnement de WebSphere Application Server.

Quel type de problème rencontrez-vous ?

Arrêt du gestionnaire de déploiement après la configuration de Secure Sockets Layer

Si, après la configuration des répertoires SSL, vous arrêtez le gestionnaire de déploiement mais laissez les agents de noeuds actifs, le message d'erreur suivant risque de s'afficher lors du redémarrage du gestionnaire de déploiement :

CWWMU0509I: The server "nodeagent" cannot be reached. It appears to be stopped.
CWWMU0211I: Error details may be seen in the file:
           /opt/WebSphere/AppServer/logs/nodeagent/stopServer.log

L'erreur se produit car le gestionnaire de déploiement n'a pas propagé le nouveau certificat SSL aux agents de noeuds. Les agents de noeuds utilisent un fichiers de certificat plus ancien que le gestionnaire de déploiement et les fichiers de certificat sont incompatibles. Pour y remédier, arrêtez manuellement les processus des agents de noeuds et du gestionnaire de déploiement.

[Windows]Pour arrêter les processus en cours d'exécution, utilisez le gestionnaire des tâches.

[AIX HP-UX Solaris]Exécutez la commande pour arrêter le processus

[z/OS]Pour arrêter les processus en cours d'exécution, utilisez la console MVS et entrez c nom_processus.

[AIX Solaris HP-UX Linux Windows][z/OS]Vous devez examiner certains éléments lors de l'identification du processus spécifique à arrêter. Pour chaque processus en cours d'arrêt, WebSphere Application Server stocke l'ID processus dans un fichier pid et il est par conséquent nécessaire de localiser les fichiers *.pid. Par exemple, le fichier server1.pid d'une action d'installation autonome peut se trouver dans : racine_installation/logs/server1.pid

[IBM i]Vous devez examiner certains éléments lors de l'identification du processus spécifique à arrêter. Pour chaque processus en cours d'arrêt, WebSphere Application Server stocke l'ID processus dans un fichier pid et il est par conséquent nécessaire de localiser les fichiers *.pid. Par exemple, le fichier server1.pid d'une action d'installation autonome peut se trouver dans : racine_serveur_applis/logs/server1.pid

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

Accès aux ressources à l'aide de HTTPS

Si vous n'arrivez pas à accéder aux ressources à l'aide d'une URL SSL (Secure Sockets Layer), URL commençant par https : ou que des messages d'erreur s'affichent indiquant des incidents SSL, vérifiez que le serveur HTTP est configuré correctement pour SSL. Parcourez la page d'accueil du serveur HTTP utilisant SSL en entrant l'URL : https://nom_hôte.

Si la page fonctionne avec HTTP, mais pas avec HTTPS, l'incident se situe au niveau du serveur HTTP.
  • Reportez-vous à la documentation afférente à votre serveur HTTP pour les instructions permettant d'activer correctement SSL. Si vous utilisez IBM® HTTP Server ou Apache, accédez au site : http://www.ibm.com/software/webservers/httpservers/library.html. Cliquez sur Frequently Asked Questions> SSL.
  • Si vous utilisez l'outil de gestion de clés IKeyman IBM pour créer des certificats et des clés, n'oubliez pas de stocker le mot de passe dans un fichier lors de la création du fichier KDB (Key Database) avec cet outil IBM.
    1. Allez dans le répertoire où le fichier KDB a été créé et vérifiez s'il contient un fichier .sth.
    2. Si ce n'est pas le cas, ouvrez le fichier KDB avec l'outil IBM de gestion de clés, puis sélectionnez Fichier de base de données de clés > Stocker le mot de passe. Le message Mot de passe chiffré et sauvegardé dans le fichier s'affiche.

Type d'erreur signalée lorsque le serveur HTTP peut traiter correctement les requêtes de chiffrement SSL ou n'est pas impliqué (par exemple, si le trafic passe d'une application client Java™ directement à un bean enterprise hébergé par WebSphere Application Server, ou si l'incident ne se produit qu'après activation de la sécurité WebSphere Application Server).

[z/OS]Système SSL : Pour plus d'informations sur l'utilisation des interfaces de programmation des services appelables par SSL (System Secure Sockets Layer), voir z/OS System Secure Sockets Layer Programming SC24-5901.

[AIX Solaris HP-UX Linux Windows][IBM i]Vous obtenez le message d'erreur org.omg.CORBA.INTERNAL: EntryNotFoundException ou NTRegistryImp E CWSCJ0070E: No privilege id configured for: lors de la création de données d'identification via un programme?.

Pour des conseils d'ordre général sur le diagnostic et la résolution des incidents liés à la sécurité, reportez-vous à la rubrique Conseils pour l'identification et la résolution des problèmes liés aux composants de sécurité

Si vous ne trouvez pas d'incident similaire au vôtre, ou si les informations fournies ne permettent pas de le résoudre, voir Identification des incidents dans l'aide d'IBM.

javax.net.ssl.SSLHandshakeException - Le client et le serveur ne peuvent pas négocier le niveau de sécurité souhaité. Motif : Echec d'établissement de liaison

Si vous rencontrez une pile d'exceptions Java similaire à celle de l'exemple ci-après :
[Root exception is org.omg.CORBA.TRANSIENT:  CAUGHT_EXCEPTION_WHILE_CONFIGURING_
SSL_CLIENT_SOCKET: CWWJE0080E:   javax.net.ssl.SSLHandshakeException - The client
and server could not negotiate the desired level of   security. Reason: handshake 
failure:host=MYSERVER,port=1079 minor code: 4942F303 completed: No]   at 
com.ibm.CORBA.transport.TransportConnectionBase.connect 
(TransportConnectionBase.java:NNN)
Les causes possibles sont les suivantes :
  • Pas de codes de chiffrement communs entre le client et le serveur.
  • Pas de protocole correct spécifié.
Pour résoudre ces incidents, procédez comme suit :
  1. [AIX Solaris HP-UX Linux Windows][z/OS]Consultez les paramètres SSL. Dans la console d'administration, sélectionnez Sécurité > Certificat SSL et gestion des clés. Sous Paramètres de configuration, cliquez sur Gérer les configurations des sécurités et les zones sécurisées de noeud final > nom_configuration_noeud final. Dans la section Articles liés, cliquez sur Configurations SSL > nom_configuration_SSL. Vous pouvez également parcourir le fichier manuellement en ouvrant le fichier racine_installation/properties/sas.client.props.
  2. [IBM i]Consultez les paramètres SSL. Dans la console d'administration, sélectionnez Sécurité > Certificat SSL et gestion des clés. Sous Paramètres de configuration, cliquez sur Gérer les configurations des sécurités et les zones sécurisées de noeud final > nom_configuration_noeud final. Dans la section Articles liés, cliquez sur Configurations SSL > nom_configuration_SSL. Vous pouvez également parcourir le fichier manuellement en ouvrant le fichier racine_serveur_applis/properties/sas.client.props.
  3. Vérifiez la propriété définie par le fichier com.ibm.ssl.protocol pour déterminer le protocole indiqué.
  4. Vérifiez les types de cryptographie désignés par l'interface com.ibm.ssl.enabledCipherSuites. Vous pouvez ajouter des types de cryptographie à la liste. Pour afficher les algorithmes de cryptographie actuellement activés, cliquez sur Paramètres de qualité de protection (QoP) et recherchez la propriété Algorithmes de cryptographie.
  5. Rectifiez l'incident de protocole ou de cryptographie en utilisant un autre protocole client ou serveur et en sélectionnant une autre cryptographie. Les protocoles les plus courants sont SSL et SSLv3.
  6. [AIX Solaris HP-UX Linux Windows][IBM i]Sélectionnez une cryptographie 40 bits au lieu de 128 bits. Pour CSIv2 (Common Secure Interoperability Version 2), définissez les deux propriétés suivantes à false dans le fichier sas.client.props ou définissez le paramètre security level=medium dans la console d'administration :
    • com.ibm.CSI.performMessageConfidentialityRequired=false
    • com.ibm.CSI.performMessageConfidentialitySupported=false

javax.net.ssl.SSLHandshakeException : Certificat inconnu

Si une pile d'exceptions Java similaire à l'exemple ci-après s'affiche, il est probable que le certificat personnel du serveur ne se trouve pas dans le fichier de clés certifiées du client :
ERROR: Could not get the initial context or unable to look up the starting context. 
Exiting.  Exception received: javax.naming.ServiceUnavailableException: A 
communication failure occurred while attempting to obtain an initial context using 
the provider url: "corbaloc:iiop:localhost:2809". Make sure that the host and port 
information is correct and that the server identified by the provider url is a 
running name server. If no port number is specified, the default port number 2809 
is used. Other possible causes include the network environment or workstation 
network configuration. [Root exception is org.omg.CORBA.TRANSIENT: 
CAUGHT_EXCEPTION_WHILE_CONFIGURING_SSL_CLIENT_SOCKET: CWWJE0080E: 
javax.net.ssl.SSLHandshakeException - The client and server could not 
negotiate the desired level of security. Reason: unknown 
certificate:host=MYSERVER,port=1940 minor code: 4942F303 completed: No]
Pour résoudre le problème, procédez comme suit :
  1. Vérifiez si le fichier de magasin sécurisé du client contient le certificat signataire issu du certificat personnel du serveur. Pour un certificat personnel de serveur auto-signé, le certificat signataire est la clé publique du certificat personnel. Pour un certificat personnel de serveur signé d'une autorité de certification (CA), le certificat signataire est le certificat de CA racine de l'autorité de certification qui a signé le certificat personnel.
  2. Ajoutez le certificat signataire du serveur dans le fichier de magasin sécurisé du client.

javax.net.ssl.SSLHandshakeException : Certificat incorrect

Une erreur de pile d'exception Java peut s'afficher si les situations suivantes se produisent :
  • Un certificat personnel existe dans le fichier de clés client utilisé pour l'authentification mutuelle SSL.
  • Le certificat du signataire n'est pas extrait dans le fichier de clés certifiées. Le serveur ne peut donc pas certifier le certificat lors de l'établissement de liaison SSL.
L'exemple suivant est un message d'erreur de pile d'exception Java :
ERROR: Could not get the initial context or unable to look 
up the starting context. Exiting.  
Exception received: javax.naming.ServiceUnavailableException: 
A communication failure occurred while attempting to obtain an 
initial context using the provider url: "corbaloc:iiop:localhost:2809". 
Make sure that the host and port information is correct and that the
server identified by the provider url is a running name 
server. If no port number is specified, the default port number 2809 
is used. Other possible causes include the network environment or 
workstation network configuration. 
[Root exception is org.omg.CORBA.TRANSIENT: CAUGHT_EXCEPTION_WHILE_CONFIGURING_SSL_
CLIENT_SOCKET: CWWJE0080E: javax.net.ssl.SSLHandshakeException - The client and 
server could not negotiate the desired level of security. Reason: 
bad certificate: host=MYSERVER,port=1940 minor code: 4942F303 completed: No]

Pour corriger ce problème, vérifiez si le fichier de magasin sécurisé du serveur contient le certificat signataire issu du certificat personnel du client. Pour un certificat personnel de client auto-signé, le certificat signataire est la clé publique du certificat personnel. Pour un certificat personnel de client signé d'une autorité de certification (CA), le certificat signataire est le certificat de CA racine de l'autorité de certification qui a signé le certificat personnel.

Pour rectifier cet incident, ajoutez le certificat signataire du client dans le fichier de magasin sécurisé du serveur.

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

Exception org.omg.CORBA.INTERNAL : EntryNotFoundException ou NTRegistryImp E CWSCJ0070E : Aucun ID de privilège n'est configuré pour : erreur lors de la création par programme d'un justificatif

Si l'exception suivante se produit dans une application client qui tente d'obtenir un justificatif auprès d'un serveur d'applications WebSphere Application Server à l'aide de l'authentification mutuelle SSL :
ERROR: Could not get the initial context or unable to look up the starting context. 
Exiting. Exception received: org.omg.CORBA.INTERNAL: Trace from 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)
ou une erreur simultanée provenant du serveur d'applications WebSphere Application semblable à :
[7/31/02 15:38:48:452 CDT] 27318f5 NTRegistryImp E CWSCJ0070E : Aucun ID de privilège n'est configuré pour : testuser

L'erreur peut provenir du fait que l'ID utilisateur envoyé au serveur par le client ne figure pas dans le registre des utilisateurs du serveur.

Pour confirmer l'incident, vérifiez qu'il existe une entrée pour le certificat personnel envoyé au serveur. En fonction du mécanisme du registre des utilisateurs, consultez l'ID utilisateur du système d'exploitation natif ou les entrées de serveur LDAP (Lightweight Directory Access Protocol).

Pour rectifier cette erreur, ajoutez l'ID utilisateur à l'entrée du registre des utilisateurs (par exemple, système d'exploitation, annuaire LDAP ou autre registre personnalisé) de l'identité du certificat personnel.

La tablette "Catalog" est vierge (aucun élément affiché) sur le client d'application à interface graphique

Ce message d'erreur s'affiche lorsque vous installez une application exemple de client ActiveX qui utilise la passerelle PlantsByWebSphere Active X vers EJB.

La raison est que le certificat du serveur ne se trouve pas dans le magasin sécurisé du client qui est spécifié dans le fichier client.ssl.props. Même si la propriété du signataire "com.ibm.ssl.enableSignerExchangePrompt" peut être définie sur true, l'invite d'échange automatique prend uniquement en charge une invite de ligne de commande. Si l'application exemple se base sur une interface graphique utilisateur et ne fournit pas d'accès à une invite de commande (par exemple, à l'aide de l'entrée et de la sortie standard), l'invite d'échange automatique ne fonctionne pas.

Remarque : Le client d'applet des exemples de technologie client n'a pas accès à l'invite de commande et ne peut pas voir l'invite d'échange automatique. Par conséquent, le client d'applet ne peut pas se baser sur la fonction d'invite d'échange automatique.

Pour corriger ce problème, vous devez extraire le certificat manuellement à l'aide de l'utilitaire retrieveSigners.

Modification des configurations SSL après une migration à l'aide de -scriptCompatibility true

Après une migration via scriptCompatibility true, tous les attributs des configurations SSL ne peuvent pas être modifiés via la console d'administration. Plus particulièrement, les paramètres de cryptographie matérielle ne peuvent pas s'afficher ou ne sont pas modifiables.

A l'aide de l'indicateur scriptCompatibility true, les configurations SSL ne sont pas migrées vers le nouveau format de prise en charge dans la version 6.1 et les suivantes. Les nouvelles fonctionnalités ajoutées ne sont pas prises en charge si les configurations ne sont pas migrées vers le format le plus récent. Si vous procédez à la migration à partir d'une version antérieure à la version 6.1, vous pouvez utiliser la tâche convertSSLConfig pour convertir vos informations de configuration SSL au format de configuration SSL centralisé.

La configuration autonome échoue quand des certificats numériques sont définis avec l'option NOTRUST.

Si vos certificats numériques sont définis avec l'option NOTRUST, vous risquez de recevoir le message d'erreur suivant :

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)?? 

Si ce message d'erreur s'affiche, entrez 'D OMVS,P. En cas d'incident lié à l'option NOTRUST, une grande valeur apparaît sous "OPNSOCK".

Vérifiez que l'option NOTRUST est activée dans vos certificats numériques. Ceci peut arriver si les certificats ont été créés à une date postérieure à la date d'expiration de l'autorité de certification (CERTAUTH) utilisée pour les créer.

Problème lors de la configuration d'un référentiel LDAP avec SSL

Lors de la configuration d'un référentiel LDAP avec la couche Secure Sockets Layer (SSL), vous devez configurer le référentiel sur le noeud avant que celui-ci ne soit enregistré auprès de l'agent d'administration.

Si vous tentez de configurer le référentiel LDAP après avoir enregistré le noeud auprès de l'agent, les référentiels fédérés recherchent les certificats SSL dans le magasin de clés certifiées de l'agent d'administration au lieu du magasin de clés certifiées du noeud.

Problème lors de la création d'un certificat chaîné pour SHA384withECDSA

Si des certificats sont convertis en SHA384withECDSA et si vous essayez de créer un certificat chaîné à partir de la console d'administration en cliquant sur Certificat SSL et gestion des clés->Fichiers de clés et certificats->magasin de clés >Certificat personnel, puis de créer un nouveau certificat chaîné, la taille de clé prise en charge doit être 384. Si ce n'est pas le cas, le certificat ne peut pas être créé.

Pour résoudre ce problème, activez Javascript pour afficher la taille de clé correcte sur le panneau.


Icône indiquant le type de rubrique Rubrique de référence



Icône d'horodatage Dernière mise à jour: last_date
http://www14.software.ibm.com/webapp/wsbroker/redirect?version=cord&product=was-nd-mp&topic=rtrb_sslprobs
Nom du fichier : rtrb_sslprobs.html