Cuando Apache arranca tiene que leer varios ficheros Certificado (vea SSLCertificateFile) y Clave Privada (vea SSLCertificateKeyFile) de los servidores virtuales que tienen SSL activado. Por razones de seguridad los ficheros de clave privada están generalmente cifrados, mod_ssl necesita preguntar al administrador por la contraseña para desencriptar esos ficheros. Esta solicitud puede hacerse de dos maneras que se pueden configurar por tipo:

• builtin

  Este es el método por defecto donde una ventana de terminal interactiva aparece al inicio antes que Apache pase a segundo plano. Aquí un administrador tiene que introducir manualmente la contraseña para cada fichero de Clave Privada cifrado. Puesto que puede haber muchos hosts virtuales configurados con SSL, se usa el siguiente esquema de reutilización para minimizar el número de veces que se pide la contraseña: Cuanto un fichero de clave privada está encriptado, se intentará usar todas las Contraseñas conocidas (al principio no hay ninguna, por supuesto). Si una de esas contraseñas conocidas funciona no se abre ventana de diálogo para este fichero de clave privada en particular. Si ninguna funciona, se vuelve a solicitar la contraseña en la terminal y se recuerda para las siguientes (donde quizás se pueden reutilizar).

  Este esquema permite a mod_ssl ser flexible al máximo (porque para N ficheros de Clave Privada cifrados usted puede usar N contraseñas diferentes - pero entonces tiene que introducir todas ellas, por supuesto) al mismo tiempo que se minimizan las solicitudes de contraseña por terminal (p.ej. cuando usa una sola contraseña para todos los N ficheros de Clave Privada esta contraseña sólo se pide una vez).

• |/path/to/program [args...]

  Este modo permite que se use un programa externo que actúa como tubería a un dispositivo de entrada en particular; al programa se le envía la solicitud estándar de texto que se usa para el modo builtin en stdin, y se espera que escriba cadenas de caracteres de contraseñas en stdout. Si se necesitan varias contraseñas (o si se introduce una contraseña incorrecta), se escribirán solicitudes de contraseña adicionales y se tendrá que devolver más contraseñas a través de dicho programa.

• exec:/path/to/program

  Aquí se configura un programa externo que se lanza en el arranque para cada uno de los ficheros de Clave Privada encriptados. Se le llama con un sólo parámetro, una cadena de caracteres de la forma ``servername:portnumber:index'' (cuando index es un número basado en una secuencia de ceros), que indica para qué servidor, puerto TCP y número de certificado debe imprimir la Contraseña correspondiente a stdout. La intención es que este programa externo primero ejecuta comprobaciones de seguridad para asegurar que el sistema no se ha visto comprometido por un atacante, y sólo cuando estas comprobaciones se realizan satisfactoriamente entonces facilita la Contraseña.

  Ambas comprobaciones de seguridad y el método en que se determina la contraseña, puede ser tan complejo como usted desee. Mod_ssl sólo define el interfaz: un programa ejecutable que provee la contraseña en stdout. Ni más y ni menos. Así que, si usted es realmente paranoico con la seguridad, este es su interfaz. Cualquier otra cosa se debe dejar como un trabajo para el administrador, porque los requerimientos de seguridad local son muy diferentes.

  El algoritmo de reutilización descrito previamente se usa aquí también. En otras palabras: se llama sólo una vez al programa externo cuando hay una única contraseña.

Esto configura una o más fuentes de generación de semilla pseudoaleatoria de números "Pseudo Random Number Generator (PRNG)" en OpenSSL en el arranque (contexto es startup) y/o justo antes de que se establezca una nueva conexión SSL (contexto es connect). Esta directiva sólo se puede usar en el contexto global de configuración del servidor porque PRNG es una característica global.

Las siguientes variante de fuente están disponibles:

• builtin

  Esta es siempre la fuente de generación de semilla que está siempre disponible. Usa el mínimo de ciclos de CPU en tiempo real así que se puede usar siempre sin contratiempos. La fuente utilizada para la generación de semilla de PRNG contiene la hora actual, el id de proceso actual y (cuando es aplicable) un extracto de 1KB escogido aleatoriamente de la estructura de scoreboard de Apache. La pega es que no es realmente una fuente muy compleja y en el momento del arranque (cuando el scoreboard todavía no está disponible) esta fuente sólo produce unos pocos bytes de entropía. Así que usted debería, al menos en el arranque, usar una fuente adicional de generación de semilla.

• file:/ruta/hacia/la/fuente

  Esta variante usa un fichero externo /ruta/hacia/la/fuente con la fuente de generación de semilla para PRNG. Cuando se especifica bytes, sólo los primeros bytes del número de bytes del fichero forman la entropía (y bytes se da a /ruta/hacia/la/fuente como el primer parámetro). Cuando no se especifica bytes el fichero al completo forma la entropía (y 0 se da a /ruta/hacia/la/fuente como primer parámetro). Use esto especialmente en el arranque, por ejemplo con dispositivos disponibles /dev/random y/o /dev/urandom (que generalmente existen en derivados de Unix modernos como FreeBSD y Linux).

  Pero tenga cuidado: Generalmente /dev/random facilita sólo tantos datos de entropía como tiene en ese momento, p.ej. cuando solicita 512 bytes de entropía, pero el dispositivo sólo tiene 100 bytes disponibles dos cosas pasan: En algunas plataformas recibe sólo 100 bytes mientras que en otras plataformas la lectura se bloquea hasta que hay suficientes bytes disponibles (lo cual puede llevar bastante tiempo). Aquí usar un /dev/urandom existente es mejor, porque nunca bloquea y porque facilita la cantidad de datos solicitada. La pega es que la calidad de los datos recibidos puede que no sea la mejor.

• exec:/ruta/al/programa

  Esta variante usa un ejecutable externo /ruta/al/programa como la fuente de generación de semilla de PRNG. Cuando se especifica bytes, sólo los primeros bytes del número de bytes de su contenido de stdout forman la entropía. Cuando no se especifica bytes, el total de los datos producidos en stdout forman la entropía. Use esto sólo en el tiempo de arranque cuando necesita una generación de semilla muy compleja con la ayuda de un programa externo (como en el ejemplo de más arriba con la utilidad truerand que puede encontrar en la distribución de mod_ssl que está basada en la librería truerand de AT&T). Usar esto en contexto de conexión ralentiza al servidor de manera dramática, por supuesto. Así que debería evitar programas externos en ese contexto.

