Versión 2.5 del Servidor HTTP Apache

Apache > Servidor HTTP > Documentación > Versión 2.5 > Módulos

# Módulo Apache mod_ssl

Idiomas disponibles: en | es | fr

Esta traducción podría estar obsoleta. Consulte la versión en inglés de la documentación para comprobar si se han producido cambios recientemente.

Descripción: | 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)
Estado: | Extensión
Identificador de Módulos: | ssl_module
Fichero de Código Fuente: | mod_ssl.c

### Resumen de contenidos

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.

### Temas

- Variables de Entorno
- Formatos de Log Personalizados
- Notas de Solicitud
- Extensión Intérprete de Expresiones
- Proveedores de Autorización para su uso con Require

### Directivas

### Lista de comprobación de errores corregidos

- httpd historial de cambios
- Problemas Conocidos
- Reportar un error

### Consulte también

- Comentarios

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

## Directiva SSLCACertificateFile ¶

Descripción: | Fichero de Certificados CA concatenados y codificados en PEM para la Autenticación de Cliente
Sintaxis: | `SSLCACertificateFile ruta-al-fichero`
Contexto: | server config, virtual host
Anula: | AuthConfig
Estado: | Extensión
Módulo: | mod_ssl

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"

## Directiva SSLCACertificatePath ¶

Descripción: | Directorio de certificados CA codificados en PEM para la autenticación de Cliente
Sintaxis: | `SSLCACertificatePath ruta-de-directorio`
Contexto: | server config, virtual host
Anula: | AuthConfig
Estado: | Extensión
Módulo: | mod_ssl

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/"

## Directiva SSLCADNRequestFile ¶

Descripción: | Fichero de certificados CA concatenados codificados en PEM para definir nombres de CA aceptables
Sintaxis: | `SSLCADNRequestFile ruta-al-fichero`
Contexto: | server config, virtual host
Estado: | Extensión
Módulo: | mod_ssl

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"

## Directiva SSLCADNRequestPath ¶

Descripción: | Directorio de Certificados CA codificados en PEM para definir nombres de CA aceptables
Sintaxis: | `SSLCADNRequestPath ruta-al-directorio`
Contexto: | server config, virtual host
Estado: | Extensión
Módulo: | mod_ssl

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/"

## Directiva SSLCARevocationCheck ¶

Descripción: | Activar comprobación de revocación basada en CRL
Sintaxis: | `SSLCARevocationCheck chain|leaf|none modificadores`
Valor por defecto: | `SSLCARevocationCheck none`
Contexto: | server config, virtual host
Estado: | Extensión
Módulo: | mod_ssl
Compatibilidad: | 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

## Directiva SSLCARevocationFile ¶

Descripción: | Fichero de CRL's de CA concatenados y codificados en PEM para la Autenticación de ClienteFile of concatenated PEM-encoded CA CRLs for
Sintaxis: | `SSLCARevocationFile ruta-al-fichero`
Contexto: | server config, virtual host
Estado: | Extensión
Módulo: | mod_ssl

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"

## Directiva SSLCARevocationPath ¶

Descripción: | Directorio de CRLs de CA codificados en PEM para la Autenticación de Cliente
Sintaxis: | `SSLCARevocationPath ruta-al-directorio`
Contexto: | server config, virtual host
Estado: | Extensión
Módulo: | mod_ssl

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/"

## Directiva SSLCertificateChainFile ¶

Descripción: | Fichero de Certificados CA de Servidor codificado en PEM
Sintaxis: | `SSLCertificateChainFile ruta-al-fichero`
Contexto: | server config, virtual host
Estado: | Extensión
Módulo: | mod_ssl

### 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"

## Directiva SSLCertificateFile ¶

Descripción: | Fichero de datos Certificado X.509 codificado en PEM
Sintaxis: | `SSLCertificateFile ruta-al-fichero`
Contexto: | server config, virtual host
Estado: | Extensión
Módulo: | mod_ssl

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"

