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.

La Figura 1 ilustra la configuración de un almacén de claves y un almacén de confianza hipotético. Una configuración SSL determina qué entidades pueden conectarse con otras entidades y las conexiones de igual en las que confía el reconocimiento de comunicación SSL. Si no tiene el certificado de firmante necesario, se genera un error en el reconocimiento de comunicación porque no se puede confiar en el igual.

Figura 1. Intercambio de firmante

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

Para conocer los detalles específicos de cada atributo de configuración SSL, consulte Configuraciones SSL.

Nota: WebSphere no permite que las suites de cifrado 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.

Si (1) o (2) es el caso, el proceso de selección de salida SSL dinámico se omite y la conexión no se realiza.

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.; Siempre que se asocia una configuración SSL con un ámbito de célula, el ámbito de nodo de la célula automáticamente hereda las propiedades de configuración. No obstante, cuando se asigna una configuración SSL a un nodo, la configuración de nodo altera temporalmente la configuración que el nodo hereda de la célula. De modo parecido, todos los servidores de aplicaciones de un nodo automáticamente heredan la configuración SSL de ese nodo a menos que se alteren temporalmente estas asignaciones. A menos que altere temporalmente una configuración específica, la topología se basa en las reglas de herencia del nivel de célula hasta el nivel de punto final para cada servidor de aplicaciones.
Nota: Si las aplicaciones se están basando en configuraciones SSL que se han establecido como valores individuales para cada configuración SSL de la topología, pero los servidores de aplicaciones han heredado la configuración SSL tal como se ha desplegado desde el nivel de célula hasta el nivel de punto final, existe la posibilidad de que se produzcan errores de comunicación entre servidores (por ejemplo, errores de reconocimiento). Debe asegurarse de que las aplicaciones funcionen de acuerdo con la gestión central de las configuraciones SSL.; La vista de la topología muestra una árbol de entrada y uno de salida. Puede realizar distintas selecciones de configuración SSL para cada extremo de la conexión SSL basándose en lo que ese servidor utiliza como conexión de salida y lo que utiliza como conexión de entrada. Consulte Gestión central de configuraciones SSL para obtener más información.

El tiempo de ejecución sigue un orden de prioridad para determinar qué configuración SSL debe seleccionarse ya que existen muchos modos de seleccionar las configuraciones SSL. Considere el siguiente orden de prioridad al seleccionar un enfoque de configuración:

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 [AIX Solaris HP-UX Linux Windows] 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.

Importante: Para una cadena de certificados caducada o una cadena de certificados de entidad emisora de certificados (CA) caducada, es necesario que actualice la cadena entera . Debe generar una nueva cadena de certificados que tenga los certificados de firmante individuales. Para una cadena de certificados de CA, esto puede requerir importar una nueva cadena de certificados, normalmente mediante un nuevo archivo de solicitud de certificados (CSR).

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.

Nota: Si los cambios de configuración provocan errores de reconocimiento SSL, también se pueden producir errores de conectividad administrativa, lo que puede provocar paradas. En este caso, debe volver a configurar las conexiones SSL y realizar manualmente la sincronización de nodos para corregir el problema. Debe completar cuidadosamente cualquier cambio dinámico. Se recomienda que realice los cambios de las configuraciones SSL en un entorno de prueba antes de realizarlos en un sistema de producción.

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.

Cuando realice una solicitud de certificado, puede enviarla a una autoridad certificadora (CA). Cuando se devuelva el certificado, puede aceptarlo en la consola administrativa.

Sugerencia: Aunque la funcionalidad iKeyMan todavía se suministra con WebSphere Application Server, configure los almacenes de claves desde la consola administrativa utilizando la funcionalidad de gestión de certificados incorporada. iKeyMan sigue siendo una opción cuando no resulta cómodo utilizar la consola administrativa. Para obtener más información, consulte Gestión de certificados utilizando iKeyman antes de SSL.

Gestión de configuración de AdminTask

Los paneles de gestión de configuración SSL de la consola administrativa se basan principalmente en las tareas administrativas, que se mantienen y mejoran para dar soporte al funcionamiento de la consola administrativa. Puede utilizar los mandatos wsadmin desde un indicador de la consola Java para automatizar la gestión de almacenes de claves, configuraciones SSL, certificados, etc.