Errores de SSL para seguridad

Es posible que encuentre varios problemas después de configurar o habilitar SSL (Secure Sockets Layer). Es posible que no pueda detener el gestor de despliegue después de configura SSL. Es posible que no pueda acceder al recurso utilizando HTTPS. Es posible que el cliente y el servidor no puedan negociar el nivel correcto de seguridad. los problemas mencionado aquí son únicamente un número reducido de posibilidades. La resolución de estos problemas es un imperativo para el funcionamiento correcto de WebSphere Application Server.

¿Qué tipo de problema tiene?

Detención del gestor de despliegue después de configurar Secure Sockets Layer

Después de configurar los repertorios de Secure Sockets Layer, si detiene el gestor de despliegue sin detener los agentes de nodo, puede recibir el siguiente mensaje de error cuando reinicie el gestor de despliegue:

CWWMU0509I: No se puede
acceder a "agente de nodo". Parece que está parado.
CWWMU0211I: Puede ver los detalles del error en el archivo:
           /opt/WebSphere/AppServer/logs/nodeagent/stopServer.log

El error se produce porque el gestor de despliegue no ha propagado el nuevo certificado SSL a los agentes de nodo. Los agentes de nodo están utilizando un archivo de certificado más antiguo que el gestor de despliegue y los archivos de certificado son incompatibles. Para evitar este problema, debe detener manualmente los procesos del agente de nodo y del gestor de despliegue.

[Windows]Para finalizar los procesos, utilice el gestor de tareas.

[AIX HP-UX Solaris]Ejecute el mandato para finalizar el proceso.

[z/OS]Para finalizar los procesos, utilice la consola de MVS y escriba c nombre_proceso.

[AIX Solaris HP-UX Linux Windows][z/OS]Debe tener en cuenta determinados elementos cuando identifique el proceso específico que ha de detener. Para cada proceso detenido, WebSphere Application Server almacena el ID de proceso en un archivo pid, siendo necesario que busque estos archivos *.pid. Por ejemplo, el archivo servidor1.pid para una acción de instalación autónoma puede encontrarse en: raíz_instalación/logs/servidor1.pid

[IBM i]Debe tener en cuenta determinados elementos cuando identifique el proceso específico que ha de detener. Para cada proceso detenido, WebSphere Application Server almacena el ID de proceso en un archivo pid, siendo necesario que busque estos archivos *.pid. Por ejemplo, el archivo servidor1.pid para una acción de instalación autónoma puede encontrarse en: raíz_servidor_aplicaciones/servidor1.pid

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

Acceso a los recursos utilizando HTTPS

Si no puede acceder a los recursos utilizando un URL de SSL (Secure Socket Layer), esto es, los que comienzan por https:, o si encuentra mensajes de error que indiquen que hay problemas de SSL, compruebe que el servidor HTTP se ha configurado correctamente para SSL. Vaya a la página de bienvenida del servidor HTTP que utiliza SSL, escribiendo el URL: https://nombre_host.

Si la página funciona con HTTP pero no con HTTPS, el problema está en el servidor HTTP.
  • Consulte la documentación del servidor HTTP para obtener instrucciones sobre cómo habilitar correctamente SSL. Si está utilizando IBM® HTTP Server o Apache, vaya a http://www.ibm.com/software/webservers/httpservers/library.html. Pulse Preguntas frecuentes> SSL.
  • Si utiliza la herramienta IBM Key Management (IKeyman) para crear certificados y claves, recuerde que debe ocultar la contraseña en un archivo cuando cree el archivo KDB (Key Database) con la herramienta IBM Key Management Tool.
    1. Vaya al directorio donde se ha creado el archivo KDB y compruebe si hay un archivo .sth.
    2. Si no es así, abra el archivo KDB con la herramienta IBM Key Management y pulse Archivo de base de datos de claves > Ocultar contraseña. Aparecerá el mensaje siguiente: La contraseña se ha cifrado y guardado en el archivo.

Si el servidor HTTP maneja correctamente las solicitudes cifradas para SSL, o si no participa (por ejemplo, si el tráfico fluye desde una aplicación de cliente Java™ directamente a un enterprise bean que alberga WebSphere Application Server o si el problema sólo surge después de habilitar la seguridad de WebSphere Application Server), ¿qué clase de error aparece?:

[z/OS]System SSL: Consulte z/OS System Secure Sockets Layer Programming SC24-5901 para obtener más información sobre el uso de las interfaces de programación de los servicios invocables System SSL (Secure Sockets Layer).

