Secure Sockets Layer (SSL) en Caching Proxy

SSL (Secure Sockets Layer) es un sistema que cifra automáticamente la información antes de enviarla a través de Internet y la descifra en el otro extremo antes de utilizarla. Este sistema protege la información confidencial como, por ejemplo, los dígitos de las tarjetas de crédito, mientras se transmite a través de Internet.

Caching Proxy utiliza SSL para proteger los servidores suplentes y proporcionar una administración remota segura, tal como se describe en las secciones siguientes. SSL también puede utilizarse para proteger las conexiones con los servidores de programa de fondo (por ejemplo, los servidores de contenido y de aplicaciones) además de las comunicaciones entre el servidor proxy y sus clientes.

Para el proxy de reenvío, Caching Proxy da soporte al túnel SSL, que omite SSL y reenvía los datos ya cifrados sin modificarlos.

Protocolo de enlace SSL

La protección se inicia cuando se envía una petición de conexión segura desde una máquina a otra. Por ejemplo, cuando un navegador envía una petición a un servidor proxy sustituto. La sintaxis de petición https:// en lugar de http:// indica al navegador que envíe la petición al puerto 443, que es donde el servidor escucha las peticiones de conexiones seguras, y no al puerto 80 para las peticiones rutinarias. Para establecer una sesión segura entre el navegador y el servidor, las dos máquinas realizan un intercambio denominado protocolo de enlace SSL para acordar una especificación de cifrado y seleccionar una clave que se utilice para cifrar y descifrar la información. Las claves se generan automáticamente y caducan cuando lo hace la sesión.

Un caso de ejemplo típico con SSL Versión 3 es el siguiente:
  1. Saludo del cliente

    El cliente inicia una sesión SSL con Caching Proxy enviando un mensaje Hello de cliente que describe las prestaciones de cifrado del cliente.

  2. Saludo del servidor

    El servidor envía su certificado al cliente y elige el conjunto de cifrado que se va a utilizar para el cifrado de datos.

  3. Finalización del cliente

    El cliente envía la información de claves de cifrado que se utilizan para crear las claves de cifrado simétricas de los datos cifrados. Este material de clave se conoce como secreto premaestro y se cifra con la clave pública del servidor (obtenida del certificado del servidor; consulteGestión de claves y certificados). Tanto el servidor como el cliente pueden derivar las claves de cifrado simétricas de lectura y escritura a partir del secreto premaestro.

  4. Finalización del servidor

    El servidor envía una confirmación final y un código de autenticación de mensajes (MAC) para todo el protocolo de establecimiento de comunicación).

  5. Validación del cliente

    El cliente envía un mensaje para validar el mensaje de finalización del servidor.

  6. Flujo de datos seguros

    Si el cliente valida el mensaje de finalización del servidor, comienza el flujo de datos cifrado.

El uso de un Caching Proxy como punto final para conexiones seguras puede reducir la carga en el contenido o en los servidores de aplicaciones. Cuando un Caching Proxy mantiene una conexión segura, realiza el cifrado, el descifrado y la creación de claves, que son operaciones que requieren mucha CPU. Caching Proxy también le permite configurar tiempos de espera de sesión SSL para maximizar el uso de cada clave.

Limitaciones de SSL

Las limitaciones siguientes se aplican a SSL en WebSphere® Application Server Caching Proxy:
  • El propio Caching Proxy no se puede utilizar como entidad emisora de certificados (consulte Gestión de claves y certificados).
  • Es posible que algunos navegadores no den soporte a toda la tecnología de cifrado que se utiliza en Caching Proxy.
  • SUSE Linux® solo da soporte a túneles SSL (no SSL; consulteTúneles SSL).

Ajuste de rendimiento de SSL

Durante volúmenes de tráfico altos de HTTPS, el servidor Caching Proxy puede causar un uso elevado de la CPU. Cambios en el ajuste de una variable de entorno (GSK_V3_SIDCACHE_SIZE) y de una directiva de proxy (SSLV3Timeout) pueden ayudar al servidor proxy a gestionar la carga y reducir el uso de CPU.

El ID de sesión de SSL identifica las sesiones SSL reutilizables, incluidas las claves de cifrado o descifrado utilizadas por ambos navegadores y servidores, y se utiliza para evitar protocolos de enlace SSL innecesarios en las conexiones nuevas, que consumen buena parte del tiempo de CPU del servidor. La biblioteca IBM Global Security Kit (GSKit) para el servidor Caching Proxy da soporte al ID de sesión SSL e incluye una memoria caché de ID de sesión SSL. Por omisión, la memoria caché del ID de sesión SSL contiene 512 entradas. Cuando se alcanza el límite de la entrada, la entrada de sesión más antigua se elimina y la nueva entrada se añade la antememoria.

Utilice la variable de entorno GSK_V3_SIDCACHE_SIZE para cambiar el tamaño por omisión de la memoria caché de ID de sesión SSL. Un valor válido de la variable está entre 1 y 4096. Si aumenta el tamaño, aumenta el tiempo de búsqueda necesario para localizar una sesión SSL en antememoria. No obstante, el aumento del tiempo de búsqueda es insignificante comparado con la actividad general que es necesaria para establecer una conexión SSL. Si aumenta el tamaño de la antememoria, ayuda al servidor proxy a gestionar más sesiones SSL simultáneas y reducir el uso de la CPU cuando el servidor proxy esté por debajo de cargas elevadas de HTTPS.