• egd:/ruta/al/egd-socket (Sólo Unix)

  Esta variante usa el socket de dominio Unix del Demonio de Recolección de Entropía externo (Entropy Gathering Daemon (EGD)) (vea http://www.lothar.com/tech /crypto/) para generar semilla de PRNG. Use esto si no hay un dispositivo de generación de datos aleatorios en su sistema.

Esto configura el tipo de almacenamiento para la Cache global/interproceso de la sesión SSL. Esta cache es una característica opcional que acelera el procesamiento de peticiones en paralelo. Para peticiones con el mismo proceso de servidor (a través de keep-alive HTTP), OpenSSL ya cachea la información de sesión de SSL localmente. Pero puesto que los clientes modernos solicitan imágenes y otros datos a través de peticiones en paralelo (generalmente hasta cuatro peticiones en paralelo es lo típico) esas peticiones se sirven por procesos de servidor diferentes. Aquí la cache de inter-proceso ayuda para evitar saludos de sesión SSL innecesarios.

Los cinto tipos de almacenamientos siguientes están soportados:

• none

  Esto desactiva la Cache de Sesión de interproceso/global. Esto repercutirá en un descenso de la velocidad notable y puede causar problemas con ciertos navegadores, particularmente si están activados los certificados cliente. Esta configuración no se recomienda.

• nonenotnull

  Esto sólo desactiva la Cache de Sesión de interproceso/global. Aun así no fuerza a OpenSSL a enviar ID de sesión no-nula para adaptarse a clientes que requieren una.

• dbm:/ruta/al/ficherodedatos

  Esto hace uso del fichero de hash DBM en el disco local para sincronizar las caches de memoria del OpenSSL de los procesos del servidor. Esta caché de sesión puede tener problemas de fiabilidad cuando hay carga alta. Para usarla, asegúrese de que mod_socache_dbm está cargado.

• shmcb:/ruta/al/ficherodedatos[(tamaño)]

  Esto hace uso del búfer cíclico de alto rendimiento (approx. tamaño bytes de tamaño) dentro de un segmento de memoria compartida en RAM (establecida con /ruta/al/ficherodedatos) para sincronizar las caches de memoria del OpenSSL local de los procesos del servidor. Esta es la caché de sesión recomendada. Para usarla, asegúrese de que mod_socache_shmcb está cargado.

• dc:UNIX:/ruta/al/socket

  Esto hace uso de las librerías de almacenamiento en caché de sesión distribuida.distcache. El parámetro debería especificar la ubicación del servidor o proxy para ser usado con distcache usando sintaxis de dirección; por ejemplo, UNIX:/ruta/al/socket especifica un socket de dominio UNIX (típicamente un proxy dc_client local); IP:server.example.com:9001 especifica una dirección IP. Para usar esto, asegúrese de que mod_socache_dc está cargado.

El mutex ssl-cache se usa para serializar el acceso a la cache de sesión para prevenir corrupción. Este mutex puede configurarse usando la directiva Mutex.

Esta directiva configura el tiemplo límite en segundos para la información guardada en la caché de sesión SSL de interproceso/global, la caché de memoria interna de OpenSSL y para las sesiones reanudadas por la reanudación de sesión de TLS (RFC 5077). Puede ponerse hasta un mínimo de 15 para hacer pruebas, pero debería configurarse con valores como 300 en entornos funcionales.

Esta directiva sirve para activar o desactivar el uso del motor del protocolo SSL/TLS. Los valores 'on', 'off' y 'optional' deberían usarse dentro de una sección VirtualHost para activar SSL/TLS para un host virtual. Por defecto el motor de SSL/TLS está deshabilitado para ambos el servidor principal y todos los host virtuales configurados.

Se deberían usar los valores addr:port en la configuración global del servidor para activar el motor del Protocolo SSL/TLS para todos los VirtualHost que coincidan con una de las direcciones de la lista.

SSLEngine puede ser configurado a optional: esto activa el soporte de RFC 2817.

Esta directiva activa o desactiva el uso de FIPS_mode en la librería SSL. Esto debe ponerse en el contexto de la configuración global del servidor y no puede configurarse con otras configuraciones que especifiquen lo contrario (SSLFIPS on seguido de SSLFIPS off o similar). Este modo se aplica a todas las operaciones de la librería SSL.

Si httpd fuera compilado contra una librería SSL que no soporta FIPS_mode, SSLFIPS on fallará. Vea el documento de Políticas de Seguridad FIPS 140-2 de su proveedor de librería SSL para requerimientos específicos para usar mod_ssl en un modo de operación aprobado; tenga en cuenta que mod_ssl en sí mismo no está validado, pero puede ser descrito como un módulo validado de criptografía FIPS 140-2, cuando todos los componentes son montados y gestionados bajo las reglas impuestas por la Política de Seguridad aplicable.

Se puede usar esta directiva para controlar que versiones del protocolo SSL/TLS serán aceptadas en las nuevas conexiones.

Los protocolos disponibles (no sensibles a mayúsculas) son:

• SSLv3

  Este es el protocolo de Secure Sockets Layer (SSL), versión 3.0, de la empresa Netscape. Es el sucesor a SSLv2 y el predecesor de TLSv1, pero se ha marcado ya como obsoleto en RFC 7568.

• TLSv1

  Este es el protocolo Transport Layer Security (TLS), versión 1.0. Es el sucesor de SSLv3 y está definido en RFC 2246. Está soportado por casi cualquier cliente.

• TLSv1.1 (cuando se usa OpenSSL 1.0.1 y posterior)

  Una revisión del protocolo TLS 1.0, tal y como se define en RFC 4346.

• TLSv1.2 (cuando se usa OpenSSL 1.0.1 y posterior)

  Una revisión del protocolo TLS 1.1, tal y como se define en RFC 5246.

• all

  Esto es un atajo para ``+SSLv3 +TLSv1'' o - cuando se usa OpenSSL 1.0.1 y posterior - ``+SSLv3 +TLSv1 +TLSv1.1 +TLSv1.2'', respectivamente (excepto para versiones de OpenSSL compiladas con la opción de configuración ``no-ssl3'', donde all no incluye +SSLv3).

Esta compleja directiva usa una cadena de cifrados separados por comas que consiste en especificaciones de cifrado OpenSSL para configurar el conjunto de cifrados que se le permite negociar al cliente en la fase de saludo SSL. Tenga en cuenta que esta directiva se puede usar en contexto de servidor y de directorio. En contexto de servidor aplica el saludo estándar de SSL cuando se establece una conexión. En contexto directorio fuerza una renegociación SSL con el juego de cifrados después de que la solicitud HTTP ha sido leída pero antes de que se envíe la respuesta.

Una especificación de cifrado SSL en especificación-de-cifrado se compone de 4 atributos principales más unos cuantos menores extra:

• Algoritmo de Intercambio de Clave:
  RSA, Diffie-Hellman, Elliptic Curve Diffie-Hellman, Secure Remote Password
• Algoritmo de Autenticación:
  RSA, Diffie-Hellman, DSS, ECDSA, or none.
• Algoritmo de Cifrado/Encriptación:
  AES, DES, Triple-DES, RC4, RC2, IDEA, etc.
• Algoritmo de Resúmen de MAC:
  MD5, SHA or SHA1, SHA256, SHA384.

Un cifrado SSL puede ser un cifrado export. Los cifrados SSLv2 ya no están soportados. Para especificar qué cifrados usar, uno puede especificar todos los cifrados a utilizar, de uno en uno, o puede usar alias para especificar la preferencia y orden de los cifrados (vea Tabla 1). La lista actual de cifrados y alias depende de la versión openssl utilizada. Versiones más modernas de openssl pueden incluir cifrados adicionales.

La parte en que ésto se vuelve interesante es que éstos se pueden poner juntos para especificar el orden y los cifrados que quiere usar. Para acelerar esto también hay pseudónimos (SSLv3, TLSv1, EXP, LOW, MEDIUM, HIGH) para ciertos grupos de cifrados. Estas etiquetas se pueden juntar con prefijos para formar especificación-de-cifrado. Los prefijos disponibles son:

• none: añade cifrado a la lista
• +: mueve los cifrados coincidentes a la ubicación actual en la lista
• -: borra los cifrados de la lista (se pueden añadir más adelante)
• !: mata el cifrado de la lista completamente (no puede añadirse después)

Una forma más sencilla de ver todo esto es usar el comando ``openssl ciphers -v'' que facilita una buena forma de crear una cadena correcta de especificación-de-cifrado. La cadena especificación-de-cifrado depende de la versión de librerías OpenSSL utilizadas. Supongamos que es ``RC4-SHA:AES128-SHA:HIGH:MEDIUM:!aNULL:!MD5'' que significa lo siguiente: Pon RC4-SHA y AES128-SHA al principio. Hacemos esto, porque estos cifrados ofrecen un buen compromiso entre velocidad y seguridad. Después, incluye los cifrados de seguridad alta y media. Finalmente, elimina todos los cifrados que no autentican, p.ej. para SSL los cifrados Anónimos Diffie-Hellman, así como todos los cifrados que usan MD5 como algoritmo de hash porque se ha probado que son insuficientes.

$ openssl ciphers -v 'RC4-SHA:AES128-SHA:HIGH:MEDIUM:!aNULL:!MD5'
RC4-SHA                 SSLv3 Kx=RSA      Au=RSA  Enc=RC4(128)  Mac=SHA1
AES128-SHA              SSLv3 Kx=RSA      Au=RSA  Enc=AES(128)  Mac=SHA1
DHE-RSA-AES256-SHA      SSLv3 Kx=DH       Au=RSA  Enc=AES(256)  Mac=SHA1
...                     ...               ...     ...           ...
SEED-SHA                SSLv3 Kx=RSA      Au=RSA  Enc=SEED(128) Mac=SHA1
PSK-RC4-SHA             SSLv3 Kx=PSK      Au=PSK  Enc=RC4(128)  Mac=SHA1
KRB5-RC4-SHA            SSLv3 Kx=KRB5     Au=KRB5 Enc=RC4(128)  Mac=SHA1

La lista completa de cifrados RSA & DH concretos para SSL se facilita en la Tabla 2.

Esta directiva apunta a un fichero con datos de certificado en formato PEM. Como mínimo, el fichero debe incluir un certificado final (no sólo CA a menos que sea autofirmado). La directiva puede usarse multiples veces (haciendo referencia a ficheros distintos) para dar soporte a múltiples algoritmos para la autenticación de servidor - típicamente RSA, DSA y ECC. El número de algoritmos soportados depende de la versión de OpenSSL utilizada por mod_ssl: con la versión 1.0.0 o posterior, openssl list-public-key-algorithms sacará una lista de algoritmos soportados, vea también la nota más adelante sobre limitaciones de versiones OpenSSL previas a 1.0.2 y la forma de sortearlas.

Los ficheros pueden también incluir certificados de CA intermedias, ordenados desde el certificado firmado hasta el certificado raíz. Esto está soportado con la versión 2.4.8 y posterior, y deja obsoleta la directiva SSLCertificateChainFile. Cuando se trabaja con OpenSSL 1.0.2 o posterior, esto permite que se configuren la cadena de CAs intermedias por certificado.

También se pueden añadir parámetros personalizados DH y un nombre de curva EC para claves efímeras al final del primer fichero configurado usando SSLCertificateFile. Esto está soportado en la versión 2.4.7 y posterior. Tales parámetros pueden ser generados usando los comandos openssl dhparam y openssl ecparam. Los parámetros se pueden añadir tal cual al final del primer fichero de certificado. sólo se puede usar el primer fichero para los parámetros personalizados, puesto que estos se aplican independientemente del tipo de algoritmo de autenticación.

Finalmente la clave privada del certificado también se puede añadir al fichero de certificado en lugar de usar por separado la directiva SSLCertificateKeyFile. Esta práctica está muy desaconsejada. Si se usa, los ficheros de certificado usando tales ficheros de claves embebidas deben configurarse después de los certificados que usan una clave privada en un fichero aparte. Si la clave privada está encriptada , el diálogo de solicitud de contraseña se fuerza en el arranque.

Esta directiva apunta al fichero de clave privada codificado en PEM para el servidor. Si la clave privada contenida en el fichero está encriptada, se forzará un diálogo de solicitud de contraseña en el arranque.

La directiva puede usarse múltiples veces (haciendo referencia a ficheros distintos) para dar soporte a múltiples algoritmos de autenticación para el servidor. Por cada directiva SSLCertificateKeyFile directive, debe haber una directiva SSLCertificateFile relacionada.

La clave privada se puede combinar con el certificado en el fichero indicado en SSLCertificateFile, pero esta práctica es muy desaconsejable. Si se usa, los ficheros de certificado con la clave privada dentro deben configurarse después de los certificados que tienen una clave privada en otro fichero.

Esta directiva configura el fichero todo-en-uno donde puede ensamblar los certificados de Autoridades de Certificación (CA - Certification Authorities) que forman la cadena del certificado del servidor. Este comienza con el certificado de la CA firmante del certificado del servidor y puede ir hasta el certificado de la CA raíz. Tal fichero es simplemente la concatenación de varios ficheros de Certificado CA codificado en PEM, generalmente siguiendo la cadena de certificación.

Esto debería usarse alternativamente y/o adicionalmente a SSLCACertificatePath para construir explicitamente la cadena de CA del certificado del servidor que se envía al navegador además del certificado del servidor. Es especialmente últil para evitar conflictos con certificados CA cuando se usa autenticación de cliente. Porque aunque colocar los CA de la cadena de certificados del servidor en SSLCACertificatePath tiene el mismo efecto para la construcción de la cadena de certificados, tiene un efecto adicional en la que los certificados cliente firmados por el mismo certificado CA también se aceptan en la autenticación de cliente.

Pero tenga cuidado: Proveer la cadena de certificados funciona sólo si está usando un sólo certificado de servidor basado en RSA o DSA. Si está usando un par de certificados juntos RSA+DSA, esto sólo funcionará si ambos certificados usan la misma cadena de certificados. Si no los navegadores se confundirán en esta situación.

Esta directiva configura el directorio donde guarda los certificados de Autoridades de Certificación (CAs) de los clientes que accederán a su servidor. Esto se usarán para verificar el certificado cliente en la Autenticación de Cliente.

Los ficheros en este directorio tienen que ser codificados en PEM y se acceden a través de nombres de ficheros con hash. Así que generalmente no puede poner simplemente los ficheros ahí: también tiene que crear enlaces simbólicos con nombre valor-hash.N. Y siempre debería asegurarse de que este directorio contiene los enlaces simbólicos apropiados.

Esta directiva configura el fichero todo-en-uno donde puede ensamblar los Certificados de las Autoridades de Certificación (CA) de los clientes que acceden a su servidor. Esto se usan para la Autenticación de Cliente. Tal fichero es sencillamente la concatenación, en orden de preferencia, de varios ficheros de Certificado codificados en PEM. Esto puede usarse alternativamente y/o adicionalmente a SSLCACertificatePath.

Cuando se solicita un certificado cliente por mod_ssl, una lista de nombres de Autoridad Certificadora aceptables se envía al cliente en el saludo SSL. Estos nombres de CA se pueden usar por el cliente para seleccionar un certificado cliente apropiado entre los que tiene disponibles.

Si no están las directivas SSLCADNRequestPath o SSLCADNRequestFile, entonces el conjunto de nombres aceptables de CA enviados al cliente es la de los nombres de todos los certificados de CA cargados en las directivas SSLCACertificateFile y SSLCACertificatePath; en otras palabras, los nombres de las CAs que se usarán actualmente para verificar el certificado cliente.

En algunas circunstancias, es útil poder enviar un conjunto de nombres de CA aceptables diferente de las CAs usadas para verificar el certificado cliente - por ejemplo, si los certificados cliente están firmados CAs intermedias. En tales casos, SSLCADNRequestPath y/o SSLCADNRequestFile se pueden usar; los nombres de CA aceptables se toman del conjunto completo de certificados en el directorio y/o fichero especificados por este par de directivas.

SSLCADNRequestFile debe especificar un fichero todo-en-uno que contenga una concatenación de certificados CA codificados en PEM.

Esta directiva opcional puede usarse para especificar un conjunto de nombres de CA aceptables que serán enviados al cliente cuando se solicita un certificado cliente. Vea la directiva SSLCADNRequestFile para más detalles.

Los ficheros en este directorio tienen que estar codificados en PEM y se accede a ellos con nombres de ficheros con hash. Así que generalmente no puede poner sin más los ficheros de Certificado ahí: también tiene que crear enlaces simbólicos llamados valor-de-hash.N. Y siempre debería estar seguro de que este directorio contiene los enlaces simbólicos apropiados.

Esta directiva configura el directorio donde usted alojará las Listas de Revocación de Certificados (CRL) de las Autoridades de Certificación (CAs) para los clientes que conectan al servidor. Estas se usan para revocar el certificado cliente en la Autenticación de Cliente.

Los ficheros en este directorio tienen que ser codificados en PEM y se accede a ellos con nombres de ficheros con hash. Así que generalmente no sólo tiene que poner los ficheros CRL ahí. Adicionalmente tiene que crear enlaces simbólicos llamados valor-de-hash.rN. Y debería asegurarse siempre que este directorio contiene los enlaces simbólicos apropiados.

Esta directiva configura el fichero todo-en-uno donde puede ensamblar las Listas de Revocación de Certificados (CRL) de las Autoridades de Certificación (CA) para los clientes que conectan a su servidor. Estos se usan para la Autenticación de Cliente. Tal fichero es simplemente la concatenación de varios ficheros CRL codificados en PEM, en orden de preferencia. Esto se puede usar alternativamente a/o adicionalmente a SSLCARevocationPath.

Activa la comprobación de la lista de revocación de certificados (CRL). Al menos SSLCARevocationFile o SSLCARevocationPath deben estar configuradas. Cuando se configuran a chain (configuración recomendada), las comprobaciones de CRL se aplican a todos los certificados en la cadena, mientras que si se configura a leaf limita las comprobaciones al certificado firmado final.

Los modificadores disponibles son:

• no_crl_for_cert_ok

  Previamente a la versión 2.3.15, la comprobación de CRL en mod_ssl también tenía éxito cuando no se encontraban CRL/s para los certificados comprobados en ninguna de las ubicaciones configuradas con SSLCARevocationFile o SSLCARevocationPath.

  Con la introducción de SSLCARevocationFile, el comportamiento ha cambiado: por defecto con chain o leaf, los CRLs deben estar presentes para que la validación tenga éxito, si no fallará con un error "unable to get certificate CRL".

  El modificador no_crl_for_cert_ok permite restaurar el comportamiento anterior..

Esta directiva configura el nivel de verificación de Certificado para la Autenticación de Cliente. Tenga en cuenta que esta directiva se puede usar tanto en contexto servidor como en contexto directorio. En contexto de servidor se aplica al proceso de autenticación de cliente usado en el saludo estándar de SSL cuando se establece una conexión. En el contexto directorio fuerza una renegociación SSL con el nivel de verificación reconfigurado después de que se lee la petiicón HTTP pero antes de que se responda la respuesta HTTP.

Los siguientes niveles están disponibles para nivel:

• none: no se requiere Certificado cliente ninguno
• optional: el cliente puede presentar un Certificado válido
• require: el cliente tiene que presentar un Certificado válido
• optional_no_ca: el cliente puede presentar un Certificado válido
  pero no tiene por qué ser verificable (satisfactoriamente). No se puede depender de esta opción para la autenticación de cliente.

Esta directiva configura hasta qué nivel debe mod_ssl verificar antes de decidir cuando los clientes no tienen un certificado válido. Tenga en cuenta que esta directiva puede usarse tanto en contexto servidor como en contexto directorio. En contexto servidor se aplica al proceso de autenticación de cliente en el salido SSL estándar cuando se establece una conexión. En el contexto directorio fuerza una renegociación SSL con la profundidad de verficiación de cliente reconfigurada después de que se lea la petición HTTP pero antes de que sé haya enviado la respuesta HTTP.

La profundidad es en realidad el número máximo de certificados CA intermedios, p. ej. el número de certificados CA máximo permitido a seguir en la verificación del certificado cliente. Una profundidad de 0 significa que sólo se aceptan los certificados cliente autofirmados, la profundidad por defecto de 1 significa que el cliente puede ser autofirmado o tiene que estar firmado por una CA que es directamente conocida por el servidor (p. ej. los certificados CA están bajo SSLCACertificatePath), etc.

Esta directiva activa TLS-SRP y configura la ruta al fichero verificador OpenSSL SRP (Secure Remote Password) que contiene nombres de usuario, verificadores, salts y parámetros de grupo TLS-SRP.

El fichero verificador puede generarse con la utilidad de línea de comandos openssl:

El valor dado con el parámetro opcional -userinfo está disponible en la variable de entorno de petición SSL_SRP_USERINFO.

Esta directiva configura la semilla usada para aparentar parámetros de usuario SRP para usuarios desconocidos, para evitar dar a conocer si el usuario facilitado existe, se especifica una cadena de caracteres secreta. Si no se usa esta directiva, entonces Apache deolverá la alerta UNKNOWN_PSK_IDENTITY a clientes que espcifican un nombre de usuario desconocido.

Esta directiva puede usarse para controlar varias opciones en tiempo real en contexto directorio. Normalmente, si múltiples SSLOptions pueden aplicar a un directorio, entonces se usará la más específica; las opciones no se fusionan. Sin embargo, si todas las opciones en la directiva SSLOptions están precedidas de un signo más (+) o menos (-), las opciones se fusionan. Cualquier opción precedida de un + es añadida a las opciones que se están aplicando en ese momento, y cualquier opción precedida de un - se elimina de las opciones aplicadas en ese momento.

Las opciones disponibles son:

• StdEnvVars

  Cuando esta opción está habilitada, se generan las variables de entorno estándar de SSL relacionadas con CGI/SSI. Esto está desactivado por defecto por razones de rendimiento, porque el paso de extracción de la información es una operación bastante costosa. Así que uno sólo activaría esta opción para peticiones CGI o SSI.

• ExportCertData

  Cuando se activa esta opción, se generan variables de entorno CGI/SSI adicionales: SSL_SERVER_CERT, SSL_CLIENT_CERT y SSL_CLIENT_CERT_CHAIN_n (con n = 0,1,2,..). Estas contienen los certificados X.509 codificados en PEM del servidor y el cliente para la conexión actual HTTPs y pueden usarse por scripts CGI para una comprobación más detallada de los Certificados. Adicionalmente también se facilitan todos los demás certificados de la cadena del certificado cliente. Esto carga el entorno de variables un poco, así que por esto deberá usar esta opción para activarla sólo cuando sea necesario.

• FakeBasicAuth

  Cuando se activa esta opción, el Nombre Distinguido de Sujeto (DN) del Certificado Cliente X509 se traduce a un nombre de Autenticación HTTP Básica. Esto significa que se pueden usar los métodos estándar de autenticación para control de acceso. El nombre de usuario es tan sólo el Sujeto del Certificado Cliente X509 (se puede determinar ejecutando el comando de OpenSSL openssl x509: openssl x509 -noout -subject -in certificado.crt). La directiva SSLUserName puede usarse para especificar qué parte del Sujeto del Certificado está embebida en el nombre de usuario. Tenga en cuenta que no se obtiene ninguna contraseña del usuario. Cada entrada en el fichero de usuario necesita esta contraseña: ``xxj31ZMTZzkVA'', que es la versión encriptada en DES de la palabra `password''. Aquellos que viven bajo la encriptación basada en MD5 (por ejemplo bajo FreeBSD or BSD/OS, etc.) debería usar el siguiente hash MD5 de la misma palabra: ``$1$OXLyS...$Owx8s2/m9/gfkcRVXzgoE/''.

  Tenga en cuenta que la directiva AuthBasicFake dentro de mod_auth_basic puede usarse como un mecanismo general para fingir la autenticación básica, dando control sobre la estructura tanto del nombre como de la contraseña.

  Los nombres de usuarios utilizados para FakeBasicAuth no deben incluir caracteres no-ASCII, caracteres de escape ASCII (tales como el de nueva línea), o una coma. Si se encuentra una coma, se generará un error 403 Forbidden con httpd 2.5.1 y posterior.

• StrictRequire

  Esto fuerza acceso prohibido cuando SSLRequireSSL o SSLRequire deciden satisfactoriamente que el acceso debería denegarse. Generalmente por defecto en el caso donde se usa una directiva ``Satisfy any'', y se pasan otras restricciones de acceso, se sobreescribe la denegación del acceso debido a SSLRequireSSL o SSLRequire (porque así es como debería funcionar el mecanismo Satisfy de Apache .) Pero para la restricción estricta de acceso puede usar SSLRequireSSL y/o SSLRequire en combinación con un ``SSLOptions +StrictRequire''. Entonces un ``Satisfy Any'' adicional no tiene oportunidad una vez que mod_ssl ha decidido denegar el acceso.

• OptRenegotiate

  Esto activa la gestión optimizada de renegociación de conexión SSL cuando se usan directivas SSL en contexto de directorio. Por defecto un esquema estricto está habilitado donde cada reconfiguración de directorio de parámetros SSL provoca una renegociación total del saludo SSL. Cuando se usa esta opción mod_ssl intenta evitar saludos SSL innecesarios haciendo comprobaciones más específicas (pero todavía seguras) de parámetros. Sin embargo estas comprobaciones más específicas pueden no ser lo que espera el usuario, así que, lo recomendable es que active ésto sólo en contexto directorio.

• LegacyDNStringFormat

  Esta opción influencia cómo se formatean los valores de las variables SSL_{CLIENT,SERVER}_{I,S}_DN. Desde la versión 2.3.11, Apache HTTPD usa un formato compatible RFC 2253 por defecto. Esto usa comas como delimitadores entre atributos, permite el uso de caracteres no-ASCII (que son convertidos a UTF-8), escapa varios caracteres especiales con barra invertida "\", y ordena los atributos con el atributo "C" al final.

  Si se activa LegacyDNStringFormat, el formato antiguo que ordena el atributo "C" el primero será utilizado, usa barras como separadores y no manipula caracteres no-ASCII y especiales de ninguna forma consistente.

Esta directiva prohibe el acceso a menos que esté habilitado HTTP sobre SSL (p. ej. HTTPS) para la conexión en cuestión. Esto es muy útil dentro de hosts virtuales con SSL activado o directorios, para defenderse de errores de configuración que exponen cosas que deberían estar protegidas. Cuando esta directiva está presente todas las peticiones que no usen SSL son denegadas.

Esta directiva especifica un requerimiento de acceso general que tiene que pasarse para que se permita el acceso. Es una directiva muy versátil porque la especificación del requerimiento es una compleja expresión booleana arbitraria que contiene cualquier número de comprobaciones.

La expresión debe coincidir en la siguiente sintaxis (dada una notación gramatical BNF):

expr     ::= "true" | "false"
           | "!" expr
           | expr "&&" expr
           | expr "||" expr
           | "(" expr ")"
           | comp

comp     ::= word "==" word | word "eq" word
           | word "!=" word | word "ne" word
           | word "<"  word | word "lt" word
           | word "<=" word | word "le" word
           | word ">"  word | word "gt" word
           | word ">=" word | word "ge" word
           | word "in" "{" wordlist "}"
           | word "in" "PeerExtList(" word ")"
           | word "=~" regex
           | word "!~" regex

wordlist ::= word
           | wordlist "," word

word     ::= digit
           | cstring
           | variable
           | function

digit    ::= [0-9]+
cstring  ::= "..."
variable ::= "%{" varname "}"
function ::= funcname "(" funcargs ")"

Para varname se puede usar cualquiera de las variables descritas en Variables de Entorno. Para funcname las funciones disponibles están listadas en la documentación de ap_expr.

La expresión es interpretada dentro de una representación interna de máquina cuando se carga la configuración, y es después evaluada durante el procesamiento de la petición. En contexto .htaccess, la expresión es en ambos casos interpretada y ejecutada cada vez que se encuentra un fichero .htaccess durante el procesamiento de la petición.

La función PeerExtList(object-ID) espera encontrar cero o más instancias de la extensión de certificado X.509 identificadas por un ID de objecto (OID) dado en el certificado cliente. La expresión se evalúa a cierta si la cadena de caracteres de la izquierda coincide exactamente contra el valor de la extensión identificada por este OID. (Si están presentes múltiples extensiones con el mismo OID, al menos uno debe coincidir).

Si se requiere una renegociación SSL por el contexto location, por ejemplo, cualquier uso de SSLVerifyClient en un bloque Directory o Location, entonces mod_ssl debe hacer búfer del cuerpo de la petición HTTP en memoria hasta que el nuevo saludo SSL puede realizarse. Esta directiva se puede usar para especificar la cantidad de memoria que se usará para este búfer.

Esta directiva configura si un cliente no-SNI tiene permiso para acceder a un host virtual basado en nombre. Si se configura a on en el host virtual por defecto basado en nombre, los clientes que no son compatibles con SNI no se les permitirá el acceso a ningún host virtual que pertenezca a esta combinación de ip/puerto. Si se configura a on en cualquier otro host virtual, los clientes no compatibles con SNI no tendrán acceso a ese host virtual en particular.

Esta directiva configura el directorio donde se guardan los certificados y claves usadas para la autenticación del servidor proxy en servidores remotos.

Los ficheros en este directorio deben ser codificados en PEM y accesibles con nombres de ficheros con hash. Además, debe crear enlaces simbólicos llamados valor-del-hash.N. Y siempre debería asegurarse de que este directorio contiene los enlaces simbólicos apropiados.

Esta directiva configura el fichero todo-en-uno donde guarda los certificados y claves usadas para la autenticación del servidor proxy en servidores remotos.

Este fichero es simplemente la concatenación de varios ficheros de certificado codificados en PEM, en orden de preferencia. Use esta directiva alternativamente o adicionalmente a SSLProxyMachineCertificatePath.

Esta directiva configura el fichero todo-en-uno donde guarda la cadena de certificados para todos los certificados cliente en uso. Esta directiva se necesitará si los servidores remotos presentan una lista de certificados CA que no son firmantes directos de uno de los certificados cliente configurados.

Este fichero es simplemente la concatenciación de varios ficheros de certificado codificado en PEM. En el arranque, cada certificado cliente configurado será examinado y se construirá una cadena de confianza.

Cuando se configura un proxy para enviar peticiones a un servidor remoto SSL, esta directiva se puede usar para configurar verificación de certificado del servidor remoto.

Los siguientes niveles están disponibles para nivel:

• none: No se requiere Certificado del servidor remoto para nada
• optional: el servidor remoto puede presentar un Certificado válido
• require: el servidor remoto tiene que presenta un Certificado válido
• optional_no_ca: el servidor remoto puede presentar un Certificado válido
  pero no tiene por qué ser verificable (con éxito).

En la práctica sólo los niveles none y require son realmente interesantes, porque el nivel optional no funciona en todos los servidores y el nivel optional_no_ca va actualmente contra la idea de autenticación (pero se puede usar para establecer páginas de test SSL, etc.)

Esta directiva configura hasta dónde mod_ssl debería verificar antes de decidir que el servidor remoto not tiene un certificado válido.

La profundidad actualmente es el número máximo de expedidores intermedios de certificados, p. ej. el número de certificados CA que se permiten seguir como máximo para verificar el certificado del servidor remoto. Una profundidad de 0 sigifnica que sólo se permiten certificados auto-firmados, la profundidad por defecto de 1 significa que el servidor remoto puede ser autofirmado o fimado por una CA que es directamente conocida por el servidor (p. ej. el certificado CA bajo SSLProxyCACertificatePath), etc.

Esta directiva configura si se debe comprobar si el certificado del servidor remoto está expirado o no. Si la comprobación falla se devuelve un error 502 (Bad Gateway).

Esta directiva configura si se debe comparar el campo CN del certificado del servidor remoto contra el nombre de host de la URL solicitada. Si ambos no son iguales se envía un código de estado 502 (Bad Gateway). SSLProxyCheckPeerCN ha sido sustituido por SSLProxyCheckPeerName en la versión 2.4.5 y posterior.

En todas las versiones desde 2.4.5 hasta 2.4.20, configurar SSLProxyCheckPeerName off era suficiente para activar este comportamiento (puesto que el valor por defecto de SSLProxyCheckPeerCN era on.) En estas versiones, ambas directivas deben configurarse a off para evitar completamente que se valide el nombre del certificado del servidor remoto. Muchos usuarios reportaron que esto es bastante confuso.

Desde la versión 2.4.21, todas las configuraciones que permiten una de las opciones SSLProxyCheckPeerName o SSLProxyCheckPeerCN usarán el nuevo comportamiento de SSLProxyCheckPeerName, y todas las configuraciones que deshabilitan una de las opciones de SSLProxyCheckPeerName o SSLProxyCheckPeerCN suprimirán la validación del nombre del certificado del servidor remoto. sólo la siguiente configuración habilitará la comparación antigua del CN en 2.4.21 y versiones posteriores;

Esta directiva configura la comprobación del nombre de host de certificados de servidor cuando mod_ssl está actuando como un cliente SSL. La comprobación tendrá éxito si el nombre de host de la petición coincide con uno de los CN del sujeto del certificado, o coincide con la extensión subjectAltName. Si la comprobación falla, la petición SSL se aborta y se devuelve un código de estado 502.

Se soportan coincidencias con certificados wildcard para casos específicos: una entrada subjectAltName del tipo dNSName, o atributos CN que comienzan con *. coincidirán con cualquier nombre de host del mismo número de elementos de nombre y el mismo sufijo. P. ej. *.example.org coinciderá con foo.example.org, pero no coincidirá con foo.bar.example.org, porque el número de elementos en el nombre de host respectivo es diferente.

Esta característica fue introducida en 2.4.5 y sustituye el comportamiento de la directiva SSLProxyCheckPeerCN, que sólo comprobaba el valor exacto en el primer atributo CN contra el nombre de host. Sin embargo, muchos usuarios estaban confundidos por el comportamiento de usar estas directivas individualmente, así que el comportamiento mutuo de las directivas SSLProxyCheckPeerName y SSLProxyCheckPeerCN fue mejorado en la versión 2.4.21. Vea la descripción de la directiva SSLProxyCheckPeerCN para el comportamiento original y detalles de estas mejoras.

Esta directiva activa el uso del motor de protocolo SSL/TLS para proxy. Esto se usa actualmente dentro de una sección VirtualHost para activar el uso de proxy con SSL/TLS en un host virtual en particular. Por defecto el Motor de Protocolo SSL/TLS está desactivado para tanto el servidor principal como todos los hosts virtuales.

Tenga en cuenta que la directiva SSLProxyEngine no debería en general, ser incluida en un host virtual que actuará como forward proxy (usando las directivas Proxy o ProxyRequests). SSLProxyEngine no es necesario para activar un servidor forward proxy para hacer proxy de peticiones SSL/TLS.

Esta directiva puede usarse para controlar los sabores de protocolo SSL que mod_ssl debería usar cuando establece si entorno de servidor para proxy. sólo conectará con servidores usando uno de sus protocolos facilitados.

Por favor vea SSLProtocol para información adicional.

Equivalente a SSLCipherSuite, pero para la conexión de proxy. Por favor consulte SSLCipherSuite para información adicional.

Esta directiva configura el directorio donde guarda los Certificados de Autoridades de Certificación (CAs) de los servidores remotos a los que conecta. Estos se usan para verificar el certificado del servidor remoto en la Autenticación de Servidor Remoto.

Los ficheros en este directorio tienen que estar codificados en PEM y se accede a ellos a través de nombres de ficheros con hash. Así que generalmente no puede tan sólo colocar los ficheros de Certificado ahí: también tiene que crear enlaces simbólicos llamados valor-de-hash.N. Y debería asegurarse siempre de que este directorio contiene los enlaces símbólicos apropiados.

Esta directiva configura el fichero todo-en-uno donde ensambla los Certificados de Autoridades de Certificación (CA) de los servidores remotos a los que conecta. Estos se usan como Autenticación de Servidor Remoto. Tal fichero es simplemente la concatenación de varios ficheros de Certificado codificados en PEM en orden de preferencia. Esto se puede usar alternativamente y/o adicionalmente a SSLProxyCACertificatePath.

Esta directiva configura el directorio donde se alojan las Listas de Revocación de Certificado (CRL) de las Autoridades de Certificación (CA) de los servidores a los que conecta. Estas se usan para revocar el certificado del servidor remoto en la Autenticación del Servidor Remoto.

Los ficheros en este directorio tienen que ser codificados en PEM y se acceden con nombres de ficheros con hash. Así que generalmente no sólo tiene que poner los ficheros CRL ahí. También tiene que crear enlaces simbólicos llamados valor-de-hash.rN. Y siempre debería asegurarse de que este directorio tiene los enlaces simbólicos apropiados.

Esta directiva configura el fichero todo-en-uno donde puede ensamblar las Listas de Revocación de Certificados (CRL) de las Autoridades de Certificación (CA) de los servidores remotos a los que conecta. Estos se usan para la Autenticación Remota de Servidor. Tal fichero es simplemente la concatenación de varios ficheros CRL codificados en PEM, en orden de preferencia. Esto se puede usar alternativamente a/o adicionalmente a SSLProxyCARevocationPath.

Activa la comprobación de listas de revocación de certificado (CRL) para los servidores remotos a los que conecta. Al menos una de las directivas SSLProxyCARevocationFile o SSLProxyCARevocationPath debe estar configurada. Cuando se configura a chain (configuración recomendada), las comprobaciones de CRL se aplican a todos los certificados en la cadena de certificación, mientras que configurándolo a leaf limita las comprobaciones al certificado firmado final.

Esta directiva configura el campo "usuario" en el objeto de solicitud de Apache. Esto se usa por módulos menores para identificar el usuario con una cadena de caracteres. En particular esto puede causar que la variable de entorno REMOTE_USER sea configurada. El nombre de variable puede ser cualquiera de las variables de entorno SSL.

Cuando se activa la opción FakeBasicAuth, esta directiva controla en su lgar el valor del nombre de usuario embebido dentro de la cabecera de autenticación básica (vea SSLOptions).

Cuando se selecciona un cifrado durante el saludo SSLv3 o TLSv1, normalmente se selecciona en función de las preferencias del cliente. Con esta directiva activada, se usará la preferencia del servidor en su lugar.

Esta directiva activa el uso de una placa hardware acelerador criptográfico para aliviar parte de la carga del procesamiento de SSL. Esta directiva sólo puede usarse si el kit de herramientas SSL está compilado con soporte de "engine"; OpenSSL 0.9.7 y posteriores versiones tienen soporte de "engine" por defecto, en versiones Openssl 0.9.6 debe usarse "-engine".

Para descubrir qué nombres de "engine" están soportados, ejecute el comando "openssl engine".

Esta opción activa la validación OCSP de la cadena de certificados del cliente. Si esta opción está activada, los certificados en la cadena de certificados del cliente se validarán contra un respondedor OCSP después de que se hayan hecho las verificaciones normales (incluidas las comprobaciones de CRL).

El respondedor OCSP utilizado o bien se extrae del mismo certificado, o derivado de la configuración; vea las directivas SSLOCSPDefaultResponder y SSLOCSPOverrideResponder directives.

Esta opción configura el respondedor OCSP por defecto a usar. Si SSLOCSPOverrideResponder no está activada, la URI facilitada se usará si no hay una URI de respondedor en el certificado que está siendo verificado.

Esta opción fuerza que se use el respondedor OCSP por defecto para la validación OCSP del certificado, independientemente de si el certificado que se está validando referencia un respondedor OCSP o no.

Esta opción configura el tiempo máximo permitido de desviación para las respuestas OCSP (cuando se están comprobando sus campos thisUpdate y nextUpdate).

Esta opción configura la edad máxima permitida de las respuestas OCSP. El valor por defecto (-1) no fuerza una edad máxima, lo que significa que las respuestas OCSP se consideran válidas mientras su campo nextUpdate está en una fecha futura.

Esta opción configura el tiempo de expiración para las consultas a los respondedores OCSP, cuando SSLOCSPEnable está activado.

Esta opción determina si las consultas a respondedores OCSP deberían contener un "nonce" o no. Por defecto, una consulta "nonce" siempre se comprueba y se usa contra la de la respuesta. Cuando el responderdor no usa "nonce"s (p.ej. Microsoft OCSP Responder), esta opción debería estar configuada a off.

Salta la verificación de certificados del respondedor OCSP, generalmente útil cuando se comprueba un servidor OCSP.

Esto aporta una lista de certificados confiables de respondedor OCSP para ser usados durante la validación de certificados de respondedor OCSP. Se confía en los certificados facilitados de manera implícita sin ninguna comprobación posterior. Esto se usa generalmente cuando el certificado del respondedor OCSP es autofirmado o se omite de la respuesta.

Esta opción permite configurar la URL de un proxy HTTP que debería usarse para todas las consultas a respondedores OCSP.

Tal y como se especificó originalmente, todas las versiones de protocolo SSL y TLS (incluído TLS/1.2) eran vulnerables a ataques tipo Man-in-the-Middle (CVE-2009-3555) durante una renegociación. Esta vulnerabilidad permitía a un atancante poner un prefijo a un texto plano específico en la petición HTTP tal y como se veía en el servidor web. Se desarrolló una extensión del protocolo para esta vulnerabilidad si estaba soportada tanto por el cliente como por el servidor.

Si mod_ssl está compilado contra la versión OpenSSL 0.9.8m o posterior, por defecto la renegociación sólo está soportada por clientes que tengan soporte para la nueva extensión del protocolo. Si esta directiva está activada, la renegociación se permitirá con los clientes antiguos (no parcheados), aunque de manera insegura.

La variable de entorno SSL_SECURE_RENEG se puede usar desde un script CGI o desde SSI para determinar si la renegociación segura está soportada para la conexión SSL en cuestión.

Esta opción activa el stapling de OCSP, tal y como se define en la extensión TLS "Solicitud de Estado de Certificado" especificada en el RFC 6066. Si está activado (y solicitado por el cliente), mod_ssl incluirá una respuesta OCSP de su propio certificado en el saludo TLS. Configurar una SSLStaplingCache es un pre-requisito para activar stapling de OCSP.

El stapling de OCSP releva al cliente de consultar el respondedor OCSP por si mismo, pero debería tenerse en cuenta que con la especificación RFC 6066, la respuesta de CertificateStatus del servidor podría sólo incluir una respuesta OCSP de un sólo certificado. Para los certificados de servidor con certificados de CA intermedias en su cadena (lo típico hoy en día), stapling en su implementación actual por tanto sólo consigue su objetivo parcialmente de "ahorrar varias peticiones y consumo de recursos" - vea también el RFC 6961 (Extensión de TLS del Estado de Múltiples Certificados).

Cuando el stapling de OCSP está activado, se usa el mutex ssl-stapling para controlar el acceso a la cahe de stapling de OCSP para prevenir corrupción, y se usa el mutex sss-stapling-refresh para controlar los refrescos a las respuestas OCSP. Estos mutexes pueden ser configurados usando la directiva Mutex.

Configura la cache utilizada para almacenar las respuestas OCSP que se incluyen en el saludo TLS si SSLUseStapling está activada. La coniguración de la cache es obligatoria para el stapling the OCSP. Con la excepción de none y nonenotnull, se da soporte a los mismos tipos de almacenamiento que con SSLSessionCache.

Esta opción configura el tiempo máximo de desviación cuando mod_ssl comprueba los campos thisUpdate y nextUpdate de las respuestas OCSP que se incluyen en el saludo TLS (Stapling de OCSP). sólo aplicable si SSLUseStapling está activada.

Esta opción configura el tiempo máximo para consultas a respondedores OCSP cuando SSLUseStapling está activada y mod_ssl está consultando a un respondedor por motivos de stapling de OCSP.

Esta opción configura la edad máxima permitida ("frescura") cuando se consideran las respuestas OCSP para stapling, p. ej. cuando SSLUseStapling está activada. El valor por defecto (-1) no fuerza una edad máxima, lo que significa que las respuestas OCSP se consideran válidas mientras el valor del campo nextUpdate está en una fecha futura.

Configura el límite de tiempo en segundos antes de que las respuestas en el cache de stapling de OCSP (configuradas con SSLStaplingCache) expiren. Esta directiva aplica a respuestas válidas, mientras que SSLStaplingErrorCacheTimeout se usa para controlar el límite de tiempo para respuestas inválidas/indisponibles.

Cuando se activa, mod_ssl pasará las respuestas de consultas sin éxito relacionadas con el stapling OCSP (tales como respuestas con un estado general que no sea otro que "con éxito", respuestas con un estado de certificado que no sea otro que "bueno", respuestas de expirado, etc.) al cliente. Si la configura a off, sólo respuestas indicando un estado de certificado "bueno" se incluirán en el saludo TLS.

Cuando se activa y una consulta de stapling a un respondedor OCSP falla, mod_ssl sintetizará una respuesta "tryLater" para el cliente. sólo efectiva si SSLStaplingReturnResponderErrors también está activada.

Configura el tiempo límite en segundos antes de que las respuestas inválidas en la cache de stapling OCSP (configuradas con SSLStaplingCache) expiren. Para configurar el tiempo límite de respuestas válidas, vea SSLStaplingStandardCacheTimeout.

Esta directiva sobreescribe la URI de un respondedor OCSP obtenida de la extensión authorityInfoAccess (AIA) del certificado. Un uso potencial puede ser cuando se usa un proxy para hacer consultas OCSP.

Opcionalmente configura una clave secreta para la encriptación y desencriptación de tickets de sesión TLS, tal y como se define en RFC 5077. Principalmente adecuado para entornos clusterizados donde la información de sesiones TLS debería ser compartida entre varios nodos. Para configuraciones de una sola instancia http, es recomendable no configurar un fichero clave de ticket, pero si depender de varias claves generadas (al azar) por mod_ssl en el arranque, en su lugar.

El fichero clave de ticket debe contener 48 bytes de datos aleatorios, preferiblemente credos de una fuente con alta entropía. En un sistema basado en Unix, un fichero clave de ticket puede generarse como sigue:

Las claves de ticket deberían rotarse (sustituirse) frecuentemente, puesto que esta es la única forma de invalidar sesiones de ticket existentes - Openssl actualmente no permite especificar un tiempo límite de validez de tickets. Una nueva clave de ticket sólo se usa después de reiniciar el servidor web. Todas las sesiones de tickets existentes son inválidas después de un reinicio.

Esta directiva permite activar la compresión a nivel de SSL.

Esta directiva permite activar o desactivar el uso de los tickets de sesión TLS (RFC 5077).

Esta directiva expone SSL_CONF de la API de OpenSSL para mod_ssl, permitiendo una configuración flexible de parámetros para OpenSSL sin la necesidad de implementar directivas adicionales de mod_ssl cuando se añaden nuevas características a OpenSSL.

El conjunto de comandos disponibles de SSLOpenSSLConfCmd depende de la versión OpenSSL utilizada para mod_ssl (al menos la versión 1.0.2 es necesaria). Para una lista de nombres de comandos soportados, vea la sección Comandos soportados para fichero de configuración en la página de manual SSL_CONF_cmd(3) de OpenSSL.

Algunos de los comandos de SSLOpenSSLConfCmd se pueden usar como alternativa a directivas existentes (tales como SSLCipherSuite o SSLProtocol), aunque debería tenerse en cuenta que la sintaxis / valores disponibles para parámetros pueden ser diferentes.

Esta directiva define un conjunto de configuraciones SSL y les da un nombre. Este nombre se puede usar en las directivas SSLPolicy y SSLProxyPolicy para aplicar esta configuración en el contexto actual.

Por un lado, esto puede hacer que la configuración del servidor sea mucho más fácil de leer y mantener. Por otro lado, está destinada a hacer SSL más fácil y seguro de usar. Para lo último, Apache httpd viene con un conjunto de políticas pre-definidas que reflejan buenas prácticas de código abierto. La política "modern", por ejemplo, lleva las configuraciones para hacer que su servidor trabaje de manera segura y compatible con navegadores actuales.

La lista de políticas predefinidas en su Apache pueden obtenerse lanzando el siguiente comando. Esta lista muestra las configuraciones detalladas con las que está definida cada política:

Esta directiva sólo se puede usar en la configuración del servidor (contexto global). Puede usar la mayoría de las directivas SSL*, sin embargo algunas sólo se pueden usar una vez y no se pueden utilizar dentro de definiciones de política. Estas son SSLCryptoDevice, SSLRandomSeed, SSLSessionCache y SSLStaplingCache.

Dos políticas no pueden tener el mismo nombre. Sin embargo, las políticas se pueden redefinir:

Las definiciones de Política se añaden en el orden que aparecen, pero se aplican cuando se ha leído toda la configuración. Esto significa que cualquier uso de 'proxy-trust' significará 'SSLProxyVerify none'. La primera definición no tiene ningún efecto. Esto permite que las políticas pre-instaladas sean sustituidas sin la necesidad de desactivarlas.

Además de reemplazar políticas, redefiniciones pueden alterar un aspecto de una política:

Esto re-utiliza todas las configuraciones de un 'proxy-trust' previo y añade una directiva encima de él. Todas las demás todavía aplican. Esto es muy útil cuando las políticas pre-definidas (por Apache mismo o un distribuidor) son casi como lo que necesitas. Previamente, tales definiciones fueron (copiadas y) editadas. Esto hacía que actualizarlas fuera difícil. Ahora pueden configurarse así:

Esta directiva aplica el conjunto de directivas SSL definidas bajo 'nombre' (vea SSLPolicyDefine) como las configuraciones base en el contexto actual. Apache viene con las siguientes políticas pre-definidas de Mozilla, los desarrolladores del navegador Firefox ( vea aquí para una descripción detallada de ellas.):

• modern: recomendada cuando su servidor es accesible desde Internet. Funciona con todos los navegadores modernos, pero dispositivos antiguos podrían no ser capaces de conectar.
• intermediate: el recurso si necesita dar soporte a clientes antiguos (pero no muy antiguos).
• old: cuando necesita dar acceso a Windows XP/Internet Explorer 7. El último recurso.

Puede comprobar una descripción detallada de todas las políticas definidas a través de la línea de comandos:

Una SSLPolicy define la línea base para el contexto en la que se utiliza. Eso significa que cualquier otra directiva SSL en el mismo contexto la sobrescribirá. Como ejemplo de esto, vea el valor efectivo de SSLProtocol en la siguiente configuración:

Puede haber más de una política aplicada en un contexto. La últimas sobrescribiendo las previas: :

Esta directiva es similar a SSLPolicy, pero aplica sólo a directivas de SSLProxy* definidas en la política. Esto ayuda cuando necesita distintas políticas para los clientes y los backends:

En este ejemplo, la política 'modern' se aplica a los clientes y backends. Entonces a las partes de los backend se sobrescriben con las configuraciones de políticas de 'intermediate'.