[AIX Solaris HP-UX Linux Windows][IBM i]Obtiene este mensaje de error: org.omg.CORBA.INTERNAL: EntryNotFoundException o NTRegistryImp E CWSCJ0070E: No hay ningún identificador privilegiado para:, al crear una credencial de forma programada.

Para obtener información general sobre cómo diagnosticar y resolver los problemas relacionados con la seguridad, consulte Sugerencias para la resolución de problemas con los componentes de seguridad

Si no encuentra ningún problema que se asemeje al suyo o si la información proporcionada no resuelve el problema, consulte Ayuda para la resolución de problemas de IBM.

javax.net.ssl.SSLHandshakeException: el cliente y el servidor no han podido negociar el nivel deseado de seguridad. Razón: error de protocolo de enlace

Si ve una pila de excepciones Java similar al siguiente ejemplo:
[La excepción raíz es org.omg.CORBA.TRANSIENT:
CAUGHT_EXCEPTION_WHILE_CONFIGURING_
SSL_CLIENT_SOCKET: CWWJE0080E:   javax.net.ssl.SSLHandshakeException - El cliente
y el servidor no han podido negociar el nivel deseado de seguridad. Razón: error de reconocimiento 
:host=MYSERVER,port=1079 código secundario: 4942F303 completado: No]   en 
com.ibm.CORBA.transport.TransportConnectionBase.connect 
(TransportConnectionBase.java:NNN)
Algunas de las causas posibles son:
  • No existe un cifrado común entre el cliente y el servidor.
  • No se especifica el protocolo correcto.
Para corregir estos problemas:
  1. [AIX Solaris HP-UX Linux Windows][z/OS]Revise los valores SSL. En la consola administrativa, pulse Seguridad > Gestión de claves y certificados SSL. En Valores de configuración, pulse Gestionar configuraciones de seguridad de punto final > nombre_configuración_punto_final. En Elementos relacionados, pulse Configuraciones SSL > nombre_configuración_SSL. También puede examinar el archivo manualmente, visualizando el archivo raíz_instalación/properties/sas.client.props.
  2. [IBM i]Revise los valores SSL. En la consola administrativa, pulse Seguridad > Gestión de claves y certificados SSL. En Valores de configuración, pulse Gestionar configuraciones de seguridad de punto final > nombre_configuración_punto_final. En Elementos relacionados, pulse Configuraciones SSL > nombre_configuración_SSL. También puede examinar el archivo manualmente, visualizando el archivo raíz_servidor_aplicaciones/properties/sas.client.props.
  3. Compruebe la propiedad especificada mediante el archivo com.ibm.ssl.protocol para determinar qué protocolo se ha especificado.
  4. Compruebe los tipos de cifrado especificados mediante la interfaz com.ibm.ssl.enabledCipherSuites. Es posible que desee añadir más tipos de cifrado a la lista. Para ver qué suites de cifrado están habilitadas actualmente, pulse Calidad de los valores de protección (QoP) y busque la propiedad Suites de cifrado.
  5. Corrija el problema de protocolo o cifrado utilizando un protocolo de cliente o de servidor diferente y una selección de cifrado diferente. Los protocolos típicos son SSL o SSLv3.
  6. [AIX Solaris HP-UX Linux Windows][IBM i]Seleccione el cifrado de 40 bits, en lugar del cifrado de 128 bits. Para CSIv2 (Common Secure Interoperability Version 2), establezca las dos propiedades siguientes como false en el archivo sas.client.props, o establezca security level=medium en los valores de la consola administrativa:
    • com.ibm.CSI.performMessageConfidentialityRequired=false
    • com.ibm.CSI.performMessageConfidentialitySupported=false

javax.net.ssl.SSLHandshakeException: certificado desconocido