## Directiva SSLCertificateKeyFile ¶

Descripción: | Fichero de clave privada de Servidor codificada en PEM
Sintaxis: | `SSLCertificateKeyFile ruta-al-fichero`
Contexto: | server config, virtual host
Estado: | Extensión
Módulo: | mod_ssl

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"

## Directiva SSLCipherSuite ¶

Descripción: | Conjunto de Cifrados disponibles para negociación en el saludo SSL
Sintaxis: | `SSLCipherSuite especificación-de-cifrado`
Valor por defecto: | `SSLCipherSuite DEFAULT (depende de la versión de OpenSSL)`
Contexto: | server config, virtual host, directory, .htaccess
Anula: | AuthConfig
Estado: | Extensión
Módulo: | mod_ssl

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

## Directiva SSLCompression ¶

Descripción: | Activa la compresión a nivel de SSL
Sintaxis: | `SSLCompression on|off`
Valor por defecto: | `SSLCompression off`
Contexto: | server config, virtual host
Estado: | Extensión
Módulo: | mod_ssl
Compatibilidad: | 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).

## Directiva SSLCryptoDevice ¶

Descripción: | Activar el uso de un hardware acelerador criptográfico
Sintaxis: | `SSLCryptoDevice engine`
Valor por defecto: | `SSLCryptoDevice builtin`
Contexto: | server config
Estado: | Extensión
Módulo: | mod_ssl

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

## Directiva SSLEngine ¶

Descripción: | Interruptor de Activación del motor SSL
Sintaxis: | `SSLEngine on|off|optional|addr[:port] [addr[:port]] ...`
Valor por defecto: | `SSLEngine off`
Contexto: | server config, virtual host
Estado: | Extensión
Módulo: | mod_ssl
Compatibilidad: | 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.

## Directiva SSLFIPS ¶

Descripción: | Interruptor del modo SSL FIPS
Sintaxis: | `SSLFIPS on|off`
Valor por defecto: | `SSLFIPS off`
Contexto: | server config
Estado: | Extensión
Módulo: | mod_ssl

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.

## Directiva SSLHonorCipherOrder ¶

Descripción: | Opción para forzar el orden de preferencia de cifrados del servidor
Sintaxis: | `SSLHonorCipherOrder on|off`
Valor por defecto: | `SSLHonorCipherOrder off`
Contexto: | server config, virtual host
Estado: | Extensión
Módulo: | mod_ssl

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

## Directiva SSLInsecureRenegotiation ¶

Descripción: | Opción para activar soporte de renegociación insegura
Sintaxis: | `SSLInsecureRenegotiation on|off`
Valor por defecto: | `SSLInsecureRenegotiation off`
Contexto: | server config, virtual host
Estado: | Extensión
Módulo: | mod_ssl
Compatibilidad: | 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.

## Directiva SSLOCSPDefaultResponder ¶

Descripción: | Configura la URI por defecto del respondedor para la validación OCSP
Sintaxis: | `SSLOCSDefaultResponder uri`
Contexto: | server config, virtual host
Estado: | Extensión
Módulo: | mod_ssl

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.

## Directiva SSLOCSPEnable ¶

Descripción: | Activa la validación OCSP para la cadena de certificados del cliente
Sintaxis: | `SSLOCSPEnable on|off`
Valor por defecto: | `SSLOCSPEnable off`
Contexto: | server config, virtual host
Estado: | Extensión
Módulo: | mod_ssl

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

## Directiva SSLOCSPNoverify ¶

Descripción: | Salta la verificación de certificados de respondedor OCSP
Sintaxis: | `SSLOCSPNoverify On/Off`
Valor por defecto: | `SSLOCSPNoverify Off`
Contexto: | server config, virtual host
Estado: | Extensión
Módulo: | mod_ssl
Compatibilidad: | 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.

## Directiva SSLOCSPOverrideResponder ¶

