mod_ssl
Criptografía fuerte usando una Capa de Sockets Seguros (Secure Sockets Layer SSL) y protocolos de Seguridad de la Capa de Transporte (Transport Layer Security TLS)
Extension
mod_ssl.c
ssl_module

Este módulo ofrece soporte para SSL v3 y TLS v1.x para el Servidor Apache HTTP. SSL v2 ya no está soportado.

Este módulo depende de OpenSSL para proveer el motor criptográfico.

Se facilitan más detalles, discusión y ejemplos en la documentación SSL.

# Variables de Entorno

Este módulo puede ser configurado para proveer muchos elementos de información SSL como variables de entorno adicionales para el espacio de nombres de SSI y CGI. Esta información no se facilita por defecto por razones de rendimiento. (Vea StdEnvVars de SSLOptions más adelante.) Las variables generadas se listan en la tabla a continuación. Para retrocompatibilidad la información también puede estar disponible bajo distintos nombres. Vea el capítulo Compatibilidad para más detalles sobre las variables de compatibilidad.

Nombre de Variable: | Valor Tipo: | Descripción:
--- | --- | ---
`HTTPS` | flag | Se está usando HTTPS.
`SSL_PROTOCOL` | string | El protocolo SSL versión (SSLv3, TLSv1, TLSv1.1, TLSv1.2)
`SSL_SESSION_ID` | string | El id de sesión SSL codificado en hexadecimal
`SSL_SESSION_RESUMED` | string | Sesión SSL inicial o reanudada. Nota: múltiples peticiones pueden servirse a través de la misma sesión SSL (Inicial o Reanudada) si el KeepAlive de HTTP está en uso
`SSL_SECURE_RENEG` | string | `true` si la renegociación segura está soportada, si no `false`
`SSL_CIPHER` | string | El nombre de la especificación del cifrado
`SSL_CIPHER_EXPORT` | string | `true` si el cifrado es un cifrado export
`SSL_CIPHER_USEKEYSIZE` | number | Número de bits de cifrado (en uso actualmente)
`SSL_CIPHER_ALGKEYSIZE` | number | Número de bits de cifrado (posibles)
`SSL_COMPRESS_METHOD` | string | Método de compresión SSL negociado
`SSL_VERSION_INTERFACE` | string | La versión de mod_ssl
`SSL_VERSION_LIBRARY` | string | La versión del programa OpenSSL
`SSL_CLIENT_M_VERSION` | string | La versión del certificado cliente
`SSL_CLIENT_M_SERIAL` | string | El serial del certificado cliente
`SSL_CLIENT_S_DN` | string | Sujeto DN en el certificado cliente
`SSL_CLIENT_S_DN_`x509 | string | Componente del Sujeto DN cliente
`SSL_CLIENT_SAN_Email_`n | string | Entradas de extensión subjectAltName del certificado cliente del tipo rfc822Name
`SSL_CLIENT_SAN_DNS_`n | string | Entradas de extensión subjectAltName del tipo dNSName
`SSL_CLIENT_SAN_OTHER_msUPN_`n | string | Entradas de extensión subjectAltName del certificado cliente del tipo otherName, Microsoft User Principal Name form (OID 1.3.6.1.4.1.311.20.2.3)
`SSL_CLIENT_I_DN` | string | DN del firmante en el certificado cliente
`SSL_CLIENT_I_DN_`x509 | string | Componente del DN en el firmante del certificado cliente
`SSL_CLIENT_V_START` | string | Validez del certificado cliente (fecha de inicio)
`SSL_CLIENT_V_END` | string | Validez del certificado cliente (fecha fin)
`SSL_CLIENT_V_REMAIN` | string | Número de días hasta que el certificado cliente expira
`SSL_CLIENT_A_SIG` | string | Algoritmo usado para la firma del certificado cliente
`SSL_CLIENT_A_KEY` | string | Algoritmo usado para la clave pública del certificado cliente.
`SSL_CLIENT_CERT` | string | Certificado cliente codificado en PEM
`SSL_CLIENT_CERT_CHAIN_`n | string | Certificados codificados en PEM en la cadena de certificados cliente
`SSL_CLIENT_CERT_RFC4523_CEA` | string | Número de serie y distribuidor del certificado. El formato coincide con el CertificateExactAssertion en RFC4523
`SSL_CLIENT_VERIFY` | string | `NONE`, `SUCCESS`, `GENEROUS` or `FAILED:`reason
`SSL_SERVER_M_VERSION` | string | La versión del certificado del servidor
`SSL_SERVER_M_SERIAL` | string | El serial del certificado del servidor
`SSL_SERVER_S_DN` | string | Nombre DN en el certificado del servidor
`SSL_SERVER_SAN_Email_`n | string | Entradas de extensión subjectAltName en el certificado del servidor del tipo rfc822Name
`SSL_SERVER_SAN_DNS_`n | string | Entradas de Extensión subjectAltName del tipo Server dNSName del certificado del Servidor
`SSL_SERVER_SAN_OTHER_dnsSRV_`n | string | Entradas de extensión subjectAltName del tipo otherName, forma SRVName (OID 1.3.6.1.5.5.7.8.7, RFC 4985) del certificado del servidor.
`SSL_SERVER_S_DN_`x509 | string | Componente del Sujeto DN del servidor
`SSL_SERVER_I_DN` | string | DN del Firmante del certificado del servidor
`SSL_SERVER_I_DN_`x509 | string | Componente en el DN del firmante del servidor
`SSL_SERVER_V_START` | string | Validez del certificado del servidor (fecha de inicio)
`SSL_SERVER_V_END` | string | Validez del certificado del servidor (fecha de fin)
`SSL_SERVER_A_SIG` | string | Algoritmo utilizado para la firma del certificado del servidor
`SSL_SERVER_A_KEY` | string | Algoritmo utilizado para la clave pública del certificado del servidor
`SSL_SERVER_CERT` | string | Certificado del servidor codificado en PEM
`SSL_SRP_USER` | string | Nombre de usuario SRP
`SSL_SRP_USERINFO` | string | Información de usuario SRP
`SSL_TLS_SNI` | string | Contenido de la extensión TLS SNI (si se provee en el ClientHello)