Caching Proxy también tiene una directiva ajustable, SSLV3Timeout. (Consulte SSLV3Timeout : especifique el tiempo de espera antes de que caduque una sesión SSLV3.) El valor por omisión de la directiva es de 1000 segundos. Esta directiva define la duración de una sesión SSL en la memoria caché de sesión. Si ninguna conexión SSL entrante utiliza una sesión SSL existente y la duración de la sesión sobrepasa este valor, la sesión se elimina de la antememoria de sesión. Es recomendable que ajuste el valor de SSLV3Timeout a la duración típica de una sesión segura de cliente. Si el tiempo de espera es demasiado corto, puede reducir el rendimiento del proxy porque se necesitan varias sesiones de protocolo de enlace SSL para completar una sola sesión segura. Sin embargo, si el valor es demasiado grande, también puede perjudicar la seguridad de una sesión segura.

Configuración SSL de un servidor sustituto

Cuando se utiliza Caching Proxy como sustituto, las solicitudes entre clientes y el proxy, o las solicitudes entre servidores de contenido y el proxy, o ambas, se pueden proteger utilizando Secure Sockets Layer. Para habilitar SSL, primero debe crear una base de datos de claves y crear y obtener un certificado.

La distribución de Application Server incluye un programa de utilidad IBM Global Security Kit (GSKit) para gestionar claves y certificados. Para obtener más información, consulte Gestión de claves y certificados.

Después de establecer la base de datos de claves y el certificado, para configurar SSL para el servidor proxy sustituto, en los formularios Configuración y administración , seleccione Configuración de proxy -> Valores SSL. En el formulario Valores SSL, seleccione el recuadro Habilitar SSL y escriba los nombre de vía de acceso del archivo de base de datos y el archivo de contraseñas del conjunto de claves de los campos proporcionados. Opcionalmente, puede especificar un valor de tiempo de espera para las sesiones SSL. Si el servidor pasa demasiado tiempo volviendo a crear las claves, es recomendable incrementar el valor del tiempo de espera del campo Tiempo de espera para sesiones SSL V3.

Asimismo, puede especificar si el servidor debe intentar colocar en memoria caché el contenido de las peticiones seguras. Aunque la colocación en memoria caché puede mejorar el rendimiento, la colocación en memoria caché de material confidencial puede suponer un riesgo para la seguridad. Puede utilizar filtros de almacenamiento en memoria caché para controlar el tipo de archivos que se almacenan en memoria caché a partir de solicitudes seguras creando filtros para los URL que utilizan https:// (Para especificar filtros de almacenamiento en memoria caché, en los formularios Configuración y administración , seleccione Configuración de memoria caché -> Filtros de almacenamiento en memoria caché.) Los valores de colocación en memoria caché SSL del servidor proxy afectan a todas las conexiones que terminan en ese servidor proxy, tanto si se realizan con las máquinas cliente o con las máquinas del servidor de contenido.

Soporte SSL para varios dominios

Anteriormente, no era posible tener un único servidor Caching Proxy actuando como proxy sustituto para varios dominios que ofrecían certificados SSL individuales. Esta limitación ya no se aplica. Caching Proxy, que actúa como proxy sustituto para varios dominios, ahora puede determinar el certificado correcto que se repartirá en función del dominio al que se envía la solicitud. Esta nueva característica se configura mediante la directiva SSLCertificate del archivo ibmproxy.conf. Consulte SSLCertificate -- Specify key labels for certificates para obtener detalles.

Utilice los rangos IP en las máscaras de protección

Esta nueva función utiliza la subdirectiva MASK de la configuración de protección para habilitar la utilización de rangos IP en las máscaras de protección. Ahora los administradores pueden configurar más fácilmente Caching Proxy para autenticar solicitudes de direcciones IP especificadas y no autenticar solicitudes de otros, evitando la necesidad de crear archivos de reglas de protección muy grandes que podrían afectar negativamente al rendimiento del proxy. Por ejemplo, especifique la siguiente información para autenticar todas las peticiones de 9.38.(100–192)/202/203.(0–255) y pasar todas las demás peticiones.
MASK  ALL@"9.38.[100-192,202,203].[0-255]", @"9.38.[0-99],193-201,204-255].
[0-255]",@"[0-8,20-255].[0-37,39-255].[0-255].[0-255]"
En este ejemplo, tenga en cuenta que los corchetes ([]) incluyen el rango, las comillas (" ") incluyen las plantillas IP del rango y los espacios no están permitidos en la plantilla de IP del rango. Tenga en cuenta que la subdirectiva MASK no debe contener divisiones de línea. Para más detalles, consulte Máscara -- Especifique los nombres de usuario, grupos y direcciones autorizados a realizar peticiones HTTP en el capítulo de referencia de directivas.
Nota: Los valores comodín no se pueden utilizar simultáneamente con el rango; por ejemplo, 9.*.[32,33].154 no está permitido.

Inhabilitación de las hebras de receptor al habilitar SSL

Esta nueva función permite a los administradores de Caching Proxy deshabilitar los hilos de escucha para peticiones HTTP estándar (normalmente en los puertos 80 u 8080) cuando SSL está habilitado (normalmente en el puerto 443). Es posible que la ejecución de hebras de receptor HTTP activas pueda crear una sitio desprotegido en un servidor que realice transacciones seguras. La habilidad para inhabilitar estas hebras de receptor mejora la seguridad de servidor. Utilice la directiva SSLOnly para inhabilitar las hebras de receptor de las peticiones HTTP estándar cuando se habilita SSL.

Después de configurar SSL, debe detener el servidor completamente y, a continuación, iniciarlo de nuevo antes de que los cambios entren en vigor, ya que los valores SSL no se modifican mediante una sencilla operación de reinicio.

Para configurar SSL editando directamente el archivo de configuración de proxy, consulte los apartados de referencia de estas directivas:

Autenticación de certificados de cliente