Descripción: | Fuerza el uso de una URI de respondedor por defecto para la validación OCSP
Sintaxis: | `SSLOCSPOverrideResponder on|off`
Valor por defecto: | `SSLOCSPOverrideResponder off`
Contexto: | server config, virtual host
Estado: | Extensión
Módulo: | mod_ssl

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.

## Directiva SSLOCSPProxyURL ¶

Descripción: | URL de Proxy a utilizar para las consultas OCSP
Sintaxis: | `SSLOCSPProxyURL url`
Contexto: | server config, virtual host
Estado: | Extensión
Módulo: | mod_ssl
Compatibilidad: | 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.

## Directiva SSLOCSPResponderCertificateFile ¶

Descripción: | Conjunto de certificados de respondedor OCSP confiables codificados en PEM
Sintaxis: | `SSLOCSPResponderCertificateFile fichero`
Contexto: | server config, virtual host
Estado: | Extensión
Módulo: | mod_ssl
Compatibilidad: | 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.

## Directiva SSLOCSPResponderTimeout ¶

Descripción: | Expiración de las consultas OCSP
Sintaxis: | `SSLOCSPResponderTimeout segundos`
Valor por defecto: | `SSLOCSPResponderTimeout 10`
Contexto: | server config, virtual host
Estado: | Extensión
Módulo: | mod_ssl

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

## Directiva SSLOCSPResponseMaxAge ¶

Descripción: | Edad máxima permitida para las respuestas OCSP
Sintaxis: | `SSLOCSPResponseMaxAge segundos`
Valor por defecto: | `SSLOCSPResponseMaxAge -1`
Contexto: | server config, virtual host
Estado: | Extensión
Módulo: | mod_ssl

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.

## Directiva SSLOCSPResponseTimeSkew ¶

Descripción: | Desviación máxima de tiempo permitida para la validación de la respuesta OCSP
Sintaxis: | `SSLOCSPResponseTimeSkew segundos`
Valor por defecto: | `SSLOCSPResponseTimeSkew 300`
Contexto: | server config, virtual host
Estado: | Extensión
Módulo: | mod_ssl

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

## Directiva SSLOCSPUseRequestNonce ¶