x509 especifica un componente de un DN X.509; uno entre `C,ST,L,O,OU,CN,T,I,G,S,D,UID,Email`. En Apache 2.2.0 en posterior, x509 también puede incluir un sufijo `_n` numérico. Si el DN en cuestión contiene múltiples atributos del mismo nombre, este sufijo se usa para un índice basado en ceros para seleccionar un atributo en particular. Por ejemplo, donde el sujeto del DN del certificado del servidor incluirá dos atributos OU, `SSL_SERVER_S_DN_OU_0` y `SSL_SERVER_S_DN_OU_1` podría usarse para referenciar cada una. Una variable sin un sufijo `_n` es equivalente a ese nombre con un sufijo `_0`; el primer (y único) atributo. Cuando la tabla del entorno se llena usando la opción `StdEnvVars` de la directiva SSLOptions, el primer (o único) atributo de cualquier DN se añade sólo bajo un nombre sin sufijo; p. ej. no se añaden entradas con sufijo `_0`.

En httpd 2.5.0 y posterior, se puede añadir un sufijo _RAW a x509 en un componente DN para suprimir la conversión del valor del atributo a UTF-8. Esto se debe colocar después del sufijo de indice (si lo hay). Por ejemplo, se podría usar `SSL_SERVER_S_DN_OU_RAW` o `SSL_SERVER_S_DN_OU_0_RAW`.

El formato de las variables *_DN ha cambiado en Apache HTTPD 2.3.11. Vea la opción `LegacyDNStringFormat` para SSLOptions para más detalles.

`SSL_CLIENT_V_REMAIN` sólo está disponible en la versión 2.1 y posterior.

Se puede usar varias variables de entorno adicionales con expresiones en SSLRequire, o en formatos de log personalizados:

    HTTP_USER_AGENT        PATH_INFO             AUTH_TYPE
    HTTP_REFERER           QUERY_STRING          SERVER_SOFTWARE
    HTTP_COOKIE            REMOTE_HOST           API_VERSION
    HTTP_FORWARDED         REMOTE_IDENT          TIME_YEAR
    HTTP_HOST              IS_SUBREQ             TIME_MON
    HTTP_PROXY_CONNECTION  DOCUMENT_ROOT         TIME_DAY
    HTTP_ACCEPT            SERVER_ADMIN          TIME_HOUR
    THE_REQUEST            SERVER_NAME           TIME_MIN
    REQUEST_FILENAME       SERVER_PORT           TIME_SEC
    REQUEST_METHOD         SERVER_PROTOCOL       TIME_WDAY
    REQUEST_SCHEME         REMOTE_ADDR           TIME
    REQUEST_URI            REMOTE_USER

En estos contextos, también se pueden usar dos formatos especiales:

`ENV:nombredevariable`
  Esto se rellenará al valor de la variable de entorno estándar nombredevariable.
`HTTP:nombredecabecera`
  Esto se rellenará con el valor de la cabecera de solicitud con el nombre nombredecabecera.

# Formatos de Log Personalizados

Cuando se compila mod_ssl en Apache o al menos se carga (en situación de DSO) existen funciones adicionales para el Formatos de Log Personalizados de mod_log_config. Primero hay una función de extensión de formato adicional ```%{`varname`}x`'' que puede usarse para extender cualquier variable facilitada por cualquier módulo, especialmente aquellas que son facilitadas por mod_ssl que puede encontrar en la tabla de más arriba.

Para retro compatibilidad adicionalmente se facilita una función de formato de criptografía ```%{`nombre`}c`''. Información sobre esta función se facilita en capítulo de Compatibilidad.

## Ejemplo

CustomLog "logs/ssl_request_log" "%t %h %{SSL_PROTOCOL}x %{SSL_CIPHER}x \"%r\" %b"

Estos formatos incluso funcionan sin la opción de configuración `StdEnvVars` de la directiva SSLOptions.

# Notas de Solicitud

mod_ssl configura "notas" para la petición que pueden usarse en el registro de logs con la cadena de caracteres `%{nombre}n` en mod_log_config.

A continuación se indican las notas soportadas:

`ssl-access-forbidden`
  Esta nota se configura al valor `1` si el acceso fue denegado debido a una directiva SSLRequire o SSLRequireSSL.
`ssl-secure-reneg`
  Si se compila mod_ssl con una versión de OpenSSL que soporta la extensión de renegociación segura, esta nota se configura con el valor `1` si se usa SSL para la conexión actual y el cliente también soporta la extensión de renegociación segura. Si el cliente no soporta la extensión de renegociación segura, esta nota se configura con el valor `0`. Si se compila mod_ssl con una versión de OpenSSL que no soporta renegociación segura, o si SSL no se usa en la conexión actual, esta nota no se configura.

# Extensión Intérprete de Expresiones

Cuando se compila mod_ssl en Apache o se carga (bajo situación DSO) cualquier variable facilitada por mod_ssl puede usarse en expresiones para el Intérprete de Expresiones ap_expr. Se puede hacer referencia a las variables usando la sintaxis ```%{`varname`}`''. Comenzando con la versión 2.4.18 uno también puede usar el estilo de sintaxis de mod_rewrite ```%{SSL:`nombredevariable`}`'' o el estilo de sintaxis de la función ```ssl(`nombredevariable`)`''.

## Ejemplo (usando mod_headers)

Header set X-SSL-PROTOCOL "expr=%{SSL_PROTOCOL}" Header set X-SSL-CIPHER "expr=%{SSL:SSL_CIPHER}"

Esta característica funciona incluso sin configurar la opción `StdEnvVars` de la directiva SSLOptions.

# Proveedores de Autorización para su uso con Require

mod_ssl facilita unos pocos proveedores de autenticación para usarse con la directiva Require de mod_authz_core.

## Require ssl

El proveedor de `ssl` deniega el acceso si la conexión no está encriptada con SSL. Esto es similar a la directiva SSLRequireSSL.

Require ssl

## Require ssl-verify-client

