SSL#
El módulo habilita el soporte de cifrado SSL/TLS para protocolos de proxy de correo (POP3, IMAP, SMTP), permitiendo una comunicación segura entre clientes y el servidor. Proporciona cifrado SSL/TLS para conexiones entrantes, soporta actualizaciones STARTTLS, gestiona certificados y claves, y controla configuraciones SSL como cifrados y versiones de protocolo.
Cuando se compila desde el código fuente, este módulo
no se compila por defecto; debe habilitarse con la opción de
compilación --with-mail_ssl_module.
En paquetes e imágenes de nuestros repositorios, el módulo está incluido en la compilación.
Nota
Este módulo requiere la biblioteca OpenSSL.
Ejemplo de configuración#
Para reducir la carga del procesador, se recomienda:
establecer el número de procesos de trabajo igual al número de procesadores;
habilitar la caché de sesión compartida;
deshabilitar la caché de sesión incorporada;
si es necesario, aumentar el tiempo de vida de la sesión (por defecto, 5 minutos).
Por ejemplo:
worker_processes auto;
mail {
...
server {
listen 993 ssl;
ssl_protocols TLSv1.2 TLSv1.3;
ssl_ciphers AES128-SHA:AES256-SHA:RC4-SHA:DES-CBC3-SHA:RC4-MD5;
ssl_certificate /usr/local/angie/conf/cert.pem;
ssl_certificate_key /usr/local/angie/conf/cert.key;
ssl_session_cache shared:SSL:10m;
ssl_session_timeout 10m;
# ...
}
Directivas#
ssl_certificate#
Especifica el certificado en formato PEM para el servidor dado. Los certificados intermedios, si los hay, siguen al certificado primario en el mismo archivo o valor; también puede colocarse allí una clave secreta en formato PEM.
El valor se interpreta como en la directiva ssl_certificate
del módulo HTTP SSL: una ruta de archivo, o el texto PEM del
certificado tras el prefijo data:. No se admiten variables: el carácter
$ se toma literalmente, como parte del nombre del archivo.
Esta directiva puede especificarse varias veces para cargar certificados de diferentes tipos, por ejemplo, RSA y ECDSA:
server {
listen 993 ssl;
ssl_certificate example.com.rsa.crt;
ssl_certificate_key example.com.rsa.key;
ssl_certificate example.com.ecdsa.crt;
ssl_certificate_key example.com.ecdsa.key;
# ...
}
ssl_certificate_compression#
| |
Predeterminado |
|
mail, server |
Habilita la compresión TLS 1.3 de certificados de servidor.
Nota
La directiva es compatible cuando se usa OpenSSL 3.2 o superior; la lista de algoritmos de compresión soportados es proporcionada por la biblioteca.
Nota
La directiva es compatible cuando se usa BoringSSL; la lista de algoritmos de compresión soportados incluye zlib.
ssl_certificate_key#
| |
Predeterminado | — |
mail, server |
Especifica la clave secreta en formato PEM para el servidor dado.
El valor, incluidos los prefijos engine: y store:, se interpreta
como en la directiva ssl_certificate_key del módulo
HTTP SSL; no se admiten variables. Una clave protegida por una
frase de contraseña se descifra con las frases de contraseña de
ssl_password_file.
ssl_ciphers#
Especifica los cifrados habilitados. Los cifrados se especifican en el formato entendido por la biblioteca OpenSSL, por ejemplo:
ssl_ciphers ALL:!aNULL:!EXPORT56:RC4+RSA:+HIGH:+MEDIUM:+LOW:+SSLv2:+EXP;
La lista de cifrados depende de la versión de OpenSSL instalada.
La lista completa se puede ver usando el comando openssl ciphers.
Advertencia
Con OpenSSL, la directiva ssl_ciphers no configura los cifrados de TLS 1.3;
en su lugar, configúrelos con el comando Ciphersuites de la directiva
ssl_conf_command. La directiva ssl_ciphers ignora los nombres de cifrados
TLS 1.3 de su valor, por lo que dichos nombres no restringen las conexiones
TLS 1.3. Si el valor consta únicamente de tales nombres, por ejemplo
TLS_AES_128_GCM_SHA256, la configuración no se carga y se produce
el error no cipher match.
En LibreSSL, los cifrados TLS 1.3 pueden configurarse usando
ssl_ciphers.En BoringSSL, los cifrados TLS 1.3 no pueden configurarse en absoluto.
ssl_client_certificate#
Especifica un archivo con certificados CA de confianza en formato PEM utilizados para verificar certificados de cliente.
La lista de certificados se enviará a los clientes. Si esto no es deseable, se puede usar la directiva ssl_trusted_certificate.
ssl_conf_command#
Establece comandos de configuración OpenSSL arbitrarios.
Nota
La directiva es compatible cuando se usa OpenSSL 1.0.2 o superior.
El comando Ciphersuites, que configura los cifrados de TLS 1.3, requiere
OpenSSL 1.1.1 o superior.
Se pueden especificar varias directivas ssl_conf_command en el mismo nivel:
ssl_conf_command Options PrioritizeChaCha;
ssl_conf_command Ciphersuites TLS_CHACHA20_POLY1305_SHA256;
Estas directivas se heredan del nivel de configuración anterior si y solo si no hay directivas ssl_conf_command definidas en el nivel actual.
Advertencia
Tenga en cuenta que configurar OpenSSL directamente podría resultar en un comportamiento inesperado.
ssl_crl#
Especifica un archivo con certificados revocados (CRL) en formato PEM utilizado para verificar certificados de cliente.
ssl_dhparam#
Especifica un archivo con parámetros DH para cifrados DHE.
Advertencia
Por defecto no se establecen parámetros, y por lo tanto no se utilizarán cifrados DHE.
ssl_ecdh_curve#
Especifica una curva para cifrados ECDHE.
Nota
Cuando se usa OpenSSL 1.0.2 o superior, es posible especificar múltiples curvas, por ejemplo:
ssl_ecdh_curve prime256v1:secp384r1;
El valor especial auto indica a Angie que use una lista incorporada en la biblioteca OpenSSL cuando se usa OpenSSL 1.0.2 o superior, o prime256v1 con versiones anteriores.
Nota
Cuando se usa OpenSSL 1.0.2 o superior, esta directiva establece la lista de curvas soportadas por el servidor. Por lo tanto, para que los certificados ECDSA funcionen, es importante incluir las curvas utilizadas en los certificados.
ssl_password_file#
Especifica un archivo con frases de contraseña para claves secretas donde cada frase de contraseña se especifica en una línea separada. Las frases de contraseña se prueban sucesivamente al cargar la clave.
Ejemplo:
mail {
ssl_password_file /etc/keys/global.pass;
...
server {
server_name mail1.example.com;
ssl_certificate_key /etc/keys/first.key;
}
server {
server_name mail2.example.com;
# también se puede usar un named pipe en lugar de un archivo
ssl_password_file /etc/keys/fifo;
ssl_certificate_key /etc/keys/second.key;
}
}
ssl_prefer_server_ciphers#
| |
Predeterminado |
|
mail, server |
Especifica que los cifrados del servidor deben ser preferidos sobre los cifrados del cliente cuando se utilizan los protocolos SSLv3 y TLS.
ssl_protocols#
| |
Predeterminado |
|
mail, server |
Habilita los protocolos especificados.
Nota
Los parámetros TLSv1.1 y TLSv1.2 funcionan solo cuando se utiliza OpenSSL 1.0.1 o superior.
El parámetro TLSv1.3 funciona solo cuando se utiliza OpenSSL 1.1.1 o superior.
ssl_session_cache#
| |
Predeterminado |
|
mail, server |
Establece los tipos y tamaños de cachés que almacenan los parámetros de sesión. Una caché puede ser de cualquiera de los siguientes tipos:
| el uso de una caché de sesión está estrictamente prohibido: Angie explícitamente le dice a un cliente que las sesiones no pueden reutilizarse. |
| el uso de una caché de sesión está suavemente desaconsejado: Angie indica al cliente que las sesiones pueden reutilizarse, pero no almacena realmente los parámetros de sesión en la caché. |
| una caché integrada en OpenSSL; utilizada por un único proceso de trabajo. El tamaño de la caché se especifica en sesiones. Si no se proporciona el tamaño, es igual a 20480 sesiones. El uso de la caché integrada puede provocar fragmentación de la memoria. |
| una caché compartida entre todos los procesos de trabajo. El tamaño de la caché se especifica en bytes; un megabyte puede almacenar aproximadamente 4000 sesiones. Cada caché compartida debe tener un nombre arbitrario. Una caché con el mismo nombre puede utilizarse en varios servidores. También se utiliza para generar automáticamente, almacenar y rotar periódicamente las claves de tickets de sesión TLS, a menos que se configure explícitamente mediante la directiva ssl_session_ticket_key. |
Ambos tipos de caché pueden usarse simultáneamente, por ejemplo:
ssl_session_cache builtin:1000 shared:SSL:10m;
pero usar solo la caché compartida sin la caché integrada debería ser más eficiente.
ssl_session_ticket_key#
Establece un archivo con la clave secreta utilizada para cifrar y descifrar los tickets de sesión TLS. La directiva es necesaria si la misma clave debe ser compartida entre múltiples servidores. Por defecto, se utiliza una clave generada aleatoriamente.
Si se especifican varias claves, solo la primera clave se utiliza para cifrar los tickets de sesión TLS. Esto permite configurar la rotación de claves, por ejemplo:
ssl_session_ticket_key current.key;
ssl_session_ticket_key previous.key;
El archivo debe contener 80 o 48 bytes de datos aleatorios y puede ser creado utilizando el siguiente comando:
$ openssl rand 80 > ticket.key
Dependiendo del tamaño del archivo, se utiliza AES256 (para claves de 80 bytes) o AES128 (para claves de 48 bytes) para el cifrado.
ssl_session_tickets#
Habilita o deshabilita la reanudación de sesión a través de tickets de sesión TLS.
ssl_session_timeout#
Especifica un tiempo durante el cual un cliente puede reutilizar los parámetros de sesión.
ssl_trusted_certificate#
Especifica un archivo con certificados CA de confianza en formato PEM usados para verificar certificados de cliente.
A diferencia del conjunto de certificados establecido por ssl_client_certificate, la lista de estos certificados no se enviará a los clientes.
ssl_verify_client#
| |
Predeterminado |
|
mail, server |
Habilita la verificación de certificados de cliente. El resultado de la verificación se pasa en la cabecera Auth-SSL-Verify de la solicitud de autenticación. Si ocurre un error durante la verificación del certificado del cliente o un cliente no proporciona el certificado requerido, la conexión se cierra.
| solicita el certificado del cliente y lo verifica si el certificado está presente |
| solicita el certificado del cliente pero no requiere que esté firmado por un certificado CA de confianza. Esto está destinado a ser utilizado en casos en los que un servicio externo a Angie realiza la verificación real del certificado. El contenido del certificado es accesible a través de solicitudes enviadas al servidor de autenticación. |
ssl_verify_depth#
Establece la profundidad de verificación en la cadena de certificados del cliente.
starttls#
| permite el uso del comando STLS para POP3 y el comando STARTTLS para IMAP y SMTP; |
| deniega el uso de los comandos STLS y STARTTLS; |
| requiere transición TLS preliminar. |
Contenido