Descripción: | Usar un nonce dentro de las consultas OCSP
Sintaxis: | `SSLOCSPUseRequestNonce on|off`
Valor por defecto: | `SSLOCSPUseRequestNonce on`
Contexto: | server config, virtual host
Estado: | Extensión
Módulo: | mod_ssl
Compatibilidad: | 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`.

## Directiva SSLOpenSSLConfCmd ¶

Descripción: | Configura parámetros OpenSSL a través de su API SSL_CONF
Sintaxis: | `SSLOpenSSLConfCmd nombre-de-comando parámetro-de-comando`
Contexto: | server config, virtual host
Estado: | Extensión
Módulo: | mod_ssl
Compatibilidad: | 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

## Directiva SSLOptions ¶

Descripción: | Configurar varias opciones del motor SSL en tiempo real
Sintaxis: | `SSLOptions [+|-]opción ...`
Contexto: | server config, virtual host, directory, .htaccess
Anula: | Options
Estado: | Extensión
Módulo: | mod_ssl

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>

## Directiva SSLPassPhraseDialog ¶

Descripción: | Tipo de díalogo de solicitud de contraseña para claves privadas encriptadas
Sintaxis: | `SSLPassPhraseDialog tipo`
Valor por defecto: | `SSLPassPhraseDialog builtin`
Contexto: | server config
Estado: | Extensión
Módulo: | mod_ssl

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"

## Directiva SSLPolicy ¶

Descripción: | Aplica una Política SSL por nombre
Sintaxis: | `SSLPolicy nombre`
Contexto: | server config, virtual host
Estado: | Extensión
Módulo: | mod_ssl
Compatibilidad: | 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>

## Directiva SSLProtocol ¶

Descripción: | Configura versiones de protocolo SSL/TLS utilizables
Sintaxis: | `SSLProtocol [+|-]protocol ...`
Valor por defecto: | `SSLProtocol all -SSLv3`
Contexto: | server config, virtual host
Estado: | Extensión
Módulo: | mod_ssl

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

## Directiva SSLProxyCACertificateFile ¶

Descripción: | Fichero de Certificados CA concatenados codificados en PEM para la Autenticación Remota del Servidor
Sintaxis: | `SSLProxyCACertificateFile ruta-al-fichero`
Contexto: | server config, virtual host, sección de proxy
Estado: | Extensión
Módulo: | mod_ssl

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"

## Directiva SSLProxyCACertificatePath ¶

Descripción: | Directorio de Certificados CA codificados en PEM para la Autenticación de Servidor Remoto
Sintaxis: | `SSLProxyCACertificatePath ruta-al-directorio`
Contexto: | server config, virtual host, sección de proxy
Estado: | Extensión
Módulo: | mod_ssl

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/"

## Directiva SSLProxyCARevocationCheck ¶

Descripción: | Activa la comprobación de revocación basada en CRL para la Autenticación Remota de Servidor
Sintaxis: | `SSLProxyCARevocationCheck chain|leaf|none`
Valor por defecto: | `SSLProxyCARevocationCheck none`
Contexto: | server config, virtual host, sección de proxy
Estado: | Extensión
Módulo: | mod_ssl

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

## Directiva SSLProxyCARevocationFile ¶

Descripción: | Fichero de CRLs de CA codificados en PEM concatenados para la Autenticación Remota de Servidor
Sintaxis: | `SSLProxyCARevocationFile ruta-al-fichero`
Contexto: | server config, virtual host, sección de proxy
Estado: | Extensión
Módulo: | mod_ssl

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"

## Directiva SSLProxyCARevocationPath ¶

Descripción: | Directorio de CRLs de CA codificadas en PEM para la Autenticación Remota de Servidor
Sintaxis: | `SSLProxyCARevocationPath ruta-al-directorio`
Contexto: | server config, virtual host, sección de proxy
Estado: | Extensión
Módulo: | mod_ssl

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/"

## Directiva SSLProxyCheckPeerCN ¶

Descripción: | Comprobar el campo CN del certificado del servidor remoto
Sintaxis: | `SSLProxyCheckPeerCN on|off`
Valor por defecto: | `SSLProxyCheckPeerCN on`
Contexto: | server config, virtual host, sección de proxy
Estado: | Extensión
Módulo: | mod_ssl

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

## Directiva SSLProxyCheckPeerExpire ¶

Descripción: | Comprobar si el certificado del servidor remoto está expirado
Sintaxis: | `SSLProxyCheckPeerExpire on|off`
Valor por defecto: | `SSLProxyCheckPeerExpire on`
Contexto: | server config, virtual host, sección de proxy
Estado: | Extensión
Módulo: | mod_ssl

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

## Directiva SSLProxyCheckPeerName ¶

Descripción: | Configure comprobación de nombre de host para certificados de servidor remoto
Sintaxis: | `SSLProxyCheckPeerName on|off`
Valor por defecto: | `SSLProxyCheckPeerName on`
Contexto: | server config, virtual host, sección de proxy
Estado: | Extensión
Módulo: | mod_ssl
Compatibilidad: | 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.

## Directiva SSLProxyCipherSuite ¶

Descripción: | Conjunto de Cifrados disponibles para negociación en el saludo SSL de proxy
Sintaxis: | `SSLProxyCipherSuite especificación-de-cifrado`
Valor por defecto: | `SSLProxyCipherSuite ALL:!ADH:RC4+RSA:+HIGH:+MEDIUM:+LOW:+EXP`
Contexto: | server config, virtual host, sección de proxy
Estado: | Extensión
Módulo: | mod_ssl

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

## Directiva SSLProxyEngine ¶

Descripción: | Interruptor de Operación del Motor de Proxy SSL
Sintaxis: | `SSLProxyEngine on|off`
Valor por defecto: | `SSLProxyEngine off`
Contexto: | server config, virtual host, sección de proxy
Estado: | Extensión
Módulo: | mod_ssl

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>

## Directiva SSLProxyMachineCertificateChainFile ¶

Descripción: | Fichero de certificados CA concatenados y codificados en PEM para ser usados por el proxy para elegir un certificado
Sintaxis: | `SSLProxyMachineCertificateChainFile ruta-al-fichero`
Contexto: | server config, virtual host, sección de proxy
Estado: | Extensión
Módulo: | mod_ssl

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"

## Directiva SSLProxyMachineCertificateFile ¶

Descripción: | Fichero de certificados cliente codificados en PEM y claves para ser usadas por el proxy
Sintaxis: | `SSLProxyMachineCertificateFile ruta-al-fichero`
Contexto: | server config, virtual host, sección de proxy
Estado: | Extensión
Módulo: | mod_ssl

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"

## Directiva SSLProxyMachineCertificatePath ¶

Descripción: | Directorio de certificados cliente codificados en PEM y claves para ser usadas por el proxy
Sintaxis: | `SSLProxyMachineCertificatePath directorio`
Contexto: | server config, virtual host, sección de proxy
Estado: | Extensión
Módulo: | mod_ssl

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/"

## Directiva SSLProxyProtocol ¶

Descripción: | Configure sabores de protocolo SSL utilizables para uso de proxy
Sintaxis: | `SSLProxyProtocol [+|-]protocolo ...`
Valor por defecto: | `SSLProxyProtocol all -SSLv3`
Contexto: | server config, virtual host, sección de proxy
Estado: | Extensión
Módulo: | mod_ssl

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.

## Directiva SSLProxyVerify ¶

Descripción: | Tipo de verficación de certificado del servidor remoto
Sintaxis: | `SSLProxyVerify level`
Valor por defecto: | `SSLProxyVerify none`
Contexto: | server config, virtual host, sección de proxy
Estado: | Extensión
Módulo: | mod_ssl

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

## Directiva SSLProxyVerifyDepth ¶

Descripción: | Máxima profundidad de los Certificados CA en la verificación del Certificado en el Servidor Remoto
Sintaxis: | `SSLProxyVerifyDepth number`
Valor por defecto: | `SSLProxyVerifyDepth 1`
Contexto: | server config, virtual host, sección de proxy
Estado: | Extensión
Módulo: | mod_ssl

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

## Directiva SSLRandomSeed ¶

Descripción: | Fuente de generación de semilla pseudoaleatoria de números (PRNG)
Sintaxis: | `SSLRandomSeed contexto fuente [bytes]`
Contexto: | server config
Estado: | Extensión
Módulo: | mod_ssl

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

## Directiva SSLRenegBufferSize ¶

Descripción: | Configure el tamaño para el búfer de renegociación SSL
Sintaxis: | `SSLRenegBufferSize bytes`
Valor por defecto: | `SSLRenegBufferSize 131072`
Contexto: | directory, .htaccess
Anula: | AuthConfig
Estado: | Extensión
Módulo: | mod_ssl

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

## Directiva SSLRequire ¶

Descripción: | Permite acceso sólo cuando una compleja expresión booleana arbitraría es cierta
Sintaxis: | `SSLRequire expresión`
Contexto: | directory, .htaccess
Anula: | AuthConfig
Estado: | Extensión
Módulo: | mod_ssl

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

### Consulte también

- Variables de entorno en el Servidor HTTP Apache, para más ejemplos.
- Require expr
- Sintaxis general de expresión en el Servidor HTTP Apache

## Directiva SSLRequireSSL ¶

Descripción: | Denegar el acceso cuando no se usa SSL para la petición HTTP
Sintaxis: | `SSLRequireSSL`
Contexto: | directory, .htaccess
Anula: | AuthConfig
Estado: | Extensión
Módulo: | mod_ssl

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

## Directiva SSLSessionCache ¶

Descripción: | Tipo de la Caché global/interproceso de la sesión SSL
Sintaxis: | `SSLSessionCache tipo`
Valor por defecto: | `SSLSessionCache none`
Contexto: | server config
Estado: | Extensión
Módulo: | mod_ssl

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

## Directiva SSLSessionCacheTimeout ¶

Descripción: | Número de segundos antes de que la sesión SSL expira en la Cache de Sesión
Sintaxis: | `SSLSessionCacheTimeout segundos`
Valor por defecto: | `SSLSessionCacheTimeout 300`
Contexto: | server config, virtual host
Estado: | Extensión
Módulo: | mod_ssl
Compatibilidad: | 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

## Directiva SSLSessionTicketKeyFile ¶

Descripción: | Clave persistente de encriptación/desencriptación para ticket de sesión TLS
Sintaxis: | `SSLSessionTicketKeyFile ruta-al-fichero`
Contexto: | server config, virtual host
Estado: | Extensión
Módulo: | mod_ssl
Compatibilidad: | 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`.