El proveedor de `ssl` permite acceso si el usuario se autentica con un certificado cliente válido. Esto sólo es útil si se está usando `SSLVerifyClient optional`.

El siguiente ejemplo permite acceso si el usuario se autentica o bien con certificado cliente o con usuario y contraseña.

Require ssl-verify-client Require valid-user
SSLPassPhraseDialog
Tipo de díalogo de solicitud de contraseña para claves privadas encriptadas
SSLPassPhraseDialog tipo
SSLPassPhraseDialog builtin
server config

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.

# Ejemplo

SSLPassPhraseDialog "exec:/usr/local/apache/sbin/pp-filter"
SSLRandomSeed
Fuente de generación de semilla pseudoaleatoria de números (PRNG)
SSLRandomSeed contexto fuente [bytes]
server config

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.

# Ejemplo

SSLRandomSeed startup builtin SSLRandomSeed startup "file:/dev/random" SSLRandomSeed startup "file:/dev/urandom" 1024 SSLRandomSeed startup "exec:/usr/local/bin/truerand" 16 SSLRandomSeed connect builtin SSLRandomSeed connect "file:/dev/random" SSLRandomSeed connect "file:/dev/urandom" 1024
SSLSessionCache
Tipo de la Caché global/interproceso de la sesión SSL
SSLSessionCache tipo
SSLSessionCache none
server config

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.

# Ejemplos

SSLSessionCache "dbm:/usr/local/apache/logs/ssl_gcache_data" SSLSessionCache "shmcb:/usr/local/apache/logs/ssl_gcache_data(512000)"

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.

SSLSessionCacheTimeout
Número de segundos antes de que la sesión SSL expira en la Cache de Sesión
SSLSessionCacheTimeout segundos
SSLSessionCacheTimeout 300
server config
virtual host
Aplica también al RFC 5077 de reanudación de sesión en Apache 2.4.10 o posterior

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.

# Ejemplo

SSLSessionCacheTimeout 600
SSLEngine
Interruptor de Activación del motor SSL
SSLEngine on|off|optional|addr[:port] [addr[:port]] ...
SSLEngine off
server config
virtual host
El parámetro `addr:port` está disponible en Apache 2.4.30 y posterior.

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.

# Ejemplo

<VirtualHost _default_:443> SSLEngine on #... </VirtualHost>

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.

# Ejemplo

SSLEngine *:443 <VirtualHost *:443> #... </VirtualHost>

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

SSLFIPS
Interruptor del modo SSL FIPS
SSLFIPS on|off
SSLFIPS off
server config

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.