Si ve una pila de excepciones Java similar al siguiente ejemplo, puede deberse a que no tiene el certificado personal del servidor en el archivo de almacén de confianza del cliente:
ERROR: No se ha podido obtener el contexto inicial o no se ha encontrado el contexto
inicial.
Saliendo.  Se ha recibido una excepción: javax.naming.ServiceUnavailableException: 
Se ha producido un error de comunicación al intentar obtener un contexto inicial mediante 
el url del proveedor: "corbaloc:iiop:localhost:2809". Asegúrese de que la información del host y del puerto 
es correcta y de que el servidor identificado por el url del proveedor es un 
servidor de nombre en ejecución. Si no se especifica ningún puerto, se utiliza el número
de puerto predeterminado 2809 
. Otras posibles causas son la configuración del entorno de red o de 
la
red de la estación de trabajo. [La excepción raíz es org.omg.CORBA.TRANSIENT: 
CAUGHT_EXCEPTION_WHILE_CONFIGURING_SSL_CLIENT_SOCKET: CWWJE0080E: 
javax.net.ssl.SSLHandshakeException: el cliente y el servidor no han podido 
negociar el nivel deseado de seguridad. Razón: desconocida 
certificado:host=MYSERVER,port=1940 código secundario: 4942F303 completado: No]
Para corregir este problema:
  1. Compruebe el archivo de almacén de confianza del cliente para determinar si está el certificado de firmante del certificado personal del servidor. En un certificado personal de servidor autofirmado, el certificado de firmante es la clave pública del certificado personal. En un certificado personal de servidor firmado por la autoridad certificadora (CA), el certificado de firmante es el certificado CA raíz de la CA que ha firmado el certificado personal.
  2. Añada el certificado de firmante del servidor al archivo de almacén de confianza del cliente.

javax.net.ssl.SSLHandshakeException: certificado no válido

Es posible que se muestre un error de la pila de excepciones Java si se produce la situación siguiente:
  • Existe un certificado personal en el almacén de claves que se utiliza para la autenticación mutua SSL.
  • El certificado de firmante no se extrae al archivo del almacén de confianza del servidor y, por lo tanto, el servidor no puede confiar en el certificado durante el reconocimiento de comunicación SSL.
El mensaje siguiente es un ejemplo de un error de la pila de excepciones Java:
ERROR: No se ha podido obtener el contexto inicial o no se ha encontrado el contexto inicial. Saliendo.  
Excepción recibida: javax.naming.ServiceUnavailableException: 
Se ha producido un error de comunicación al intentar obtener un 
contexto inicial mediante el url del proveedor: "corbaloc:iiop:localhost:2809". 
Asegúrese de que la información del host y del puerto sea correcta y de que
el servidor identificado por el url del proveedor es un servidor de nombre en ejecución 
. Si no se especifica ningún puerto, se utiliza el número
de puerto predeterminado 2809 
. Otras posibles causas son la configuración del entorno de red o de 
la red de la estación
de trabajo. 
[La excepción raíz es org.omg.CORBA.TRANSIENT: CAUGHT_EXCEPTION_WHILE_CONFIGURING_SSL_
CLIENT_SOCKET: CWWJE0080E: javax.net.ssl.SSLHandshakeException - El cliente y 
el servidor no han podido negociar el nivel deseado de seguridad. Razón: 
certificado no válido:host=MYSERVER,port=1940 minor code: 4942F303
completed: No]

Para verificar este problema, compruebe el archivo de almacén de confianza del cliente para determinar si está el certificado de firmante del certificado personal del cliente. En un certificado personal de cliente autofirmado, el certificado de firmante es la clave pública del certificado personal. En un certificado personal de cliente firmado por la autoridad certificadora, el certificado de firmante es el certificado CA raíz de la CA que ha firmado el certificado personal.

Para corregir este problema, añada el certificado de firmante del cliente al archivo de almacén de confianza del servidor.

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

org.omg.CORBA.INTERNAL: EntryNotFoundException o NTRegistryImp E CWSCJ0070E: No hay ningún identificador privilegiado para:, al crear una credencial de forma programada.

Si encuentra la excepción siguiente en una aplicación de cliente cuando intenta solicitar una credencial a WebSphere Application Server utilizando la autenticación mutua SSL:
ERROR: No se ha podido obtener el contexto inicial o no se ha encontrado el contexto
inicial.
Saliendo. Se ha recibido la excepción: org.omg.CORBA.INTERNAL: Rastreo desde el servidor: 1198777258 
en el host MYHOST del puerto 0 >>org.omg.CORBA.INTERNAL: EntryNotFoundException código
menor: 494210B0 completado: 
No en com.ibm.ISecurityLocalObjectBaseL13Impl.PrincipalAuthFailReason.
map_auth_fail_to_minor_code(PrincipalAuthFailReason.java:99)
o un error simultáneo procedente de WebSphere Application Server que se asemeja a:
[7/31/02 15:38:48:452 CDT] 27318f5 NTRegistryImp E CWSCJ0070E: No se ha configurado un ID de privilegio 
para: testuser

La causa puede ser que el ID de usuario que ha enviado el cliente al servidor no está en el registro de usuarios de ese servidor.