## Directiva SSLSessionTickets ¶

Descripción: | Activa o desactiva el uso de tickets de sesión TLS
Sintaxis: | `SSLSessionTickets on|off`
Valor por defecto: | `SSLSessionTickets on`
Contexto: | server config, virtual host
Estado: | Extensión
Módulo: | mod_ssl
Compatibilidad: | 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

## Directiva SSLSRPUnknownUserSeed ¶

Descripción: | Semilla de usuario desconocido SRP
Sintaxis: | `SSLSRPUnknownUserSeed cadenadecaracteres-secreta`
Contexto: | server config, virtual host
Estado: | Extensión
Módulo: | mod_ssl
Compatibilidad: | 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"`

## Directiva SSLSRPVerifierFile ¶

Descripción: | Ruta hacia el fichero verificador SRP
Sintaxis: | `SSLSRPVerifierFile ruta-al-fichero`
Contexto: | server config, virtual host
Estado: | Extensión
Módulo: | mod_ssl
Compatibilidad: | 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`.

## Directiva SSLStaplingCache ¶

Descripción: | Configura la cache del stapling de OCSP
Sintaxis: | `SSLStaplingCache tipo`
Contexto: | server config
Estado: | Extensión
Módulo: | mod_ssl
Compatibilidad: | 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`.