SSLProtocol
Configura versiones de protocolo SSL/TLS utilizables
SSLProtocol [+|-]protocol ...
SSLProtocol all -SSLv3
server config
virtual host

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`).

# Ejemplo

SSLProtocol TLSv1
SSLCipherSuite
Conjunto de Cifrados disponibles para negociación en el saludo SSL
SSLCipherSuite especificación-de-cifrado
SSLCipherSuite DEFAULT (depende de la versión de OpenSSL)
server config
virtual host
directory
.htaccess
AuthConfig

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.

Tag | Description
--- | ---
Algoritmo de Intercambio de Clave:
`kRSA` | RSA key exchange
`kDHr` | Diffie-Hellman key exchange with RSA key
`kDHd` | Diffie-Hellman key exchange with DSA key
`kEDH` | Ephemeral (temp.key) Diffie-Hellman key exchange (no cert)
`kSRP` | Secure Remote Password (SRP) key exchange
Algoritmo de Autenticación:
`aNULL` | No authentication
`aRSA` | RSA authentication
`aDSS` | DSS authentication
`aDH` | Diffie-Hellman authentication
Algoritmo de Codificación de Cifrado:
`eNULL` | No encryption
`NULL` | alias for eNULL
`AES` | AES encryption
`DES` | DES encryption
`3DES` | Triple-DES encryption
`RC4` | RC4 encryption
`RC2` | RC2 encryption
`IDEA` | IDEA encryption
Algoritmo de Resumen de MAC:
`MD5` | MD5 hash function
`SHA1` | SHA1 hash function
`SHA` | alias for SHA1
`SHA256` | SHA256 hash function
`SHA384` | SHA384 hash function
Aliases:
`SSLv3` | all SSL version 3.0 ciphers
`TLSv1` | all TLS version 1.0 ciphers
`EXP` | all export ciphers
`EXPORT40` | all 40-bit export ciphers only
`EXPORT56` | all 56-bit export ciphers only
`LOW` | all low strength ciphers (no export, single DES)
`MEDIUM` | all ciphers with 128 bit encryption
`HIGH` | all ciphers using Triple-DES
`RSA` | all ciphers using RSA key exchange
`DH` | all ciphers using Diffie-Hellman key exchange
`EDH` | all ciphers using Ephemeral Diffie-Hellman key exchange
`ECDH` | Elliptic Curve Diffie-Hellman key exchange
`ADH` | all ciphers using Anonymous Diffie-Hellman key exchange
`AECDH` | all ciphers using Anonymous Elliptic Curve Diffie-Hellman key exchange
`SRP` | all ciphers using Secure Remote Password (SRP) key exchange
`DSS` | all ciphers using DSS authentication
`ECDSA` | all ciphers using ECDSA authentication
`aNULL` | all ciphers using no authentication

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)

# Los cifrados `aNULL`, `eNULL` y `EXP` siempre están deshabilitados

Empezando con la versión 2.4.7, null y cifrados de grado export están siempre deshabilitados, asi que mod_ssl añade incondicionalmente `!aNULL:!eNULL:!EXP` a cualquier lista de cifrados en la inicialización.

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.

# Ejemplo

SSLCipherSuite RSA:!EXP:!NULL:+HIGH:+MEDIUM:-LOW

Cipher-Tag | Protocol | Key Ex. | Auth. | Enc. | MAC | Type
--- | --- | --- | --- | --- | --- | ---
RSA Ciphers:
`DES-CBC3-SHA` | SSLv3 | RSA | RSA | 3DES(168) | SHA1 |
`IDEA-CBC-SHA` | SSLv3 | RSA | RSA | IDEA(128) | SHA1 |
`RC4-SHA` | SSLv3 | RSA | RSA | RC4(128) | SHA1 |
`RC4-MD5` | SSLv3 | RSA | RSA | RC4(128) | MD5 |
`DES-CBC-SHA` | SSLv3 | RSA | RSA | DES(56) | SHA1 |
`EXP-DES-CBC-SHA` | SSLv3 | RSA(512) | RSA | DES(40) | SHA1 | export
`EXP-RC2-CBC-MD5` | SSLv3 | RSA(512) | RSA | RC2(40) | MD5 | export
`EXP-RC4-MD5` | SSLv3 | RSA(512) | RSA | RC4(40) | MD5 | export
`NULL-SHA` | SSLv3 | RSA | RSA | None | SHA1 |
`NULL-MD5` | SSLv3 | RSA | RSA | None | MD5 |
Diffie-Hellman Ciphers:
`ADH-DES-CBC3-SHA` | SSLv3 | DH | None | 3DES(168) | SHA1 |
`ADH-DES-CBC-SHA` | SSLv3 | DH | None | DES(56) | SHA1 |
`ADH-RC4-MD5` | SSLv3 | DH | None | RC4(128) | MD5 |
`EDH-RSA-DES-CBC3-SHA` | SSLv3 | DH | RSA | 3DES(168) | SHA1 |
`EDH-DSS-DES-CBC3-SHA` | SSLv3 | DH | DSS | 3DES(168) | SHA1 |
`EDH-RSA-DES-CBC-SHA` | SSLv3 | DH | RSA | DES(56) | SHA1 |
`EDH-DSS-DES-CBC-SHA` | SSLv3 | DH | DSS | DES(56) | SHA1 |
`EXP-EDH-RSA-DES-CBC-SHA` | SSLv3 | DH(512) | RSA | DES(40) | SHA1 | export
`EXP-EDH-DSS-DES-CBC-SHA` | SSLv3 | DH(512) | DSS | DES(40) | SHA1 | export
`EXP-ADH-DES-CBC-SHA` | SSLv3 | DH(512) | None | DES(40) | SHA1 | export
`EXP-ADH-RC4-MD5` | SSLv3 | DH(512) | None | RC4(40) | MD5 | export

SSLCertificateFile
Fichero de datos Certificado X.509 codificado en PEM
SSLCertificateFile ruta-al-fichero
server config
virtual host

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.

# Interoperabilidad de parámetro DH con primos > 1024 bits

Comenzando con la versión 2.4.7, mod_ssl hace uso de parámetros DH estandarizados con longitud de primos de 2048, 3072 y 4096 bits y con longitud adicional de primos de 6144 y 8192 bits comenzando con la versión 2.4.10 (from RFC 3526), y los envía a clientes basándose en la longitud de la clave RSA/DSA del certificado. Con clientes basados en Java en particular (Java 7 o anterior), esto puede llevar a fallos de saludo inicial SSL - vea esta respuesta de FAQ para sortear estos problemas.

# Parámetros DH por defecto cuando se usan multiples certificados y y versiones de OpenSSL anteriores a 1.0.2

Cuando se usan múltiples certificados para dar soporte a algoritmos de autenticación diferentes (como RSA, DSA pero principalmente ECC) y OpenSSL anterior a 1.0.2, se recomienda usar o bien parámetros DH personalizados (preferiblemente) añadiéndolos al primer fichero de certificado (como se describe más arriba), o ordenar las directivas SSLCertificateFile para que los certificados RSA/DSA estén colocadas después del ECC.

Esto se debe a una limitación en versiones más antiguas de OpenSSL que no permiten que el servidor HTTP Apache determine el certificado seleccionado actualmente en el momento del saludo SSL (cuando se deben mandar los parámetros DH al cliente) pero en su lugar siempre se provee el último certificado configurado. Consecuentemente, el servidor puede seleccionar parámetros DH por defecto basado en la longitud de la clave privada incorrecta (las clacves ECC son mucho más pequeñas que las RSA/DSA y su longitud no es relevante para seleccionar primos DH).

Puesto que los parámetros personalizados DH siempre tienen precedencia sobre los de por defecto, este problema se puede evitar creando y configurándolos (como se describe arriba), y así usar una longitud adecuada/personalizada.

# Ejemplo

SSLCertificateFile "/usr/local/apache2/conf/ssl.crt/server.crt"
SSLCertificateKeyFile
Fichero de clave privada de Servidor codificada en PEM
SSLCertificateKeyFile ruta-al-fichero
server config
virtual host

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.

# Ejemplo

SSLCertificateKeyFile "/usr/local/apache2/conf/ssl.key/server.key"
SSLCertificateChainFile
Fichero de Certificados CA de Servidor codificado en PEM
SSLCertificateChainFile ruta-al-fichero
server config
virtual host

# SSLCertificateChainFile está obsoleto

`SSLCertificateChainFile` quedó obsoleto con la versión 2.4.8, cuando se extendió SSLCertificateFile para cargar también los certificados de CA intermedias del fichero de certificados del servidor.

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.

# Ejemplo

SSLCertificateChainFile "/usr/local/apache2/conf/ssl.crt/ca.crt"
SSLCACertificatePath
Directorio de certificados CA codificados en PEM para la autenticación de Cliente
SSLCACertificatePath ruta-de-directorio
server config
virtual host
AuthConfig

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.

# Ejemplo

SSLCACertificatePath "/usr/local/apache2/conf/ssl.crt/"
SSLCACertificateFile
Fichero de Certificados CA concatenados y codificados en PEM para la Autenticación de Cliente
SSLCACertificateFile ruta-al-fichero
server config
virtual host
AuthConfig

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.

# Ejemplo

SSLCACertificateFile "/usr/local/apache2/conf/ssl.crt/ca-bundle-client.crt"
SSLCADNRequestFile
Fichero de certificados CA concatenados codificados en PEM para definir nombres de CA aceptables
SSLCADNRequestFile ruta-al-fichero
server config
virtual host

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.

# Ejemplo

SSLCADNRequestFile "/usr/local/apache2/conf/ca-names.crt"
SSLCADNRequestPath
Directorio de Certificados CA codificados en PEM para definir nombres de CA aceptables
SSLCADNRequestPath ruta-al-directorio
server config
virtual host

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.

# Ejemplo

SSLCADNRequestPath "/usr/local/apache2/conf/ca-names.crt/"
SSLCARevocationPath
Directorio de CRLs de CA codificados en PEM para la Autenticación de Cliente
SSLCARevocationPath ruta-al-directorio
server config
virtual host

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.

# Ejemplo

SSLCARevocationPath "/usr/local/apache2/conf/ssl.crl/"
SSLCARevocationFile
Fichero de CRL's de CA concatenados y codificados en PEM para la Autenticación de ClienteFile of concatenated PEM-encoded CA CRLs for
SSLCARevocationFile ruta-al-fichero
server config
virtual host

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.

# Ejemplo

SSLCARevocationFile "/usr/local/apache2/conf/ssl.crl/ca-bundle-client.crl"
SSLCARevocationCheck
Activar comprobación de revocación basada en CRL
SSLCARevocationCheck chain|leaf|none modificadores
SSLCARevocationCheck none
server config
virtual host
Modificadores Opcionales disponibles en httpd 2.4.21 o posterior

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..

# Ejemplo

SSLCARevocationCheck chain

# Compatibilidad con versiones 2.2

SSLCARevocationCheck chain no_crl_for_cert_ok
SSLVerifyClient
Tipo de verificación de Certificado Cliente
SSLVerifyClient nivel
SSLVerifyClient none
server config
virtual host
directory
.htaccess
AuthConfig

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.

# Ejemplo

SSLVerifyClient require
SSLVerifyDepth
Profundidad máxima de Certificados CA en la verificación de Certificado Cliente
SSLVerifyDepth number
SSLVerifyDepth 1
server config
virtual host
directory
.htaccess
AuthConfig

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.

# Ejemplo

SSLVerifyDepth 10
SSLSRPVerifierFile
Ruta hacia el fichero verificador SRP
SSLSRPVerifierFile ruta-al-fichero
server config
virtual host
Disponible en httpd 2.4.4 y posterior si se usa OpenSSL 1.0.1 o posterior

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.

# Ejemplo

SSLSRPVerifierFile "/ruta/al/fichero.srpv"

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

# Creando el fichero verificador SRP

openssl srp -srpvfile passwd.srpv -userinfo "some info" -add username

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

SSLSRPUnknownUserSeed
Semilla de usuario desconocido SRP
SSLSRPUnknownUserSeed cadenadecaracteres-secreta
server config
virtual host
Disponible en httpd 2.4.4 y posterior si se usa OpenSSL 1.0.1 o posterior

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.

# Ejemplo

SSLSRPUnknownUserSeed "secret"
SSLOptions
Configurar varias opciones del motor SSL en tiempo real
SSLOptions [+|-]opción ...
server config
virtual host
directory
.htaccess
Options

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.

# Ejemplo

SSLOptions +FakeBasicAuth -StrictRequire <Files ~ "\.(cgi|shtml)$"> SSLOptions +StdEnvVars -ExportCertData </Files>
SSLRequireSSL
Denegar el acceso cuando no se usa SSL para la petición HTTP
SSLRequireSSL
directory
.htaccess
AuthConfig

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.

# Ejemplo

SSLRequireSSL
SSLRequire
Permite acceso sólo cuando una compleja expresión booleana arbitraría es cierta
SSLRequire expresión
directory
.htaccess
AuthConfig

# SSLRequire está obsoleta

`SSLRequire` está obsoleta y debería en general ser sustituida por Require expr. La tal llamada sintaxis de ap_expr en `Require expr` es la sustitución de la sintaxis de `SSLRequire`, con la siguiente excepción:

En `SSLRequire`, los operadores de comparación `<`, `<=`, ... son equivalentes completamente a los operadores `lt`, `le`, ... y funionan de una manera un tanto peculiar que primero compara la longitud de dos cadenas de caracteres y después el orden léxico. Por otro lado, ap_expr tiene dos conjuntos de operadores de comparación: Los operadores `<`, `<=`, ... hacen compraciones léxicas de cadenas de caracteres, mientras que los operadores `-lt`, `-le`, ... hacen comparación de números integrales. Para los últimos, también hay aliases sin el guión inicial: `lt`, `le`, ...

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.

# Ejemplo

SSLRequire ( %{SSL_CIPHER} !~ m/^(EXP|NULL)-/ \ and %{SSL_CLIENT_S_DN_O} eq "Snake Oil, Ltd." \ and %{SSL_CLIENT_S_DN_OU} in {"Staff", "CA", "Dev"} \ and %{TIME_WDAY} -ge 1 and %{TIME_WDAY} -le 5 \ and %{TIME_HOUR} -ge 8 and %{TIME_HOUR} -le 20 ) \ or %{REMOTE_ADDR} =~ m/^192\.76\.162\.[0-9]+$/

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).

# Ejemplo

SSLRequire "foobar" in PeerExtList("1.2.3.4.5.6")

# Notas sobre la función PeerExtList

- El ID de objeto puede ser especificado o bien como un nombre descriptivo reconocido por la librería SSL, tal como `"nsComment"`, o como un OID numérico, tal como `"1.2.3.4.5.6"`.

- Expresiones con tipos conocidos para la librería SSL se expresan como una cadena de caracteres antes de su comparación. Para una extensión con un tipo no reconocido por la librería SSL, mod_ssl interpretará el valor si es uno de los tipos primitivos ASN.1 types UTF8String, IA5String, VisibleString, o BMPString. Para una extensión de uno de estos tipos, el valor de la cadena de caracteres se convertirá en UTF-8 si es necesario, y entonces comparada contra la expresión de la izquierda.

Variables de entorno en el Servidor HTTP Apache, para más ejemplos.
Require expr
Sintaxis general de expresión en el Servidor HTTP Apache
SSLRenegBufferSize
Configure el tamaño para el búfer de renegociación SSL
SSLRenegBufferSize bytes
SSLRenegBufferSize 131072
directory
.htaccess
AuthConfig

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.

Tenga en cuenta que en muchas configuraciones, el cliente enviando el cuerpo de la petición no es confiable así que se debe considerar un ataque de denegación de servicio por consumo de memoria cuando se cambie este valor de configuración.

# Ejemplo

SSLRenegBufferSize 262144
SSLStrictSNIVHostCheck
Permitir o no a clientes no-SNI acceder a host virtuales basados en nombre.
SSLStrictSNIVHostCheck on|off
SSLStrictSNIVHostCheck off
server config
virtual host

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 opción sólo está disponible si httpd fue compilado contra una versión compatible con SNI de OpenSSL.

# Ejemplo

SSLStrictSNIVHostCheck on
SSLProxyMachineCertificatePath
Directorio de certificados cliente codificados en PEM y claves para ser usadas por el proxy
SSLProxyMachineCertificatePath directorio
server config
virtual host
proxy section

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.

Actualmente no hay soporte para claves privadas encriptadas

# Ejemplo

SSLProxyMachineCertificatePath "/usr/local/apache2/conf/proxy.crt/"
SSLProxyMachineCertificateFile
Fichero de certificados cliente codificados en PEM y claves para ser usadas por el proxy
SSLProxyMachineCertificateFile ruta-al-fichero
server config
virtual host
proxy section

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`.

