Comunicaciones seguras utilizando SSL (Secure Sockets Layer - Capa de sockets seguros)
El protocolo SSL (Secure Sockets Layer) proporciona seguridad de capa de transporte, incluida la autenticidad, la firma de datos y el cifrado de datos, para garantizar una conexión segura entre un cliente y un servidor que utiliza WebSphere® Application Server. La tecnología en la que se basa SSL es la criptografía de claves públicas, que garantiza que cuando una entidad cifre los datos mediante su clave pública, sólo las entidades con la clave privada correspondiente puedan descifrar esos datos.
WebSphere Application Server utiliza JSSE (Java™ Secure Sockets Extension) como implementación SSL para conexiones seguras. JSSE forma parte de la especificación Java 2 Standard Edition (J2SE) y se incluye en la implementación IBM® de Java Runtime Extension (JRE). JSSE maneja la negociación de reconocimiento de comunicación y las posibilidades de protección que SSL proporciona para garantizar que exista una conectividad segura entre la mayoría de los protocolos. JSSE se basa en los pares de claves asimétricos basados en certificados X.509 para lograr la protección de conexiones seguras y parte del cifrado de datos. Los pares de claves cifran de forma eficaz las claves secretas basadas en sesiones que cifran bloques más grandes de datos. la implementación SSL gestiona los certificados X.509.
WebSphere Application Server suministra Java SE7. De forma predeterminada, Java SE 7 habilita SNI (Server Name Indication). SNI es una extensión del protocolo TLS. SNI permite a un cliente especificar el nombre de host al que está intentando conectarse. Se generan excepciones si el certificado devuelto no coincide con el nombre de host esperado.
En algunos entornos de proxy esto provocará errores. El cliente espera recibir el certificado del proxy, pero en su lugar recibe el certificado del servidor de punto final.
Gestión de certificados X.509
Las comunicaciones seguras para WebSphere Application Server requieren certificados X.509 firmados digitalmente. El contenido de un certificado X.509 , como su nombre distinguido y caducidad, está firmado por una entidad emisora de certificados (CA), firmado por un certificado raíz en NodeDefaultRootStore o DmgrDefaultRootStore, o está autofirmado. Cuando una CA de confianza firma un certificado X.509 , WebSphere Application Server identifica el certificado y lo distribuye libremente. Un certificado debe estar firmado por una CA porque el certificado representa la identidad de una entidad ante el público en general. Los puertos del extremo del servidor que aceptan conexiones del público en general deben utilizar certificados firmados por una CA. Las mayoría de los clientes y navegadores ya tienen el certificado de firmante que puede validar el certificado X.509 para que el intercambio de firmante no sea necesario para una conexión satisfactoria.
Puede confiar en la identidad de un certificado X.509 autofirmado sólo dentro de un igual de un entorno controlado como, por ejemplo, unas comunicaciones de red internas acepte el certificado de firmante. Para completar un reconocimiento de comunicación de confianza, primero debe enviar una copia del certificado de entidad a cada igual que se conecte con la entidad.
Los certificados X.509 de CA, encadenados y autofirmados residen en Java keystores. JSSE proporciona un referencia al almacén de claves donde reside un certificado. Puede seleccionar entre muchos tipos de almacenes de claves, incluidos los almacenes de claves basados en JCE (Java Cryptographic Extension) y basados en hardware. Normalmente, cada configuración JSSE tiene dos referencias de almacén de claves Java: un almacén de claves y un truststore. La referencia de almacén de claves representa un objeto de almacén de claves Java que contiene certificados personales. La referencia de almacén de confianza representa un objeto de almacén de claves Java que contiene certificados de firmante.
Un certificado personal sin una clave privada es un certificado X.509 que representa a la entidad propietaria durante un reconocimiento de comunicación. Los certificados personales contienen claves públicas y privadas. Un certificado de firmante es un certificado X.509 que representa una entidad de igual o a sí mismo. Los certificados de firmante sólo contienen la clave pública y verifican la firma de la identidad que se recibe durante un reconocimiento de comunicación de igual a igual.
Para obtener más información, consulte Adición de los certificados de firmante SSL correctos al almacén de claves del plug-in
Para obtener más información sobre los almacenes de claves, consulte Configuraciones de almacén de claves para SSL.
Intercambio de firmante
Cuando configura una conexión SSL, puede intercambiar firmantes para establecer la confianza en un personal certificate para una entidad específica. El intercambio de firmante permite extraer el certificado X.509 del almacén de claves de igual y añadirlo al almacén de confianza de otra entidad para que las dos entidades de igual puedan conectarse. El certificado de firmante también puede originarse a partir de una CA como certificado de firmante raíz o como certificado de firmante intermedio. También puede extraer un signer certificate directamente de un certificado autofirmado, que es el certificado X.509 con la clave pública.
En este ejemplo, el almacén de confianza para la Entidad A contiene tres firmantes. La Entidad A puede conectarse con cualquier igual siempre y cuando uno de los tres firmantes valide su certificado personal. Por ejemplo, la Entidad A puede conectarse con la Entidad B o Entidad C porque los firmantes pueden confiar en ambos certificados personales firmados. El almacén de confianza de la Entidad B contiene un firmante. La Entidad B sólo puede conectarse con la Entidad C y sólo cuando el punto final de igual esté utilizando el Cert 1 de la Entidad C como identidad. La Entidad B no confía en los puertos que utilizan el otro certificado personal para la Entidad C. La Entidad C se puede conectar únicamente a la Entidad A.
En el ejemplo, la configuración autofirmada parece representar una relación de uno a uno entre el firmante y el certificado. No obstante, cuando una CA firma un certificado, generalmente firma muchas cada vez. La ventaja de utilizar un único firmante de CA es que puede validar certificados personales que la CA genera para el uso de los iguales. No obstante, si el firmante es una CA pública, debe tener en cuenta que es posible que los certificados firmados se hayan generado para otra empresa distinta de su entidad de destino. Para las comunicaciones internas, las CA privadas y los certificados autofirmados son preferibles a las CA públicas porque le permiten aislar las conexiones que desee que ocurran y evitar las que no desee que ocurran.
Configuraciones SSL
Una configuración SSL consta de un conjunto de atributos de configuración que puede asociar con un punto final o conjunto de puntos finales en la topología de WebSphere Application Server . La configuración SSL le permite crear un objeto SSLContext, que el objeto JSSE esencial que utiliza el servidor para obtener las fábricas de sockets SSL. Puede gestionar los atributos de configuración siguientes:- Un alias para el objeto SSLContext
- Una versión del protocolo de reconocimiento de comunicación
- Una referencia de almacén de claves
- Una referencia de almacén de confianza
- Un gestor de claves
- Uno o más gestores de confianza
- Una selección de nivel de seguridad de un grupo de suites de cifrado o de una lista de suites de cifrado específica
- Una elección de alias de certificado para las conexiones de cliente y servidor
RC4
de la lista de cifrado HIGH
mantengan el servidor más seguro de forma predeterminada. Es posible que se utilizara un cifrado
RC4
de forma predeterminada en procesos de reconocimiento
SSL antes de este cambio. Con la eliminación de los cifrados RC4
, es probable que en
su lugar se utilice un cifrado AES
. Los usuarios pueden observar una reducción del rendimiento cuando se
utilizan cifrados AES
más seguros.Selección de configuraciones SSL
En releases anteriores de WebSphere Application Server, sólo puede hacer referencia a una configuración SSL seleccionando directamente el alias de configuración SSL. Todos los puntos finales seguros se conocían por un atributo de alias que hacía referencia a una configuración SSL válida de un repertorio de configuraciones SSL. Cuando se realizaba un único cambio de configuración, era necesario volver a configurar muchas referencias de alias en los distintos procesos. Aunque el release actual todavía da soporte a la selección directa, este enfoque ya no se recomienda.
El release actual proporciona posibilidades mejoradas para gestionar las configuraciones SSL y obtener una mayor flexibilidad al seleccionar las configuraciones SSL. En este release, puede seleccionar entre los siguiente enfoques:- Selección programática
- Puede establecer una configuración SSL en la hebra en ejecución antes de una conexión de salida. WebSphere Application Server garantiza que la mayoría de los protocolos del sistema, incluidos IIOP (Internet Inter-ORB Protocol), JMS (Java Message Service), HTTP (Hyper Text Transfer Protocol) y LDAP (Lightweight Directory Access Protocol), acepten la configuración.
- Selección dinámica
- Puede asociar una configuración SSL dinámicamente con un host, puerto o protocolo de salida de destino específico utilizando un criterio de selección predefinido. Cuando establece la conexión, WebSphere Application Server comprueba si el host y el puerto de destino coinciden con un criterio predefinido que incluye la parte de dominio del host. Adicionalmente, puede predefinir el protocolo para una selección de
configuración SSL de salida y alias de certificado específica.
La selección de salida dinámica de las configuraciones SSL (Secure Sockets Layer) se basa en la información de conexión disponible para el servidor de modo que el servidor pueda comparar el protocolo de salida, host o puerto cuando la creación del socket de cliente tiene lugar en com.ibm.websphere.ssl.protocol.SSLSocketFactory. Para los conectores de administración de WebSphere como SOAP y RMI (Remote Method Invocation), la información de conexión se coloca en la hebra y está disponible para que la selección de salida dinámica se lleve a cabo. El proceso de selección de salida dinámica responde a la información de conexión que se está configurando cuando las propiedades SSL se recuperan de forma similar a lo que se describe en Especificar mediante programación una configuración SSL de salida utilizando la API JSSEHelper.
Cuando la conexión de salida se realiza desde aplicaciones escritas por el cliente, es posible que partes de la información de conexión no se encuentren disponibles. Algunas de estas aplicaciones han llamadas de API a un protocolo para realizar la conexión. La API, en última instancia, llama a uno de los métodos createSocket() de com.ibm.websphere.ssl.protocol.SSLSocketFactory para completar el proceso. Toda la información de conexión de la selección de salida dinámica podría no estar disponible, y es posible que tenga que ajustar el filtro de conexión de la selección de salida dinámica y rellenar con un asterisco (*) la parte que falta de la información de conexión. Como ejemplo, la llamada openConnection() en un objeto de URL llama finalmente a
createSocket(java.net.Socket socket, String host, int port, boolean autoClose)
. La información de conexión puede crearse con el host y el puerto proporcionados, pero no se proporciona ningún protocolo. En este caso, debe utilizarse un comodín o un asterisco (*) para la parte del protocolo de la información de conexión de selección dinámica.La mayor parte de los métodos createSocket() toman una dirección de host o IP y un puerto como parámetros. El filtro de conexión de la selección de salida dinámica puede crearse con el host y el puerto. El método predeterminado, createSocket(), sin parámetros no contiene ninguna información para crear el filtro de conexión de selección de salida a menos que se haya creado una instancia para la fábrica de sockets con información de conexión. Si no hay disponible ninguna información de conexión, puede considerar utilizar uno de los otros métodos de selección de una configuración SSL descritos en este tema "Selección de programación".
Evitar problemas: WebSphere Application Server se basa en la información de host, puerto y protocolo que se pasa a la fábrica de sockets SSL de WebSphere Application Server . La fábrica de sockets SSL de WebSphere Application Server se puede eludir mediante los valores de configuración o la aplicación, es decir:- El archivo java.security no contiene la especificación para la fábrica de sockets de WebSphere Application Server.
- La aplicación llama directamente a otra fábrica de sockets.
- Selección directa
- Puede seleccionar una configuración SSL mediante un alias específico, como en releases anteriores. Este método de selección se mantiene para la compatibilidad con versiones anteriores ya que muchas aplicaciones y procesos se basan en referencias de alias.
- Selección de ámbito
- Puede asociar una configuración SSL y el alias de certificado correspondiente, que se encuentra en el almacén de claves asociado con esa configuración SSL, mediante un ámbito de gestión WebSphere Application Server. Se recomienda este enfoque para gestionar las configuraciones SSL centralmente. Puede gestionar los puntos finales con más eficacia ya que están ubicados en una vista de la topología de la célula. La relación de herencia entre los ámbitos reduce el número de asignaciones de configuraciones SSL que debe establecer.
- Selección programática. Si una aplicación establece una configuración SSL en la hebra en ejecución utilizando la API (interfaz de programas de aplicación) com.ibm.websphere.ssl.JSSEHelper, la configuración SSL tiene garantizada la máxima prioridad.
- Los criterios de selección dinámica para el puerto, protocolo o host de salida.
- Selección directa.
- Selección de ámbito. La herencia de ámbito garantiza que el punto final que seleccione esté asociado con una configuración SSL y lo hereden todos los ámbitos por debajo de él que no alteren temporalmente esta selección.
Configuración predeterminada de certificados encadenados
De forma predeterminada, WebSphere Application Server crea un certificado encadenado exclusivo para cada nodo. El certificado encadenado está firmado con un certificado raíz autofirmado que se almacena en DmgrDefaultRootStore o NodeDefaultRootStore. WebSphere Application Server ya no se basa en un certificado autofirmado o en el certificado predeterminado o ficticio que se suministra con el producto. El almacén de claves predeterminado key.p12 y el almacén de confianza trust.p12 se almacenan en el repositorio de configuración del directorio de nodos. El certificado raíz predeterminado se almacena en el archivo root-key.p12 del repositorio de configuraciones en el directorio de nodos.
Todos los nodos ponen sus certificados de firmante del certificado raíz predeterminado en este almacén de confianza común (trust.p12). Además, después de federar un nodo, la configuración SSL predeterminada se modifica automáticamente para que apunte al almacén de confianza común, que se encuentra en el directorio de célula. El nodo puede comunicarse ahora con todos los demás servidores de la célula.
Todas las configuraciones SSL predeterminadas contienen un almacén de claves con el sufijo de nombre DefaultKeyStore, un almacén de confianza con el sufijo de nombre DefaultTrustStore y un almacén de raíces con el sufijo de nombre DefaultRootStore. Estos sufijos predeterminados indican al tiempo de ejecución de WebSphere Application Server que añada el firmante raíz del certificado personal al almacén de confianza común. Si un nombre de almacén de confianza no termina por DefaultKeyStore, los certificados de firmante del almacén de confianza no se añaden al almacén de confianza común cuando se federa el servidor. Puede cambiar la configuración SSL predeterminada, pero debe garantizar que se establezca la confianza correcta para las conexiones administrativas, entre otras cosas.
Para obtener más información, consulte Configuración del certificado encadenado predeterminado en SSL y Configuración predeterminada del plug-in de servidor web en SSL.
Supervisión de la caducidad de certificados
La supervisión de certificados garantiza que el certificado encadenado predeterminado para cada nodo no pueda caducar. La función de supervisión de la caducidad de certificados emite un aviso antes de que se establezca la caducidad de los certificados y firmantes. Los certificados y firmantes que se encuentran en los almacenes de claves gestionados por la configuración de WebSphere Application Server se pueden supervisar. Puede configurar el supervisor de caducidad para que sustituya un certificado automáticamente. Se volverá a crear un certificado encadenado basado en los mismos datos que se han utilizado para la creación inicial y se firmará con el mismo certificado raíz con el que se ha firmado el certificado original. Un certificado autofirmado o un certificado encadenado se vuelven a crear según los mismos datos utilizados para la creación inicial.
El supervisor también puede sustituir automáticamente los firmantes antiguos con los firmantes de los nuevos certificados encadenados o autofirmados en los almacenes de claves gestionados por WebSphere Application Server. Se preservan los intercambios de firmante existentes realizados por el tiempo de ejecución durante la federación o por la administración. Para obtener más información, consulte Supervisión de caducidad de certificados en SSL.
Se configura el supervisor de caducidad para sustituir certificados personales encadenados firmados por un certificado raíz en DmgrDefaultRootStore o NodeDefaultRootStore El certificado se renueva con el mismo certificado raíz utilizado para firmar el certificado original.
El supervisor también puede sustituir automáticamente los firmantes antiguos por los firmantes de los nuevos certificados autofirmados en los almacenes de claves gestionados por WebSphere Application Server. Se preservan los intercambios de firmante existentes realizados por el tiempo de ejecución durante la federación o por la administración. Para obtener más información, consulte Supervisión de caducidad de certificados en SSL.Clientes de WebSphere Application Server : requisitos de intercambio de firmante
Se genera un nuevo certificado encadenado para cada nodo durante su arranque inicial. Para garantizar la confianza, se debe proporcionar a los clientes los firmantes raíz para establecer una conexión. La introducción de certificados encadenados en el release actual simplifica este proceso. En lugar de intercambiar el firmante de un certificado autofirmado de corta vida, puede intercambiar el firmante raíz de larga vida, lo que permitirá que se mantenga la confianza en las renovaciones de certificados personales. Además, puede obtener acceso a los certificados de firmante de varios nodos a los que el cliente debe conectarse con cualquiera de las opciones siguientes (para obtener más información, consulte Instalación segura para la recuperación de firmante de cliente en SSL):- Un indicador de intercambio de firmante le permite importar
certificados de firmante que no estén presentes todavía en los almacenes
de confianza durante una conexión con un servidor. De forma predeterminada, este
indicador está habilitado para las conexiones administrativas y puede
habilitarse para cualquier configuración SSL de cliente. Cuando se
habilita este indicador, cualquier conexión que se realice con un servidor
donde el firmante todavía no esté presente ofrece el firmante del servidor
junto con la información de certificado y un valor de conversión SHA
(Secure Hash Algorithm) del certificado para su verificación. El usuario puede optar si
desea aceptar estas credenciales. Si las credenciales se aceptan, el
firmante se añade al almacén de confianza del cliente hasta que el
firmante se elimina explícitamente. El indicador de intercambio de firmante no vuelve a aparecer al conectarse al mismo servidor a menos que
cambie el certificado personal.Atención: No es seguro confiar en un indicador de intercambio de firmante sin verificar el resumen SHA. Un indicador no verificado puede originarse a partir de un navegador cuando no se confíe en un certificado.
- Puede ejecutar un script administrativo retrieveSigners de un cliente antes de realizar las conexiones con los servidores. Para bajar firmantes, no es necesaria ninguna autorización administrativa. Para subir firmantes, debe tener una autorización de rol de administrador. El script baja todos los firmantes de un determinado almacén de confianza de servidor en el almacén de confianza de cliente especificado y se le puede llamar para que sólo baje un alias específico de un almacén de confianza. Asimismo, puede llamar al script para que suba los firmante a los almacenes de confianza de servidor. Al seleccionar el almacén de confianza CellDefaultTrustStore como almacén de confianza de servidor especificado y almacén de confianza común para una célula, todos los firmante de esa célula se bajan en el almacén de confianza de cliente especificado, que es generalmente ClientDefaultTrustStore. Para obtener más información, consulte MandatoretrieveSigners.
- Puede distribuir físicamente entre los clientes el almacén de confianza común trust.p12 ubicado en el directorio de célula del repositorio de configuración. Al realizar esta distribución, no obstante, debe garantizar que se haya especificado la contraseña correcta en el archivo de configuración SSL de cliente ssl.client.props. La contraseña predeterminada para este almacén de confianza es WebAS. Cambie la contraseña predeterminada antes de la distribución. La distribución física no es tan efectiva como las opciones anteriores. Cuando se realizan cambios en los certificados personales del servidor, los intercambios automáticos puede generar un error.
Cambios de configuración SSL dinámica
El tiempo de ejecución SSL para WebSphere Application Server mantiene escuchas para la mayoría de conexiones SSL. Un cambio de la configuración SSL hace que los escuchas de conexiones de entrada creen un nuevo objeto SSLContext. Las conexiones existentes continúan utilizando el objeto SSLContext actual. Las conexiones de salida utilizan automáticamente las nuevas propiedades de configuración cuando aquellas se acepten.Realice cambios dinámicos en la configuración SSL durante las horas de menor actividad para reducir la posibilidad de problemas relacionados con la temporización y para evitar la posibilidad de que se reinicie el servidor. Si habilita el tiempo de ejecución para que acepte cambios dinámicos, cambie la configuración SSL y guarde el archivo security.xml. Los cambios entrarán en vigor cuando el nuevo archivo security.xml llegue a cada nodo.
Gestión de certificados incorporada
Una gestión de certificados comparable a las funciones de iKeyMan está integrada actualmente en los paneles de gestión de almacenes de claves de la consola administrativa. Utilice la gestión de certificados incorporada para gestionar los certificados personales, las solicitudes de certificados y los certificados de firmante ubicados en los almacenes de claves. Asimismo, puede gestionar los almacenes de claves de forma remota. Por ejemplo, puede gestionar un almacén de claves basado en archivos ubicado fuera del repositorio de configuración en cualquier nodo del gestor de despliegue. También puede gestiona los almacenes de claves criptográficos de hardware desde el gestor de despliegue de forma remota.Con la gestión de certificados incorporada, puede sustituir un certificado encadenado o autofirmado junto con todos los certificados de firmante repartidos entre numerosos almacenes de confianza y recuperar un firmante desde un puerto remoto mediante la conexión con el host y puerto SSL remotos y la interceptación del firmante durante el reconocimiento de la comunicación. Primero se valida el certificado de acuerdo con el valor de conversión SHA del certificado y, a continuación, el administrador debe aceptar el certificado validado antes de que pueda colocarse en un almacén de confianza.