Configuración SSL#
Para configurar un servidor HTTPS, el parámetro ssl debe estar habilitado en los sockets de escucha dentro del bloque server, y se deben especificar las ubicaciones de los archivos del certificado del servidor y de la clave privada:
server {
listen 443 ssl;
server_name www.example.com;
ssl_certificate www.example.com.crt;
ssl_certificate_key www.example.com.key;
ssl_protocols TLSv1.2 TLSv1.3;
ssl_ciphers HIGH:!aNULL:!MD5;
#...
}
El certificado del servidor es un certificado público. Se envía a cada cliente que se conecta al servidor. La clave privada es un dato sensible y debe almacenarse en un archivo con acceso restringido; sin embargo, debe ser legible por el proceso maestro de Angie. La clave privada también puede almacenarse en el mismo archivo que el certificado.
ssl_certificate www.example.com.cert;
ssl_certificate_key www.example.com.cert;
En ese caso, los derechos de acceso al archivo también deben estar restringidos. Aunque el certificado y la clave se almacenan en un único archivo, solo se envía el certificado al cliente.
Las directivas ssl_protocols y ssl_ciphers pueden usarse para limitar las conexiones e incluir únicamente las versiones y cifrados fuertes de SSL/TLS. Por defecto, Angie utiliza:
ssl_protocols TLSv1.2 TLSv1.3;
ssl_ciphers HIGH:!aNULL:!MD5;
Por lo tanto, configurarlas explícitamente generalmente no es necesario. Las operaciones SSL consumen recursos adicionales de CPU. En sistemas multiprocesador, se deben ejecutar varios procesos de trabajo, no menos de la cantidad de núcleos de CPU disponibles. La operación más intensiva en CPU es el handshake SSL. Hay dos formas de minimizar el número de estas operaciones por cliente: la primera es habilitando conexiones keepalive para enviar varias solicitudes a través de una única conexión, y la segunda es reutilizar los parámetros de sesión SSL para evitar handshakes SSL en conexiones paralelas y subsiguientes. Las sesiones se almacenan en una caché de sesiones SSL compartida entre los trabajadores y configurada por la directiva ssl_session_cache. Un megabyte de la caché contiene aproximadamente 4000 sesiones. El tiempo de espera predeterminado de la caché es de 5 minutos. Puede aumentarse utilizando la directiva ssl_session_timeout. Aquí hay una configuración de ejemplo optimizada para un sistema multinúcleo con una caché de sesiones compartida de 10m: Algunos navegadores pueden quejarse de un certificado firmado por una autoridad certificadora reconocida, mientras que otros navegadores pueden aceptar el certificado sin problemas. Esto ocurre porque la autoridad emisora ha firmado el certificado del servidor utilizando un certificado intermedio que no está presente en la base de certificados de confianza distribuida con un navegador particular. En este caso, la autoridad proporciona un conjunto de certificados encadenados que deben concatenarse al certificado firmado del servidor. El certificado del servidor debe aparecer antes que los certificados encadenados en el archivo combinado: El archivo resultante debe utilizarse con la directiva ssl_certificate: Si el certificado del servidor y el conjunto se concatenaron en el orden incorrecto, Angie no se inicia y muestra un mensaje de error: (SSL: error:0B080074:x509 certificate routines:
X509_check_private_key:key values mismatch) Esto ocurre porque Angie intentó usar la clave privada con el primer certificado del conjunto en lugar del certificado del servidor. Los navegadores generalmente almacenan certificados intermedios que reciben, firmados por autoridades de confianza, por lo que los navegadores que se utilizan habitualmente pueden ya tener los certificados intermedios requeridos y no quejarse de un certificado enviado sin un conjunto encadenado. Para asegurar que el servidor envía la cadena de certificados completa, se puede utilizar la utilidad de línea de comandos openssl, por ejemplo: Truco Al probar configuraciones con SNI, es importante especificar la opción -servername, ya que openssl no utiliza SNI por defecto. En este ejemplo, el sujeto ("s") del certificado del servidor www.GoDaddy.com #0 está firmado por un emisor ("i") que a su vez es el sujeto del certificado #1, que está firmado por un emisor que a su vez es el sujeto del certificado #2, que está firmado por el emisor conocido ValiCert, Inc. cuyo certificado está almacenado en la base de certificados integrada de los navegadores. Si no se ha añadido un conjunto de certificados, solo se mostrará el certificado del servidor #0. Es posible configurar un único servidor que maneje tanto peticiones HTTP como HTTPS: Un problema común surge al configurar dos o más servidores HTTPS escuchando en una única dirección IP: Con esta configuración, un navegador recibe el certificado del servidor predeterminado, es decir, www.example.com, independientemente del nombre de servidor solicitado. Esto es causado por el comportamiento del protocolo SSL. La conexión SSL se establece antes de que el navegador envíe una solicitud HTTP, y Angie no conoce el nombre del servidor solicitado. Por lo tanto, solo puede ofrecer el certificado del servidor predeterminado. El método más antiguo y robusto para resolver el problema es asignar una dirección IP separada para cada servidor HTTPS: Existen otras formas que permiten compartir una única dirección IP entre varios servidores HTTPS. Sin embargo, todas ellas tienen sus inconvenientes. Una forma es usar un certificado con varios nombres en el campo Otra forma es usar un certificado con un nombre comodín, por ejemplo, Es mejor colocar un archivo de certificado con varios nombres y su archivo de clave privada en el nivel de configuración Una solución más genérica para ejecutar varios servidores HTTPS en una única dirección IP es la extensión TLS Server Name Indication (SNI, RFC 6066), que permite a un navegador pasar el nombre del servidor solicitado durante el handshake SSL, y por lo tanto, el servidor sabrá qué certificado debe usar para la conexión. SNI es actualmente compatible con la mayoría de los navegadores modernos, aunque puede no ser utilizado por algunos clientes antiguos o especiales. Truco Solo los nombres de dominio pueden pasarse en SNI; sin embargo, algunos navegadores pueden pasar erróneamente una dirección IP del servidor como su nombre si una solicitud incluye una dirección IP literal. No se debe confiar en esto. Si Angie fue compilado con soporte para SNI, entonces Angie mostrará esto al ejecutarse con el interruptor Sin embargo, si Angie habilitado para SNI está vinculado dinámicamente a una biblioteca OpenSSL sin soporte para SNI, Angie mostrará una advertencia: Angie was built with SNI support, however, now it is linked
dynamically to an OpenSSL library which has no tlsext support,
therefore SNI is not availableOptimización del Servidor HTTPS#
worker_processes auto;
http {
ssl_session_cache shared:SSL:10m;
ssl_session_timeout 10m;
server {
listen 443 ssl;
server_name www.example.com;
keepalive_timeout 70;
ssl_certificate www.example.com.crt;
ssl_certificate_key www.example.com.key;
ssl_protocols TLSv1.2 TLSv1.3;
ssl_ciphers HIGH:!aNULL:!MD5;
#...
Cadena de Certificados SSL#
$ cat www.example.com.crt bundle.crt > www.example.com.chained.crt
server {
listen 443 ssl;
server_name www.example.com;
ssl_certificate www.example.com.chained.crt;
ssl_certificate_key www.example.com.key;
#...
}
$ openssl s_client -connect www.godaddy.com:443
Certificate chain
0 s:/C=US/ST=Arizona/L=Scottsdale/1.3.6.1.4.1.311.60.2.1.3=US
/1.3.6.1.4.1.311.60.2.1.2=AZ/O=GoDaddy.com, Inc
/OU=MIS Department/CN=www.GoDaddy.com
/serialNumber=0796928-7/2.5.4.15=V1.0, Clause 5.(b)
i:/C=US/ST=Arizona/L=Scottsdale/O=GoDaddy.com, Inc.
/OU=http://certificates.godaddy.com/repository
/CN=Go Daddy Secure Certification Authority
/serialNumber=07969287
1 s:/C=US/ST=Arizona/L=Scottsdale/O=GoDaddy.com, Inc.
/OU=http://certificates.godaddy.com/repository
/CN=Go Daddy Secure Certification Authority
/serialNumber=07969287
i:/C=US/O=The Go Daddy Group, Inc.
/OU=Go Daddy Class 2 Certification Authority
2 s:/C=US/O=The Go Daddy Group, Inc.
/OU=Go Daddy Class 2 Certification Authority
i:/L=ValiCert Validation Network/O=ValiCert, Inc.
/OU=ValiCert Class 2 Policy Validation Authority
/CN=http://www.valicert.com//emailAddress=info@valicert.com
Un Único Servidor HTTP/HTTPS#
server {
listen 80;
listen 443 ssl;
server_name www.example.com;
ssl_certificate www.example.com.crt;
ssl_certificate_key www.example.com.key;
#...
}
Servidores HTTPS Basados en Nombres#
server {
listen 443 ssl;
server_name www.example.com;
ssl_certificate www.example.com.crt;
#...
}
server {
listen 443 ssl;
server_name www.example.org;
ssl_certificate www.example.org.crt;
#...
}
server {
listen 192.168.1.1:443 ssl;
server_name www.example.com;
ssl_certificate www.example.com.crt;
#...
}
server {
listen 192.168.1.2:443 ssl;
server_name www.example.org;
ssl_certificate www.example.org.crt;
#...
}
Un Certificado SSL con Múltiples Nombres#
SubjectAltName del certificado, por ejemplo, www.example.com y www.example.org. Sin embargo, la longitud del campo SubjectAltName es limitada.*.example.org. Un certificado comodín protege todos los subdominios del dominio especificado, pero solo en un nivel. Este certificado coincide con www.example.org pero no coincide con example.org ni con www.sub.example.org. Estos dos métodos también se pueden combinar. Un certificado puede contener nombres exactos y comodín en el campo SubjectAltName, por ejemplo, example.org y *.example.org.http para heredar una única copia en memoria en todos los servidores:ssl_certificate common.crt;
ssl_certificate_key common.key;
server {
listen 443 ssl;
server_name www.example.com;
#...
}
server {
listen 443 ssl;
server_name www.example.org;
#...
}
Indicación de Nombre de Servidor#
-V:$ angie -V
...
TLS SNI support enabled
...
Contenido