Actualmente no hay soporte para claves privadas encriptadas

# Ejemplo

SSLProxyMachineCertificateFile "/usr/local/apache2/conf/ssl.crt/proxy.pem"
SSLProxyMachineCertificateChainFile
Fichero de certificados CA concatenados y codificados en PEM para ser usados por el proxy para elegir un certificado
SSLProxyMachineCertificateChainFile ruta-al-fichero
server config
virtual host
proxy section

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.

# Aviso de Seguridad

Si se activa esta directiva, se confiará en todos los certificados en el fichero como si también estuvieran en SSLProxyCACertificateFile.

# Ejemplo

SSLProxyMachineCertificateChainFile "/usr/local/apache2/conf/ssl.crt/proxyCA.pem"
SSLProxyVerify
Tipo de verficación de certificado del servidor remoto
SSLProxyVerify level
SSLProxyVerify none
server config
virtual host
proxy section

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.)

# Ejemplo

SSLProxyVerify require
SSLProxyVerifyDepth
Máxima profundidad de los Certificados CA en la verificación del Certificado en el Servidor Remoto
SSLProxyVerifyDepth number
SSLProxyVerifyDepth 1
server config
virtual host
proxy section

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.

# Ejemplo

SSLProxyVerifyDepth 10
SSLProxyCheckPeerExpire
Comprobar si el certificado del servidor remoto está expirado
SSLProxyCheckPeerExpire on|off
SSLProxyCheckPeerExpire on
server config
virtual host
proxy section

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).