Esta función permite a Caching Proxy recuperar un certificado de infraestructura de claves públicas (PKI) del lado del cliente a través de una sesión SSL. Este certificado se utiliza seguidamente para autenticar el cliente. Exigir a los clientes que presenten un certificado PKI aumenta la seguridad del servidor, garantizando la autenticación del cliente. Utiliza la directiva SSLCertificate para especificar si el servidor proxy debe recuperar un certificado PKI del cliente.

Túneles SSL

Cuando Caching Proxy se configura como un proxy de reenvío, utiliza el túnel SSL para dar soporte a conexiones seguras entre clientes y servidores de contenido. En los túneles SSL, los datos cifrados se pasan a través del servidor proxy sin experimentar modificaciones. Como el servidor proxy no descifra los datos, no se da soporte en los túneles SSL a las funciones que requieren que el servidor proxy lea las peticiones o las cabeceras de documento. Asimismo, las peticiones de túnel no se colocan en memoria caché.

Solo se aplica a configuraciones de proxy de reenvío.

La Figura 1 muestra cómo se establece una conexión utilizando el túnel SSL.
Figura 1. Túneles SSL
Túneles SSL
El procedo de túneles SSL es el siguiente:
  1. El cliente realiza una solicitud de túnel: CONNECT server-host-name:port HTTP/1.1 (o HTTP/1.0). El número de puerto es opcional y es 443 generalmente. El navegador del cliente enviará automáticamente la petición CONNECT primero al servidor proxy para cada petición HTTPS si el proxy de reenvío se ha configurado en el navegador.
  2. El proxy acepta la conexión en su puerto 80, recibe la petición y se conecta al servidor de destino en el puerto solicitado por el cliente.
  3. El proxy responde al cliente que se ha establecido una conexión.
  4. El proxy difunde mensajes de protocolo de enlace en ambas direcciones: desde el cliente al servidor de destino y desde éste al cliente.
  5. Después de que se haya completado el protocolo de enlace seguro, el proxy envía y recibe datos cifrados para que se descifren en el cliente o en el servidor de destino.
  6. Si el cliente o el servidor de destino solicita el cierre de cualquiera de los puertos, el servidor proxy cierra ambas conexiones (los puertos 443 y 80) y continúa con su actividad normal.

Configuración de túneles SSL

En un valor de proxy de reenvío, únicamente están disponibles los túneles SSL. Para habilitar el túnel SSL, en los formularios Configuración y administración , seleccione Configuración de proxy -> Valores de proxy. Seleccione el recuadro de selección Túneles SSL.

El método CONNECT (que se habilita por omisión) también debe habilitarse para las conexiones de túneles SSL. Para activarlo en los formularios de configuración, seleccione Configuración del servidor -> Procesamiento de peticiones y utilice el formulario Métodos HTTP.

Se proporcionan tres opciones (OutgoingPorts, OutgoingIPs, IncomingIPs) para la directiva Enable CONNECT para mejorar la seguridad de túneles SSL. Es necesario que especifique un valor para OutgoingPorts como mínimo; en caso contrario, el método CONNECT no se habilitará.
  • OutgoingPorts (para limitar el acceso para túneles SSL según los puertos del servidor remoto). El formato es,
    Enable CONNECT OutgoingPorts [all | [port1|port1-port2|port1-*],...]
    Para permitir que los clientes se conecten sólo al puerto 443 de los servidores remotos para túneles SSL, establezca las directivas siguientes. (Normalmente, el puerto 443 es para peticiones HTTPS en el servidor remoto.)
    Enable CONNECT OutgoingPorts 443 
SSLTunneling on
    Para permitir que los clientes se conecten a cualquier puerto de los servidores remotos para túneles SSL, establezca las directivas siguientes:
    Enable CONNECT OutgoingPorts all 
SSLTunneling on
    Para permitir a los clientes conectarse a los puertos 80, 8080-8088 y 9000 y puertos superiores en los servidores remotos para túneles SSL, establezca las directivas siguientes:
    Enable CONNECT OutgoingPorts 80,8080-8088,9000-* 
SSLTunneling on

    Los puertos y los rangos de puertos se separan con una coma sin dejar ningún espacio en la lista.

    IMPORTANTE: para configuraciones de proxy directo, especifique al menos 443 o all con la opción OutgoingPorts para habilitar el túnel SSL normal.

  • OutgoingIPs (para limitar el acceso para túneles SSL según la dirección IP del servidor remoto). El formato es,
    Enable CONNECT OutgoingIPs [[!]IP_pattern,...]
    Por ejemplo, para permitir que los clientes se conecten a cualquier puerto de los servidores remotos que coincidan con el nombre de IP/host *.ibm.com y que no coincidan con 192.168.*.* , establezca las directivas siguientes:
    Enable CONNECT OutgoingPorts all OutgoingIPs *.ibm.com,!192.168.*.*
SSLTunneling on
    Nota: los patrones de IP están separados por una coma sin ningún espacio en la lista.
  • IncomingIPs (para limitar el acceso para túneles SSL según la dirección IP del cliente). El formato es,
    Enable CONNECT IncomingIPs [[!]IP_Pattern,...]
    Por ejemplo, para permitir que los clientes procedentes de la dirección IP 192.168.*.* establezcan una conexión con cualquier puerto de los servidores remotos para túneles SSL, establezca las directivas siguientes:
    Enable CONNECT OutgoingPorts all IncomingIPs 192.168.*.* 
SSLTunneling on
    Nota:
    1. Suponiendo que 192.168.*.* es la máscara de IP de LAN interna. La opción anterior sólo permite a los usuarios internos utilizar el método de conexión y la función de túneles SSL.
    2. Los valores IP_patterns se separan con una coma sin dejar ningún espacio en la lista.

Configuración de la administración remota segura

La administración remota de Caching Proxy se puede realizar utilizando las características de seguridad proporcionadas por SSL (Secure Sockets Layer) y la autenticación de contraseña. Con ello, se reduce significativamente la probabilidad de acceso al servidor proxy por las personas no autorizadas.