## Directiva SSLStaplingErrorCacheTimeout ¶

Descripción: | Número de segundos antes de expirar respuestas inválidas en la cache del stapling de OCSP
Sintaxis: | `SSLStaplingErrorCacheTimeout segundos`
Valor por defecto: | `SSLStaplingErrorCacheTimeout 600`
Contexto: | server config, virtual host
Estado: | Extensión
Módulo: | mod_ssl
Compatibilidad: | 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`.

## Directiva SSLStaplingFakeTryLater ¶

Descripción: | Sintetiza respuestas "tryLater" para consultas fallidas de stapling de OCSP
Sintaxis: | `SSLStaplingFakeTryLater on|off`
Valor por defecto: | `SSLStaplingFakeTryLater on`
Contexto: | server config, virtual host
Estado: | Extensión
Módulo: | mod_ssl
Compatibilidad: | 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.

## Directiva SSLStaplingForceURL ¶

Descripción: | Sobreescribe la URI especificada por el respondedor OCSP especificada en la extensión AIA del certificado
Sintaxis: | `SSLStaplingForceURL uri`
Contexto: | server config, virtual host
Estado: | Extensión
Módulo: | mod_ssl
Compatibilidad: | 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.

## Directiva SSLStaplingResponderTimeout ¶

Descripción: | Tiempo máximo para las consultas de stapling de OCSP
Sintaxis: | `SSLStaplingResponderTimeout segundos`
Valor por defecto: | `SSLStaplingResponderTimeout 10`
Contexto: | server config, virtual host
Estado: | Extensión
Módulo: | mod_ssl
Compatibilidad: | 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.

## Directiva SSLStaplingResponseMaxAge ¶

Descripción: | Edad máxima permitida para respuesta de stapling OCSP
Sintaxis: | `SSLStaplingResponseMaxAge segundos`
Valor por defecto: | `SSLStaplingResponseMaxAge -1`
Contexto: | server config, virtual host
Estado: | Extensión
Módulo: | mod_ssl
Compatibilidad: | 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.

## Directiva SSLStaplingResponseTimeSkew ¶

Descripción: | Tiempo máximo permitido para la validación del stapling OCSP
Sintaxis: | `SSLStaplingResponseTimeSkew segundos`
Valor por defecto: | `SSLStaplingResponseTimeSkew 300`
Contexto: | server config, virtual host
Estado: | Extensión
Módulo: | mod_ssl
Compatibilidad: | 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.

## Directiva SSLStaplingReturnResponderErrors ¶

Descripción: | Pasa los errores relacionados con stapling de OCSP al cliente
Sintaxis: | `SSLStaplingReturnResponderErrors on|off`
Valor por defecto: | `SSLStaplingReturnResponderErrors on`
Contexto: | server config, virtual host
Estado: | Extensión
Módulo: | mod_ssl
Compatibilidad: | 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.

## Directiva SSLStaplingStandardCacheTimeout ¶

Descripción: | Número de segundos antes de expirar las respuestas en la cache del stapling de OCSP
Sintaxis: | `SSLStaplingStandardCacheTimeout segundos`
Valor por defecto: | `SSLStaplingStandardCacheTimeout 3600`
Contexto: | server config, virtual host
Estado: | Extensión
Módulo: | mod_ssl
Compatibilidad: | 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.

## Directiva SSLStrictSNIVHostCheck ¶

Descripción: | Permitir o no a clientes no-SNI acceder a host virtuales basados en nombre.
Sintaxis: | `SSLStrictSNIVHostCheck on|off`
Valor por defecto: | `SSLStrictSNIVHostCheck off`
Contexto: | server config, virtual host
Estado: | Extensión
Módulo: | mod_ssl

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

## Directiva SSLUserName ¶

Descripción: | Nombre de variable para determinar el nombre de usuario
Sintaxis: | `SSLUserName nombre de variable`
Contexto: | server config, directory, .htaccess
Anula: | AuthConfig
Estado: | Extensión
Módulo: | mod_ssl

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

## Directiva SSLUseStapling ¶

Descripción: | Activa stapling de las respuestas OCSP en el saludo TLS
Sintaxis: | `SSLUseStapling on|off`
Valor por defecto: | `SSLUseStapling off`
Contexto: | server config, virtual host
Estado: | Extensión
Módulo: | mod_ssl
Compatibilidad: | 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`.

## Directiva SSLVerifyClient ¶

Descripción: | Tipo de verificación de Certificado Cliente
Sintaxis: | `SSLVerifyClient nivel`
Valor por defecto: | `SSLVerifyClient none`
Contexto: | server config, virtual host, directory, .htaccess
Anula: | AuthConfig
Estado: | Extensión
Módulo: | mod_ssl

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

## Directiva SSLVerifyDepth ¶

Descripción: | Profundidad máxima de Certificados CA en la verificación de Certificado Cliente
Sintaxis: | `SSLVerifyDepth number`
Valor por defecto: | `SSLVerifyDepth 1`
Contexto: | server config, virtual host, directory, .htaccess
Anula: | AuthConfig
Estado: | Extensión
Módulo: | mod_ssl

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

Idiomas disponibles: en | es | fr

## Comentarios

Notice:
This is not a Q&A section. Comments placed here should be pointed towards suggestions on improving the documentation or server, and may be removed again by our moderators if they are either implemented or considered invalid/off-topic. Questions on how to manage the Apache HTTP Server should be directed at either our IRC channel, #httpd, on Freenode, or sent to our mailing lists.