Para confirmar este problema, compruebe que exista una entrada para el certificado personal que se envía al servidor. Dependiendo del mecanismo del registro de usuarios, busque las entradas de servidor LDAP (Lightweight Directory Access Protocol) o el ID de usuario del sistema operativo original.

Para corregir este problema, añada el ID de usuario a la entrada del registro de usuarios (por ejemplo, el sistema operativo, el directorio LDAP u otro registro personalizado) para conocer la identidad del certificado personal.

"Catalog" está en blanco (no se visualiza ningún elemento) en el cliente de aplicaciones de la GUI

Este mensaje de error se genera cuando se instala una aplicación de ejemplo de cliente ActiveX que utiliza PlantsByWebSphere Active X para el puente EJB.

La causa es que el certificado del servidor no está en el almacén de confianza del cliente especificado en el archivo client.ssl.props. Aunque la propiedad de firmante "com.ibm.ssl.enableSignerExchangePrompt" puede haberse establecido en true, el indicador auto-exchange sólo da soporte al indicador de línea de mandatos. Si la aplicación de cliente se basa en una interfaz gráfica de usuario y no proporciona acceso a un indicador de mandatos utilizando, por ejemplo, salida estándar y entrada estándar, el indicador auto-exchange no funciona.

Nota: El cliente del applet de los ejemplos de Client Technology no tiene acceso al indicador de mandatos y no puede ver el indicador auto-exchange. Por lo tanto, el cliente del applet no puede basarse en la característica del indicador auto-exchange.

Para corregir este problema, recupere el certificado manualmente utilizando el programa de utilidad retrieveSigners.

Modificación de las configuraciones SSL después de la migración utilizando -scriptCompatibility true

Después de migrar utilizando scriptCompatibility true, todos los atributos de las configuraciones SSL no se pueden editar a través de la consola administrativa. En particular, los valores criptográficos de hardware no se pueden visualizar ni editar.

Utilizando el distintivo scriptCompatibility true, las configuraciones SSL no se migrarán al formato nuevo para el soporte en la versión 6.1 y releases posteriores. Se han añadido posibilidades nuevas que no reciben soporte cuando las configuraciones no se migran al formato más reciente. Si migra desde un release anterior a la Versión 6.1, puede utilizar la tarea convertSSLConfig para convertir la información de configuración SSL al formato de configuración SSL centralizada.

La configuración autónoma falla cuando los certificados digitales están definidos con la opción NOTRUST

Si los certificados digitales están definidos con la opción NOTRUST, es posible que reciba el siguiente mensaje de error:

Rastreo: 2008/06/18 16:57:57.798 01 t=8C50B8 c=UNK key=S2 (0000000A)
Description: Log Boss/390 Error 
del archivo: ./bbgcfcom.cpp 
en la línea: 376 
Mensaje de error: BBOO0042E La función AsynchIOaccept ha fallado con RV=-1, RC=124, RSN=050B0146, ?EDC5124I 
Hay demasiados archivos abiertos. (errno2=0x0594003D)?? 

Si aparece este error, especifique 'D OMVS,P. Si tiene un problema NOTRUST, aparece un número elevado en 'OPNSOCK'.

Compruebe los certificados digitales y asegúrese de que no estén marcados con la opción NOTRUST. Esto puede ocurrir si los certificados se han creado con una fecha posterior a la fecha de caducidad de la autorización CERTAUTH utilizada para su creación.

Problema al configurar un repositorio LDAP con SSL

Al configurar un repositorio LDAP con SSL, debe configurar el repositorio LDAP en el nodo antes de que el nodo se registre con el agente administrativo.

Si intenta configurar el repositorio LDAP después de registrar el nodo con el agente, los repositorios federados buscan los certificados SSL en el almacén de confianza del agente administrativo en lugar del almacén de confianza del nodo.

Problema al crear un certificado encadenado para SHA384withECDSA

Si tiene certificados convertidos a SHA384withECDSA e intenta crear un certificado encadenado desde la consola administrativa pulsando Certificado SSL y gestión de claves->Almacenes de claves y certificados ->almacén_claves >Certificado personal y, a continuación, crea un nuevo certificado encadenado, el tamaño de clave soportado debe ser 384. Si no lo es, no puede crearse el certificado.

Para resolverlo, habilite Javascript para que muestre el tamaño de clave correcto en el panel


Icon that indicates the type of topic Reference topic



Timestamp icon Last updated: last_date
http://www14.software.ibm.com/webapp/wsbroker/redirect?version=cord&product=was-nd-mp&topic=rtrb_sslprobs
File name: rtrb_sslprobs.html