Para aplicar SSL durante la administración remota del servidor, utilice una solicitud https:// en lugar de una solicitud http:// para abrir los formularios de Configuración y administración . Por ejemplo:
https://
                  your.server.name
               /
                  yourFrontPage.html

Gestión de claves y certificados

Antes de configurar SSL debe configurar una base de datos de claves, y obtener o crear un certificado. Los certificados se utilizan para autenticar las identidades de servidor. Utilice el programa de utilidad IBM Key Management (a veces denominado iKeyman) para configurar los archivos de certificación. Este programa de utilidad forma parte de Java Development Kit (JDK). iKeyman también incluye una interfaz gráfica basada en Java para abrir archivos de certificado.

Los pasos básicos siguientes configuran los certificados y las claves SSL:
  1. Asegúrese de que tiene IBM JDK Versión 1.6 o posterior.
  2. Utilice el gestor de claves para crear una clave para las comunicaciones de red seguras y recibir un certificado de una autoridad certificadora. Es posible que decida crear un certificado autofirmado mientras espera recibir el certificado de la autoridad certificadora.
  3. Cree una base de datos de claves y especifique una contraseña de base de datos de claves.
Nota: Los archivos de claves y keystash se desinstalan siempre que se desinstala Caching Proxy . Para evitar tener que solicitar un nuevo certificado a la autoridad certificadora, guarde copias de seguridad de estos dos archivos en otro directorio antes de desinstalar el software de proxy.

En todos los sistemas operativos excepto para Linux, si el certificado ha caducado, el proxy de almacenamiento en memoria caché no se iniciará correctamente, y aparece un mensaje de error que indica que la base de datos de claves ha caducado. En Linux, el proxy parece iniciarse, pero el proceso desaparece rápidamente y no se genera ningún mensaje de error.

Para prevenir este problema en los sistemas Red Hat Enterprise Linux 3.0, asegúrese de que los paquetes GCC estén en los niveles siguientes o superiores:
  • libstdc++-3.2.3-52
  • libgcc-3.2.3-52

Autoridades certificadoras

La clave pública debe asociarse con un certificado firmado digitalmente procedente de una autoridad certificadora (CA) designada como CA raíz de confianza del servidor. Puede comprar un certificado firmado sometiendo una petición de certificado a un proveedor de autoridades certificadoras (CA).

Caching Proxy da soporte a las siguientes CA externas:
  • VeriSign
  • Thawte
Por omisión, se designan como CA de confianza a las siguientes CA:
  • Verisign Class 1 Individual Subscriber CA - Persona Not Validated
  • Verisign Class 2 Individual Subscriber CA - Persona Not Validated
  • Verisign Class 3 Individual Subscriber CA - Persona Not Validated
  • VeriSign Class 3 International Server CA
  • VeriSign Class 2 OnSite Individual CA
  • VeriSign Class 1 Public Primary CA
  • VeriSign Class 2 Public Primary CA
  • VeriSign Class 3 Public Primary CA
  • VeriSign Class 1 Public Primary CA - G2
  • VeriSign Class 2 Public Primary CA - G2
  • RSA Secure Server CA (de VeriSign)
  • Thawte Personal Basic CA
  • Thawte Personal Freemail CA
  • Thawte Personal Premium CA
  • Thawte Premium Server CA
  • Thawte Server CA

Utilización del programa de utilidad IBM Key Manager

Esta sección proporciona una referencia rápida para utilizar el programa de utilidad IBM Key Manager (iKeyman). Utilice el gestor de claves para crear el archivo de base de datos de claves SSL, el par de claves pública y privada y la petición de certificado. Después de recibir el certificado firmado por la CA, utilice el gestor de claves para colocar el certificado en la base de datos de claves donde ha creado la petición de certificado original.

La documentación más detallada sobre IBM Key Manager e IBM Global Security Kit (GSKit) se empaqueta con el software GSKit.

Configure el sistema para que ejecute el gestor de claves

Antes de iniciar la GUI de iKeyman, realice las acciones siguientes:
  1. Instale IBM JDK versión 1.6 o superior. Puede utilizar el paquete Java que se suministra con el producto Load Balancer.
  2. Establezca JAVA_HOME en la ubicación del directorio Java. Por ejemplo:
    • Para plataformas Windows:
      set JAVA_HOME=C:\Program Files\IBM\edge\lb\java
    • Para plataformas AIX®, HP-UX, Linuxy Solaris:
       export JAVA_HOME=/opt/ibm/edge/lb/java/
  3. Registre los proveedores de servicios IBM JCE, IBM CMSe IBMJCEFIPS.

    Actualice el archivo JAVA_HOME/jre/lib/security/java.security para añadir los proveedores IBM CMS e IBM JCE en las posiciones que se muestran en el ejemplo siguiente:

    security.provider.1=com.ibm.jsse2.IBMJSSEProvider2
    security.provider.2=com.ibm.security.cmskeystore.CMSProvider
    security.provider.3=com.ibm.crypto.provider.IBMJCE
    security.provider.4=com.ibm.security.jgss.IBMJGSSProvider
    security.provider.5=com.ibm.security.cert.IBMCertPath

  4. Para habilitar la operación FIPS, actualice el archivo JAVA_HOME/jre/lib/security/java.security para que también añada IBMJCEFIPS. Asegúrese de registrar al proveedor IBMJCEFIPS con una prioridad mayor que IBMJCE. Por ejemplo:
    security.provider.1=com.ibm.jsse2.IBMJSSEProvider2
    security.provider.2=com.ibm.security.cmskeystore.CMSProvider
    security.provider.3=com.ibm.crypto.fips.provider.IBMJCEFIPS
    security.provider.4=com.ibm.crypto.provider.IBMJCE
  5. Opcional: Si utiliza hardware criptográfico, registre el proveedor de servicios IBMPKCS11Impl. Por ejemplo:
    security.provider.1=com.ibm.jsse2.IBMJSSEProvider2
    security.provider.2=com.ibm.security.cmskeystore.CMSProvider
    security.provider.3=com.ibm.crypto.fips.provider.IBMJCEFIPS
    security.provider.4=com.ibm.crypto.provider.IBMJCE
    security.provider.5=com.ibm.crypto.pkcs11Impl.provider.IBMPKCS11Impl
    security.provider.6=com.ibm.security.jgss.IBMJGSSProvider
    security.provider.7=com.ibm.security.cert.IBMCertPath