# Ejemplo

SSLProxyCheckPeerExpire on
SSLProxyCheckPeerCN
Comprobar el campo CN del certificado del servidor remoto
SSLProxyCheckPeerCN on|off
SSLProxyCheckPeerCN on
server config
virtual host
proxy section

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;

# Ejemplo

SSLProxyCheckPeerCN on SSLProxyCheckPeerName off
SSLProxyCheckPeerName
Configure comprobación de nombre de host para certificados de servidor remoto
SSLProxyCheckPeerName on|off
SSLProxyCheckPeerName on
server config
virtual host
proxy section
Apache HTTP Server 2.4.5 and later

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.

SSLProxyEngine
Interruptor de Operación del Motor de Proxy SSL
SSLProxyEngine on|off
SSLProxyEngine off
server config
virtual host
proxy section

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.

# Ejemplo

<VirtualHost _default_:443> SSLProxyEngine on #... </VirtualHost>
SSLProxyProtocol
Configure sabores de protocolo SSL utilizables para uso de proxy
SSLProxyProtocol [+|-]protocolo ...
SSLProxyProtocol all -SSLv3
server config
virtual host
proxy section

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.

SSLProxyCipherSuite
Conjunto de Cifrados disponibles para negociación en el saludo SSL de proxy
SSLProxyCipherSuite especificación-de-cifrado
SSLProxyCipherSuite ALL:!ADH:RC4+RSA:+HIGH:+MEDIUM:+LOW:+EXP
server config
virtual host
proxy section

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

SSLProxyCACertificatePath
Directorio de Certificados CA codificados en PEM para la Autenticación de Servidor Remoto
SSLProxyCACertificatePath ruta-al-directorio
server config
virtual host
proxy section

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.

# Ejemplo

SSLProxyCACertificatePath "/usr/local/apache2/conf/ssl.crt/"
SSLProxyCACertificateFile
Fichero de Certificados CA concatenados codificados en PEM para la Autenticación Remota del Servidor
SSLProxyCACertificateFile ruta-al-fichero
server config
virtual host
proxy section

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.

# Ejemplo

SSLProxyCACertificateFile "/usr/local/apache2/conf/ssl.crt/ca-bundle-remote-server.crt"
SSLProxyCARevocationPath
Directorio de CRLs de CA codificadas en PEM para la Autenticación Remota de Servidor
SSLProxyCARevocationPath ruta-al-directorio
server config
virtual host
proxy section

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.

# Ejemplo

SSLProxyCARevocationPath "/usr/local/apache2/conf/ssl.crl/"
SSLProxyCARevocationFile
Fichero de CRLs de CA codificados en PEM concatenados para la Autenticación Remota de Servidor
SSLProxyCARevocationFile ruta-al-fichero
server config
virtual host
proxy section

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.

# Ejemplo

SSLProxyCARevocationFile "/usr/local/apache2/conf/ssl.crl/ca-bundle-remote-server.crl"
SSLProxyCARevocationCheck
Activa la comprobación de revocación basada en CRL para la Autenticación Remota de Servidor
SSLProxyCARevocationCheck chain|leaf|none
SSLProxyCARevocationCheck none
server config
virtual host
proxy section

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.