Inicio del gestor de claves

Inicie la interfaz gráfica de usuario del gestor de claves ejecutando la herramienta iKeyman desde JDK. Por ejemplo, utilice el mandato siguiente:

/opt/ibm/edge/lb/java/jre/bin/ikeyman

Creación de un par de claves y una petición de certificados nuevos

La base de datos de claves almacena pares de claves y peticiones de certificado. Para crear un par de claves pública y privada y una petición de certificado, siga los pasos siguientes:
  1. Si no ha creado la base de datos de claves, siga las instrucciones de Creación de una nueva base de datos de claves, contraseña y archivo de ocultación.
  2. En el programa de utilidad de gestión de claves, en el menú principal, pulse Base de datos de claves -> Archivo -> Abrir.
  3. En el recuadro de diálogo Abrir (Abrir), escriba el nombre de la base de datos de claves o pulse key.kdb si está utilizando el valor por omisión. Pulse Aceptar.
  4. En el recuadro de diálogo Password Prompt (Solicitud de contraseña), escriba la contraseña y pulse OK (Aceptar).
  5. En el menú principal, pulse Crear -> Nueva solicitud de certificado.
  6. En el recuadro de diálogo New Key and Certificate Request (Nueva clave y petición de certificado), especifique la siguiente información:
    • Key Label (Etiqueta de clave): escriba un nombre (etiqueta) que se utilice para identificar la clave y el certificado de la base de datos, por ejemplo, my self-signed certificate o www.companyA.com.
    • Tamaño de clave: tamaño de la clave, por ejemplo, 1024. Para beneficiarse de un cifrado de 128-bit bits, se recomienda un tamaño de 1024.
    • Organization Name (Nombre de la organización): nombre de la organización que se va a asociar con la clave, por ejemplo, Company A.
    • Organization Unit (Unidad organizativa) (opcional)
    • Localidad (Opcional)
    • State/Province (Estado/Provincia) (opcional)
    • Zipcode (Opcional)
    • Country (País): código del país. Debe especificar dos caracteres como mínimo, por ejemplo, US.
    • Certificate request file name (Nombre de archivo de petición de certificado): nombre del archivo de petición. Opcionalmente, se puede utilizar un nombre por omisión.
  7. Pulse Aceptar. Se visualizará un mensaje de confirmación:
    A new certificate request has been successfully created 
in the file 
                        keyfile_database_name
                     .
  8. Pulse Aceptar. Se visualizará el nombre de etiqueta que ha especificado bajo la cabecera Personal Certificate Requests (Peticiones de certificados personales).
  9. En el cuadro de diálogo Información , pulse Aceptar. Se le recuerda que envíe el archivo a una autoridad certificadora.
  10. A menos que haya creado un certificado autofirmado, envíe la solicitud de certificado a una CA:
    • Deje el gestor de despliegue en ejecución.
    • Inicie un navegador web y especifique el URL de la CA de la que desea obtener el certificado.
    • Siga las instrucciones facilitadas por la CA para enviar la petición de certificado.
    Las peticiones de certificado pueden tardar de dos a tres semanas en satisfacerse. Mientras espera a que la CA procese la solicitud de certificado, puede actuar como su propia CA y utilizar iKeyman para crear un certificado de servidor autofirmado para habilitar las sesiones SSL entre los clientes y el servidor Caching Proxy .

Creación de un certificado autofirmado

Utilice el programa de utilidad de gestión de claves para crear un certificado de servidor autofirmado para habilitar las sesiones SSL entre los clientes y el servidor proxy mientras se espera que se envíe un certificado. Asimismo, puede utilizar certificados autofirmados sólo para pruebas.

Siga este procedimiento para crear un certificado autofirmado:
  1. Si no ha creado la base de datos de claves, siga las instrucciones de Creación de una nueva base de datos de claves, contraseña y archivo de ocultación.
  2. En el programa de utilidad de gestión de claves, en el menú principal, pulse Base de datos de claves -> Archivo -> Abrir.
  3. En el recuadro de diálogo Open (Abrir), escriba el nombre de la base de datos de claves o acepte el valor por omisión, key.kdb. Pulse Aceptar.
  4. En el recuadro de diálogo Password Prompt (Solicitud de contraseña), escriba la contraseña y pulse OK (Aceptar).
  5. En el marco de contenido Key Database (Base de datos de claves), seleccione Personal Certificates (Certificados personales) y pulse Create New Self-Signed Certificate (Crear certificado autofirmado nuevo).
  6. En la ventana Create New Self-Signed Certificate (Crear certificado autofirmado nuevo), especifique la siguiente información:
    • Key Label (Etiqueta de clave): nombre (etiqueta) que se utilice para identificar la clave y el certificado de la base de datos, por ejemplo, my self-signed certificate.
    • Tamaño de clave: tamaño de la clave, por ejemplo, 512.
    • Common Name (Nombre común): nombre completo del host de servidor, por ejemplo, www.myserver.com
    • Organization Name (Nombre de la organización): nombre de la organización que se va a asociar con la clave, por ejemplo, Company A
    • Organization Unit (Unidad organizativa) (opcional)
    • Localidad (Opcional)
    • State/Province (Estado/Provincia) (opcional)
    • Zipcode (Opcional)
    • Country (País): código del país. Debe especificar dos caracteres como mínimo, por ejemplo, US.
    • Período de validez: período de tiempo que el certificado es válido.
  7. Pulse Aceptar.
  8. Registre la base de datos de claves con el servidor añadiendo el archivo de claves y el archivo de ocultación a los valores de configuración (consulte Creación de una nueva base de datos de claves, contraseña y archivo de ocultación).

Exportación de claves

Utilice este procedimiento para exportar claves a otra base de datos de claves:
  1. Inicie el programa de utilidad de gestión de claves.
  2. En el menú principal, pulse Archivo de base de datos de claves -> Abrir.
  3. En el recuadro de diálogo Open (Abrir), escriba el nombre de la base de datos de claves o acepte el valor por omisión, key.kdb. Pulse Aceptar.
  4. En el recuadro de diálogo Password Prompt (Solicitud de contraseña), escriba la contraseña y pulse OK (Aceptar).
  5. En el marco de contenido Key Database (Base de datos de claves), seleccione Personal Certificates (Certificados personales) y, a continuación, pulse el botón Export/Import (Exportar/Importar) en la etiqueta.
  6. En la ventana Export/Import Key (Exportar/Importar clave):
    • Seleccione Exportar clave.
    • Seleccione el tipo de base de datos de destino (por ejemplo, PKCS12 ).
    • Escriba el nombre de archivo o pulse Browse (Explorar) para seleccionarlo.
    • Escriba la ubicación correcta.
  7. Pulse Aceptar.
  8. En el recuadro de diálogo Password Prompt (Solicitud de contraseña), escriba la contraseña correcta, escriba la contraseña de nuevo para confirmarla y, a continuación, pulse OK (Aceptar) para exportar la clave seleccionada a otra base de datos de claves.

Importación de claves

Para importar claves de otra base de datos de claves:
  1. Inicie el programa de utilidad de gestión de claves.
  2. En el menú principal, seleccione Archivo de base de datos de claves -> Abrir.
  3. En el recuadro de diálogo Open (Abrir), escriba el nombre de la base de datos de claves o acepte el valor por omisión, key.kdb. Pulse Aceptar.
  4. En el recuadro de diálogo Password Prompt (Solicitud de contraseña), escriba la contraseña correcta y pulse OK (Aceptar).
  5. En el marco de contenido Key Database (Base de datos de claves), seleccione Personal Certificates (Certificados personales) y, a continuación, pulse el botón Export/Import (Exportar/Importar) en la etiqueta.
  6. En la ventana Export/Import Key (Exportar/Importar clave):
    • Seleccione Importar clave.
    • Seleccione el tipo de archivo de base de datos de claves (por ejemplo, PKCS12).
    • Escriba el nombre de archivo o pulse Browse (Explorar) para seleccionarlo.
    • Seleccione la ubicación correcta.
  7. Pulse Aceptar.
  8. En el recuadro de diálogo Password Prompt (Solicitud de contraseña), escriba la contraseña correcta y pulse OK (Aceptar).
  9. En la lista Select from Key Label (Seleccionar de etiqueta de clave), seleccione el nombre de etiqueta correcto y pulse OK (Aceptar).

Listado de autoridades certificadoras

Para visualizar una lista de las autoridades certificadoras (CA) de confianza en la base de datos de claves:
  1. Inicie el programa de utilidad de gestión de claves.
  2. En el menú principal, pulse Archivo de base de datos de claves -> Abrir.
  3. En el recuadro de diálogo Open (Abrir), escriba el nombre de la base de datos de claves o acepte el valor por omisión, key.kdb. Pulse Aceptar.
  4. En el recuadro de diálogo Password Prompt (Solicitud de contraseña), escriba la contraseña correcta y pulse OK (Aceptar).
  5. En el marco de contenido Key Database (Base de datos de claves), seleccione Signer Certificates (Certificados de firmante).
  6. Pulse Signer Certificates (Certificados de firmante), Personal Certificates (Certificados personales) o Certificate Requests (Peticiones de certificados) para ver la lista de las CA en la ventana Key Information (Información de claves).

Utilice este procedimiento para recibir un certificado que se le envíe electrónicamente desde una entidad emisora de certificados (CA) designada como CA de confianza de forma predeterminada (consulte la lista en Entidades emisoras de certificados). Si la CA que emite el certificado firmado por CA o no es una CA de confianza en la base de datos de claves, primero debe almacenar el certificado de la CA y designar la CA como una CA de confianza. A continuación, ya puede recibir el certificado firmado por CA en la base de datos. No puede recibir un certificado firmado por CA de una CA que no sea una CA de confianza (consulte Almacenamiento de un certificado de CA).