# Cuando se configura a `chain` o `leaf`, las CRLs deben estar disponibles para la validación con éxito.

Antes de la versión 2.4.15, la comprobación de CRL en mod_ssl también tenía éxito cuando no se encontraban CRLs en ninguna de las ubicaciones configuradas con SSLProxyCARevocationFile o SSLProxyCARevocationPath. Con la introducción de esta directiva, el comportamiento ha cambiado: cuando la comprobación está habilitada, las CRLs deben estar presentes para que la validación pueda tener éxito - si no fallará con un error `"unable to get certificate CRL"`.

# Ejemplo

SSLProxyCARevocationCheck chain
SSLUserName
Nombre de variable para determinar el nombre de usuario
SSLUserName nombre de variable
server config
directory
.htaccess
AuthConfig

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).

# Ejemplo

SSLUserName SSL_CLIENT_S_DN_CN
SSLHonorCipherOrder
Opción para forzar el orden de preferencia de cifrados del servidor
SSLHonorCipherOrder on|off
SSLHonorCipherOrder off
server config
virtual host

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.

# Ejemplo

SSLHonorCipherOrder on
SSLCryptoDevice
Activar el uso de un hardware acelerador criptográfico
SSLCryptoDevice engine
SSLCryptoDevice builtin
server config

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`".

# Ejemplo

# For a Broadcom accelerator: SSLCryptoDevice ubsec
SSLOCSPEnable
Activa la validación OCSP para la cadena de certificados del cliente
SSLOCSPEnable on|off
SSLOCSPEnable off
server config
virtual host

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.

# Ejemplo

SSLVerifyClient on SSLOCSPEnable on SSLOCSPDefaultResponder "http://responder.example.com:8888/responder" SSLOCSPOverrideResponder on
SSLOCSPDefaultResponder
Configura la URI por defecto del respondedor para la validación OCSP
SSLOCSDefaultResponder uri
server config
virtual host

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.

SSLOCSPOverrideResponder
Fuerza el uso de una URI de respondedor por defecto para la validación OCSP
SSLOCSPOverrideResponder on|off
SSLOCSPOverrideResponder off
server config
virtual host

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.

SSLOCSPResponseTimeSkew
Desviación máxima de tiempo permitida para la validación de la respuesta OCSP
SSLOCSPResponseTimeSkew segundos
SSLOCSPResponseTimeSkew 300
server config
virtual host

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`).

SSLOCSPResponseMaxAge
Edad máxima permitida para las respuestas OCSP
SSLOCSPResponseMaxAge segundos
SSLOCSPResponseMaxAge -1
server config
virtual host

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.

SSLOCSPResponderTimeout
Expiración de las consultas OCSP
SSLOCSPResponderTimeout segundos
SSLOCSPResponderTimeout 10
server config
virtual host

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