Para recibir un certificado firmado por CA en una base de datos de claves:
  1. Inicie el programa de utilidad de gestión de claves.
  2. En el menú principal, seleccione Archivo de base de datos de claves -> Abrir.
  3. En el recuadro de diálogo Open (Abrir), escriba el nombre de la base de datos de claves o acepte el valor por omisión, key.kdb. Pulse Aceptar.
  4. En el recuadro de diálogo Password Prompt (Solicitud de contraseña), escriba la contraseña y pulse OK (Aceptar).
  5. Asegúrese de que el nombre de archivo del listado DB-Type (Tipo-BD) es correcto.
  6. En la ventana Key Database ((Base de datos de claves), seleccione Personal Certificates (Certificados personales) y, a continuación, pulse Receive (Recibir).
  7. En el recuadro de diálogo Receive Certificate from a File (Recibir certificado de un archivo), escriba el nombre de un archivo codificado en Base 64 válido en el campo de texto Certificate filename (Nombre de archivo de certificados). Pulse Aceptar.
  8. Para cerrar el programa de utilidad del gestor de claves, en el menú principal, pulse Archivo de base de datos de claves -> Salir.

Visualización de la clave por omisión en una base de datos de claves

Visualice la entrada de clave por omisión como se indica a continuación:
  1. Inicie el programa de utilidad de gestión de claves.
  2. En el menú principal, pulse Archivo de base de datos de claves -> Abrir.
  3. En el recuadro de diálogo Open (Abrir), escriba el nombre de la base de datos de claves o acepte el valor por omisión, key.kdb. Pulse Aceptar.
  4. En el recuadro de diálogo Password Prompt (Solicitud de contraseña), escriba la contraseña y pulse OK (Aceptar).
  5. En el marco de contenido Key Database (Base de datos claves), seleccione Personal Certificates (Certificados personales) y seleccione el nombre de etiqueta del certificado de CA.
  6. En la ventana Key Information (Información de claves), pulse View/Edit (Ver/Editar) para visualizar la información de claves por omisión del certificado.

Creación de una nueva base de datos de claves, una contraseña y un archivo stash

Una base de datos de claves es un archivo que el servidor utiliza para almacenar uno o más pares de claves y certificados. Puede utilizar una base de datos de claves para todos los pares de claves y certificados o crear varias bases de datos. El programa de utilidad de gestión de claves se utiliza para crear nuevas bases de datos de claves y especificar sus contraseñas y archivos stash.

Para crear una base de datos de claves y un archivo stash:
  1. Inicie el programa de utilidad de gestión de claves.
  2. En el menú principal, seleccione Archivo de base de datos de claves -> Nuevo.
  3. En el nuevo New (Nuevo), asegúrese de que está seleccionado el tipo de archivo CMS Key Database (Base de datos de claves CMS). Escriba el nombre de base de datos de claves y la ubicación del archivo o acepte el valor por omisión key.kdb. Pulse Aceptar.
  4. En el recuadro de diálogo Password Prompt (Solicitud de contraseña), escriba y confirme la contraseña de esta base de datos. Haga clic en Aceptar.
  5. Seleccione el recuadro de selección para ocultar el archivo de contraseñas. Cuando se le solicite, escriba y confirme una contraseña para su verificación. Se muestra el mensaje siguiente: DB-Type: CMS key database file keyfile_database_name
    Nota: Si no oculta el archivo de contraseñas, el servidor se inicia pero no escucha en el puerto 443.

La contraseña que especifique cuando cree una base de datos de claves nueva protege la clave privada. La clave privada es la única clave que puede firmar documentos o descifrar mensajes cifrados con la clase pública.

Siga las siguientes directrices cuando especifique la contraseña:
  • La contraseña debe estar formada por el juego de caracteres de inglés americano.
  • La contraseña debe tener seis caracteres como mínimo y contener al menos dos números no consecutivos. Asegúrese de que la contraseña no contenga información personal que se pueda obtener públicamente como, por ejemplo, su nombre, iniciales o fecha de nacimiento o los de sus familiares mas cercanos.
  • Oculte la contraseña.

Es aconsejable modificar la contraseña de base de datos de claves con frecuencia. No obstante, si especifica una fecha de caducidad para la contraseña, registre cuándo debe modificarse. Si la contraseña caduca antes de modificarla, se escribe un mensaje en las anotaciones cronológicas de error y se inicia el servidor, pero no puede realizar conexiones de red seguras.

Siga estos pasos para modificar la contraseña de base de datos de claves:
  1. En el menú principal, pulse Archivo de base de datos de claves -> Abrir.
  2. En el recuadro de diálogo Open (Abrir), escriba el nombre de la base de datos de claves o acepte el valor por omisión, key.kdb. Pulse Aceptar.
  3. En el recuadro de diálogo Password Prompt (Solicitud de contraseña), escriba la contraseña establecida y pulse OK (Aceptar).
  4. En el menú principal, pulse Archivo de base de datos de claves -> Cambiar contraseña.
  5. En el recuadro de diálogo Change Password (Modificar contraseña), escriba y confirme una contraseña nueva. Haga clic en Aceptar.

Para realizar una conexión SSL entre un proxy y un servidor LDAP, introduzca la contraseña de base de datos de claves en el archivo pac_keyring.pwd. (El archivo pac_keyring.pwd no es el archivo stash generado por iKeyman.)

Recepción de un certificado de CA

Utilice este procedimiento para recibir un certificado que se le envíe electrónicamente desde una autoridad certificadora (CA) que esté designada como una CA de confianza por omisión en la lista de entidades emisoras de certificados. Si la CA que emite el certificado firmado por CA o no es una CA de confianza en la base de datos de claves, primero debe almacenar el certificado de la CA y designar la CA como una CA de confianza. A continuación, puede recibir el certificado firmado por CA en la base de datos.

No puede recibir un certificado firmado por una CA de una CA que no sea fiable. Consulte Almacenamiento de un certificado de CA.

Para recibir un certificado firmado por CA en una base de datos de claves:

  1. Inicie el programa de utilidad de gestión de claves.
  2. En el menú principal, seleccione Archivo de base de datos de claves > Abrir.
  3. En el recuadro de diálogo Open (Abrir), escriba el nombre de la base de datos de claves o acepte el valor por omisión, key.kdb. Pulse Aceptar.
  4. En el recuadro de diálogo Password Prompt (Solicitud de contraseña), escriba la contraseña y pulse OK (Aceptar).
  5. Asegúrese de que el nombre de archivo del listado DB-Type (Tipo-BD) es correcto.
  6. En la ventana Key Database ((Base de datos de claves), seleccione Personal Certificates (Certificados personales) y, a continuación, pulse Receive (Recibir).
  7. En el recuadro de diálogo Receive Certificate from a File (Recibir certificado de un archivo), escriba el nombre de un archivo codificado en Base 64 válido en el campo de texto Certificate filename (Nombre de archivo de certificados). Pulse Aceptar.
  8. Para cerrar el programa de utilidad del gestor de claves, en el menú principal, pulse Archivo de base de datos de claves > Salir.

Almacenamiento de un certificado de CA

Sólo los certificados firmados por las CA de confianza se aceptan para establecer conexiones seguras. Para añadir una CA a la lista de autoridades de confianza, debe obtener y almacenar el certificado como de confianza.

Siga este procedimiento para almacenar un certificado de una CA nueva, antes de recibirlo en la base de datos:
  1. Inicie el programa de utilidad de gestión de claves.
  2. En el menú principal, pulse Archivo de base de datos de claves > Abrir.
  3. En el recuadro de diálogo Open (Abrir), escriba el nombre de la base de datos de claves o acepte el valor por omisión, key.kdb. Pulse Aceptar.
  4. En el recuadro de diálogo Password Prompt (Solicitud de contraseña), escriba la contraseña y pulse OK (Aceptar).
  5. En el marco de contenido Key Database (base de datos de clave), seleccione Signer Certificates (Certificados de firmante) y, a continuación, pulse Add (Añadir).
  6. En el recuadro de diálogo Add CA's Certificate from a File (Añadir certificado de CA de un archivo), seleccione el nombre de archivo de certificado de datos codificados en Base 64 o utilice la opción Examinar (Examinar). Pulse Aceptar.
  7. En el recuadro de diálogo Label (Etiqueta), escriba el nombre de etiqueta y pulse OK (Aceptar).
  8. Utilice el recuadro de selección para designar el certificado como de confianza (por omisión).
    Nota: Vea el recuadro de selección después de crear el certificado utilizando el botón "Ver/Editar". El recuadro de selección aparecerá en el panel pero no se visualizará durante la adición del certificado.

Especificaciones de cifrado soportadas

Los algoritmos de cifrado y hashes utilizados para SSL versiones 2 y 3 aparecen enumerados en las tablas siguientes.

Generación de pares de claves: tamaños de clave pública de RSA 512–1024

Tabla 1. SSL Versión 2. Versiones de Estados Unidos y de exportación para SSL versión 2.
Versión de Estados Unidos Versión de exportación
RC4 US RC4 Export
RC2 US RC2 Export
DES 56-bit no aplicable
Triple DES US no aplicable
RC4 Export no aplicable
RC2 Export no aplicable
Tabla 2. SSL Versión 3. Versiones de Estados Unidos y de exportación para SSL versión 3.
Versión de Estados Unidos Versión de exportación
Triple DES SHA US DES SHA Export
DES SHA Export RC2 MD5 Export
RC2 MD5 Export RC4 MD5 Export
RC4 SHA US NULL SHA
RC4 MD5 US NULL MD5
RC4 MD5 Export NULL NULL
RC4 SHA 56 bits no aplicable
DES CBC SHA no aplicable
NULL SHA no aplicable
NULL MD5 no aplicable
NULL NULL no aplicable

Estas especificaciones SSL también pueden configurarse editando directamente el archivo de configuración de proxy. Para obtener detalles, consulte las secciones de referencia en Directivas de archivo de configuración.

Cifrado de 128 bits para Caching Proxy

Sólo se entrega una versión de cifrado de 128 bits de Caching Proxy . Ya no se puede acceder a la versión de 56 bits. Si está actualizando una versión anterior, puede instalar Caching Proxy directamente en la versión de 128 bits o 56 bits instalada actualmente. Si previamente utilizaba un navegador de 56 bits (de exportación), debe actualizarlo a un navegador de 128 bits para aprovechar el cifrado de 128 bits del proxy.

Después de una actualización de una versión de 56 bits de Caching Proxy a la versión de 128 bits, si el tamaño de clave utilizado para cifrar certificados se establece en 1024, no es necesario ningún cambio de configuración. No obstante, si el tamaño de clave se establece en 512, para aprovechar el cifrado de 128 bits del proxy, debe crear nuevos certificados con un tamaño de clave de 1024. Cree nuevas claves utilizando el programa de utilidad IBM Key Manager (iKeyman).
  1. Inicie el gestor de claves. Por ejemplo, utilice el mandato siguiente:
    /opt/ibm/edge/lb/java/jre/bin/ikeyman
  2. En el menú principal, pulse Archivo de base de datos de claves -> Abrir.
  3. En el recuadro de diálogo Open (Abrir), escriba el nombre de la base de datos de claves o pulse key.kdb si está utilizando el valor por omisión, y pulse OK (Aceptar).
  4. Si el recuadro de diálogo Password Prompt se abre, escriba la contraseña y pulse OK (Aceptar).
  5. En el menú principal, pulse Crear -> Nueva solicitud de certificado.
  6. En la ventana New Key and Certificate Request (Nueva clave y petición de certificado), especifique la siguiente información:
    • Key Label (Etiqueta de clave): escriba un nombre que se utilice para identificar la clave y el certificado de la base de datos.
    • Tamaño de clave: seleccione 1024.
    • Organization Name (Nombre de la organización): escriba el nombre de la organización que se vaya a asociar con la clave.
    • Country (País): escriba el código del país. Debe especificar dos caracteres como mínimo, por ejemplo, US.
    • Certificate request file name (Nombre de archivo de petición de certificado): escriba un nombre para el archivo de petición, u opcionalmente, utilice un nombre por omisión.
  7. Pulse Aceptar.

Esta versión del producto no da soporte al cifrado en SUSE Linux.