SSLOCSPUseRequestNonce
Usar un nonce dentro de las consultas OCSP
SSLOCSPUseRequestNonce on|off
SSLOCSPUseRequestNonce on
server config
virtual host
Disponible en httpd 2.4.10 y posterior

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`.

SSLOCSPNoverify
Salta la verificación de certificados de respondedor OCSP
SSLOCSPNoverify On/Off
SSLOCSPNoverify Off
server config
virtual host
Disponible en httpd 2.4.26 y posterior, si se usa OpenSSL 0.9.7 o posterior

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

SSLOCSPResponderCertificateFile
Conjunto de certificados de respondedor OCSP confiables codificados en PEM
SSLOCSPResponderCertificateFile fichero
server config
virtual host
Disponible en httpd 2.4.26 y posterior, si se usa con OpenSSL 0.9.7 o posterior

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.

SSLOCSPProxyURL
URL de Proxy a utilizar para las consultas OCSP
SSLOCSPProxyURL url
server config
virtual host
Disponible en httpd 2.4.19 y posterior

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

SSLInsecureRenegotiation
Opción para activar soporte de renegociación insegura
SSLInsecureRenegotiation on|off
SSLInsecureRenegotiation off
server config
virtual host
Disponible si se usa OpenSSL 0.9.8m o posterior

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.

# Aviso de Seguridad

Si se activa esta directiva, las conexiones SSL serán vulnerables a ataques Man-in-the-Middle de prefijo tal y como se describe en CVE-2009-3555.

# Ejemplo

SSLInsecureRenegotiation on

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.

SSLUseStapling
Activa stapling de las respuestas OCSP en el saludo TLS
SSLUseStapling on|off
SSLUseStapling off
server config
virtual host
Disponible si se usa OpenSSL 0.9.8h o posterior

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.

SSLStaplingCache
Configura la cache del stapling de OCSP
SSLStaplingCache tipo
server config
Disponible si se usa OpenSSL 0.9.8h o posterior

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.

SSLStaplingResponseTimeSkew
Tiempo máximo permitido para la validación del stapling OCSP
SSLStaplingResponseTimeSkew segundos
SSLStaplingResponseTimeSkew 300
server config
virtual host
Disponible si se usa OpenSSL 0.9.8h o posterior

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.

SSLStaplingResponderTimeout
Tiempo máximo para las consultas de stapling de OCSP
SSLStaplingResponderTimeout segundos
SSLStaplingResponderTimeout 10
server config
virtual host
Disponible si se usa OpenSSL 0.9.8h o posterior

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.

SSLStaplingResponseMaxAge
Edad máxima permitida para respuesta de stapling OCSP
SSLStaplingResponseMaxAge segundos
SSLStaplingResponseMaxAge -1
server config
virtual host
Disponible si se usa OpenSSL 0.9.8h o posterior

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.

SSLStaplingStandardCacheTimeout
Número de segundos antes de expirar las respuestas en la cache del stapling de OCSP
SSLStaplingStandardCacheTimeout segundos
SSLStaplingStandardCacheTimeout 3600
server config
virtual host
Disponible si se usa OpenSSL 0.9.8h o posterior

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.

SSLStaplingReturnResponderErrors
Pasa los errores relacionados con stapling de OCSP al cliente
SSLStaplingReturnResponderErrors on|off
SSLStaplingReturnResponderErrors on
server config
virtual host
Disponible si se usa OpenSSL 0.9.8h o posterior

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.

SSLStaplingFakeTryLater
Sintetiza respuestas "tryLater" para consultas fallidas de stapling de OCSP
SSLStaplingFakeTryLater on|off
SSLStaplingFakeTryLater on
server config
virtual host
Disponible si se usa OpenSSL 0.9.8h o posterior

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.

SSLStaplingErrorCacheTimeout
Número de segundos antes de expirar respuestas inválidas en la cache del stapling de OCSP
SSLStaplingErrorCacheTimeout segundos
SSLStaplingErrorCacheTimeout 600
server config
virtual host
Disponible si se usa OpenSSL 0.9.8h o posterior

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.

SSLStaplingForceURL
Sobreescribe la URI especificada por el respondedor OCSP especificada en la extensión AIA del certificado
SSLStaplingForceURL uri
server config
virtual host
Disponible si se usa OpenSSL 0.9.8h o posterior

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.

SSLSessionTicketKeyFile
Clave persistente de encriptación/desencriptación para ticket de sesión TLS
SSLSessionTicketKeyFile ruta-al-fichero
server config
virtual host
Disponible en httpd 2.4.0 y posterior, si se usaOpenSSL 0.9.8h o posterior

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:

dd if=/dev/random of=/path/to/file.tkey bs=1 count=48

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.

El fichero clave de ticket contiene material sensible de claves y debería protegerse con permisos de fichero de una manera similar a las que se deben usar para los ficheros utilizados con SSLCertificateKeyFile.

SSLCompression
Activa la compresión a nivel de SSL
SSLCompression on|off
SSLCompression off
server config
virtual host
Disponible en httpd 2.4.3 y posterior, si se usa OpenSSL 0.9.8 o posterior; disponible en el contexto de virtualhost si se usa OpenSSL 1.0.0 o posterior. El valor por defecto solía ser `on` en la versión 2.4.3

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

Activar la compresión provoca problemas de seguridad en la mayoría de las configuraciones (como el conocido ataque CRIME).

SSLSessionTickets
Activa o desactiva el uso de tickets de sesión TLS
SSLSessionTickets on|off
SSLSessionTickets on
server config
virtual host
Disponible en httpd 2.4.11 y posterior, si se usa OpenSSL 0.9.8f o posterior.

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

Los tickets de sesión TLS se activan por defecto. Usarlos sin reiniciar el servidor web con una frecuencia apropiada (p. ej. diariamente) compromete un "forward secrecy" perfecto

SSLOpenSSLConfCmd
Configura parámetros OpenSSL a través de su API SSL_CONF
SSLOpenSSLConfCmd nombre-de-comando parámetro-de-comando
server config
virtual host
Disponible en httpd 2.4.8 y posterior, si se usa OpenSSL 1.0.2 o posterior

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.

# Ejemplos

SSLOpenSSLConfCmd Options -SessionTicket,ServerPreference SSLOpenSSLConfCmd ECDHParameters brainpoolP256r1 SSLOpenSSLConfCmd ServerInfoFile "/usr/local/apache2/conf/server-info.pem" SSLOpenSSLConfCmd Protocol "-ALL, TLSv1.2" SSLOpenSSLConfCmd SignatureAlgorithms RSA+SHA384:ECDSA+SHA256
SSLPolicyDefine
Define un conjunto de nombres de configuraciones SSL
<SSLPolicyDefine nombre>
server config
Disponible in httpd 2.4.30 y posterior

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.

# Definición y Uso de una Política

<SSLPolicyDefine safe-stapling> SSLUseStapling on SSLStaplingResponderTimeout 2 SSLStaplingReturnResponderErrors off SSLStaplingFakeTryLater off SSLStaplingStandardCacheTimeout 86400 </SSLPolicyDefine>

... <VirtualHost...> SSLPolicy safe-stapling ...

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:

# Lista todas las Políticas Definidas

httpd -t -D DUMP_SSL_POLICIES

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:

# Sobreescribir Políticas

<SSLPolicyDefine proxy-trust> SSLProxyVerify require </SSLPolicyDefine> ... <SSLPolicyDefine proxy-trust> SSLProxyVerify none </SSLPolicyDefine>

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:

# Policy Redefine

<SSLPolicyDefine proxy-trust> SSLProxyVerify require </SSLPolicyDefine> ... <SSLPolicyDefine proxy-trust> SSLPolicy proxy-trust SSLProxyVerifyDepth 10 </SSLPolicyDefine>

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í:

# Ajusta una Política Pre-Definida

Include ssl-policies.conf

<SSLPolicyDefine modern> SSLPolicy modern SSLProxyVerify none </SSLPolicyDefine>
SSLPolicy
Aplica una Política SSL por nombre
SSLPolicy nombre
server config
virtual host
Disponible en httpd 2.5.0 y posterior

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:

# Listar Todas las Políticas Definidas

httpd -t -D DUMP_SSL_POLICIES

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:

# Precedencia de Política

<VirtualHost...> # efectivo en: 'all' SSLPolicy modern SSLProtocol all </VirtualHost>

<VirtualHost...> # efectivo en: 'all' SSLProtocol all SSLPolicy modern </VirtualHost>

SSLPolicy modern <VirtualHost...> # efectivo en: 'all' SSLProtocol all </VirtualHost>

SSLProtocol all <VirtualHost...> # efectivo en: '+TLSv1.2' SSLPolicy modern </VirtualHost>

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

# Ordenando Políticas

<VirtualHost...> # protocolo efectivo: 'all -SSLv3' SSLPolicy modern SSLPolicy intermediate </VirtualHost>

<VirtualHost...> # protocolo efectivo: '+TLSv1.2' SSLPolicy intermediate SSLPolicy modern </VirtualHost>
SSLProxyPolicy
Aplica directivas de tipo SSLProxy* en una SSLPolicy
SSLProxyPolicy nombre
server config
virtual host
Disponible en httpd 2.4.30 y posterior

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:

# Otras Políticas sólo para Proxy

SSLPolicy modern SSLProxyPolicy intermediate

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'.