Tutorial: configure SSl/TLS en Amazon Linux 2
SSL/TLS (Secure Sockets Layer/Transport Layer Security) crea un canal cifrado entre
un servidor web y el cliente web que protege los datos en tránsito del acceso no autorizado.
En este tutorial, se explica cómo añadir soporte manualmente para SSL/TLS en una instancia
EC2 con Amazon Linux 2 y el servidor web de Apache. En este tutorial, se presupone
que no está utilizando un balanceador de carga. Si utiliza Elastic Load Balancing,
puede elegir configurar la descarga SSL en el balanceador de carga, mediante un certificado
de AWS Certificate Manager
Por motivos históricos, el cifrado web se suele denominar simplemente SSL. Aunque
los navegadores web siguen admitiendo SSL, el protocolo que lo sustituye, TLS, es
menos vulnerable a los ataques. Amazon Linux 2 deshabilita el soporte del lado del
servidos para todas las versiones de SSL de forma predeterminada. Los organismos de normas de seguridad
Este tutorial se refiere a un cifrado web moderno tan simple como TLS.
Estos procedimientos son para usar con Amazon Linux 2. También se supone que comienza
con una instancia Amazon EC2 nueva. Si intenta configurar una instancia EC2 que ejecute
una distribución diferente o una instancia que ejecute una versión anterior de Amazon
Linux 2, es posible que algunos procedimientos de este tutorial no funcionen. Con
la AMI Amazon Linux, consulte Tutorial: configure SSL/TLS con la AMI Amazon Linux. Para Ubuntu, consulte la siguiente documentación de la comunidad de Ubuntu: ApachemySQLPHP
Contenido
Requisitos previos
Siga estos pasos antes de comenzar este tutorial:
-
Lance una instancia de Amazon Linux 2 con respaldo de EBS. Para obtener más información, consulte Paso 1: Lanzamiento de una instancia.
-
Configure los grupos de seguridad para que la instancia acepte conexiones en los siguientes puertos TCP:
-
SSH (puerto 22)
-
HTTP (puerto 80)
-
HTTPS (puerto 443)
Para obtener más información, consulte Autorizar tráfico entrante para las instancias de Linux.
-
-
Instale el servidor web Apache. Para leer las instrucciones detalladas, consulte Tutorial: Instalar un servidor web LAMP enAmazon Linux 2. Solo es necesario el paquete httpd y sus dependencias; por lo que puede omitir las instrucciones relacionadas con PHP y MariaDB.
-
Para identificar y autenticar sitios web, la infraestructura de clave pública (PKI) de TLS se basa en el sistema de nombres de dominio (DNS). Si tiene pensado utilizar la instancia EC2 para alojar un sitio web público, tiene que registrar un nombre de dominio para el servidor web o transferir un nombre de dominio existente al host de Amazon EC2. Para hacer esto, hay disponibles numerosos servicios de registro de dominios y alojamiento de DNS de terceros o bien puede utilizar Amazon Route 53.
Paso 1: Habilitar TLS en el servidor
Este procedimiento le guía a lo largo del proceso de configuración de TLS en Amazon Linux 2 con un certificado digital autofirmado.
Se puede utilizar un certificado autofirmado para las pruebas, pero no para la producción. Si expone a Internet su certificado autofirmado, los visitantes del sitio recibirán advertencias de seguridad.
Para habilitar TLS en un servidor
-
Conéctese a su instancia y confirme que Apache se está ejecutando.
[ec2-user ~]$
sudo systemctl is-enabled httpd
Si el valor devuelto no es "enabled", inicie Apache y configúrelo para que se inicie cada vez que arranque el sistema.
[ec2-user ~]$
sudo systemctl start httpd && sudo systemctl enable httpd
-
Para asegurarse de que todos los paquetes de software están actualizados, realice una actualización rápida del software en la instancia. Este proceso puede durar unos minutos, pero es importante realizarlo para asegurarse de que tiene las actualizaciones de seguridad y las correcciones de errores más recientes.
nota La opción
-y
instala las actualizaciones sin necesidad de confirmación. Si le gustaría examinar las actualizaciones antes de la instalación, puede omitir esta opción.[ec2-user ~]$
sudo yum update -y
-
Ahora que la instancia está actualizada y admite TLS instalando el módulo de Apache
mod_ssl
.[ec2-user ~]$
sudo yum install -y mod_ssl
La instancia tiene ahora los archivos siguientes que utiliza para configurar el servidor seguro y crear un certificado para pruebas:
-
/etc/httpd/conf.d/ssl.conf
El archivo de configuración para mod_ssl. Contiene directivas que le indican a Apache donde encontrar claves de cifrado y certificados, las versiones de protocolo TLS que se permiten y los cifrados que se aceptan.
-
/etc/pki/tls/certs/make-dummy-cert
Un script para generar un certificado X.509 autofirmado y una clave privada para su host de servidor. Este certificado es útil para probar si Apache está configurado correctamente para utilizar TLS. Dado que no ofrece ninguna prueba de identidad, no se debería utilizar en producción. Si se utiliza en la producción, dispara advertencias en los navegadores web.
-
-
Ejecute el script para generar un certificado ficticio autofirmado y una clave para pruebas.
[ec2-user ~]$
cd /etc/pki/tls/certs sudo ./make-dummy-cert localhost.crt
Esto genera un nuevo archivo
localhost.crt
en el directorio/etc/pki/tls/certs/
. El nombre de archivo especificado coincide con el valor predeterminado que se ha asignado en la directiva SSLCertificateFile en/etc/httpd/conf.d/ssl.conf
.Este archivo contiene un certificado autofirmado y la clave privada del certificado. Apache requiere que el certificado y la clave estén en formato PEM que consta de caracteres ASCII codificados en Base64 contenidos entre las líneas "BEGIN" y "END", como en el siguiente ejemplo abreviado.
-----BEGIN PRIVATE KEY----- MIIEvgIBADANBgkqhkiG9w0BAQEFAASCBKgwggSkAgEAAoIBAQD2KKx/8Zk94m1q 3gQMZF9ZN66Ls19+3tHAgQ5Fpo9KJDhzLjOOCI8u1PTcGmAah5kEitCEc0wzmNeo BCl0wYR6G0rGaKtK9Dn7CuIjvubtUysVyQoMVPQ97ldeakHWeRMiEJFXg6kZZ0vr GvwnKoMh3DlK44D9dX7IDua2PlYx5+eroA+1Lqf32ZSaAO0bBIMIYTHigwbHMZoT ... 56tE7THvH7vOEf4/iUOsIrEzaMaJ0mqkmY1A70qQGQKBgBF3H1qNRNHuyMcPODFs 27hDzPDinrquSEvoZIggkDMlh2irTiipJ/GhkvTpoQlv0fK/VXw8vSgeaBuhwJvS LXU9HvYq0U6O4FgD3nAyB9hI0BE13r1HjUvbjT7moH+RhnNz6eqqdscCS09VtRAo 4QQvAqOa8UheYeoXLdWcHaLP -----END PRIVATE KEY----- -----BEGIN CERTIFICATE----- MIIEazCCA1OgAwIBAgICWxQwDQYJKoZIhvcNAQELBQAwgbExCzAJBgNVBAYTAi0t MRIwEAYDVQQIDAlTb21lU3RhdGUxETAPBgNVBAcMCFNvbWVDaXR5MRkwFwYDVQQK DBBTb21lT3JnYW5pemF0aW9uMR8wHQYDVQQLDBZTb21lT3JnYW5pemF0aW9uYWxV bml0MRkwFwYDVQQDDBBpcC0xNzItMzEtMjAtMjM2MSQwIgYJKoZIhvcNAQkBFhVy ... z5rRUE/XzxRLBZOoWZpNWTXJkQ3uFYH6s/sBwtHpKKZMzOvDedREjNKAvk4ws6F0 CuIjvubtUysVyQoMVPQ97ldeakHWeRMiEJFXg6kZZ0vrGvwnKoMh3DlK44D9dlU3 WanXWehT6FiSZvB4sTEXXJN2jdw8g+sHGnZ8zCOsclknYhHrCVD2vnBlZJKSZvak 3ZazhBxtQSukFMOnWPP2a0DMMFGYUHOd0BQE8sBJxg== -----END CERTIFICATE-----
Los nombres y las extensiones de los archivos se utilizan simplemente por comodidad y no afectan al funcionamiento. Por ejemplo, puede llamar a un certificado
cert.crt
,cert.pem
, o cualquier otro nombre de archivo, siempre que la directiva relacionada en el archivossl.conf
utilice el mismo nombre.nota Cuando sustituya los archivos TLS predeterminados por sus propios archivos personalizados, asegúrese de que estén en formato PEM.
-
Abra el archivo
/etc/httpd/conf.d/ssl.conf
y convierta en comentario la siguiente línea, porque el certificado ficticio autofirmado también contiene la clave. Si no convierte en comentario esta línea antes de completar el siguiente paso, se producirá un error al iniciar el servicio de ApacheSSLCertificateKeyFile /etc/pki/tls/private/localhost.key
-
Reinicie Apache.
[ec2-user ~]$
sudo systemctl restart httpd
nota Asegúrese de que el puerto 443 de TCP sea accesible en la instancia EC2, tal y como se ha explicado anteriormente.
-
Ahora el servidor web de Apache debería admitir HTTPS (HTTP seguro) en el puerto 443. Pruébelo escribiendo la dirección IP o el nombre completo de dominio de la instancia EC2 en la barra URL del navegador con el prefijo
https://
.Dado que se va a conectar a un sitio con un certificado de host autofirmado que no es de confianza, es posible que el navegador envíe una serie de advertencias de seguridad. Omita las advertencias y vaya al sitio.
Si se abre la página de prueba de Apache predeterminada, eso significa que ha configurado correctamente TLS en el servidor. Ahora todos los datos que pasan entre el navegador y el servidor se cifran.
nota Para evitar que los visitantes del sitio reciban pantallas de advertencia, tiene que obtener un certificado de confianza firmado por una CA que no solo cifre, sino que también le autentique públicamente como propietario del sitio.
Paso 2: Obtener un certificado firmado por una CA
Puede utilizar el siguiente proceso para obtener un certificado firmado por una CA:
-
Genere una solicitud de firma de certificado (CSR) de una clave privada
-
Envie el CSR a una autoridad de certificación (CA)
-
Obtenga un certificado de host firmado
-
Configure Apache para utilizar el certificado
Un certificado de host TLS X.509 autofirmado es idéntico, desde el punto de vista criptográfico, a un certificado firmado por una CA. La diferencia es social, no matemática. Una CA promete, como mínimo, validar la propiedad de un dominio antes de emitir un certificado para el solicitante. Para ello, cada navegador web contiene una lista de CA de confianza del proveedor del navegador. Un certificado X.509 consta principalmente de una clave pública, que se corresponde con la clave del servidor privado, y una firma de la CA que está vinculada criptográficamente a la clave pública. Cuando un navegador se conecta a un servidor web a través de HTTPS, el servidor presenta un certificado al navegador para que lo compruebe en su lista de CA de confianza. Si el signatario está en la lista o se puede obtener acceso a él a través de una cadena de confianza compuesta por otros signatarios de confianza, el navegador negocia un canal de datos cifrados rápido con el servidor y carga la página.
Generalmente, los certificados cuestan dinero por el trabajo que supone la validación
de las solicitudes, por lo que vale la pena comparar precios. En dmoztools.net
Si planea ofrecer servicios de calidad comercial, AWS Certificate Manager es una buena opción.
La clave es hacer que el certificado del host esté subyacente. Desde 2019, grupos
del gobierno
Estas instrucciones para adquirir un certificado de host firmado por una CA no funcionan a menos que posea un dominio DNS alojado y registrado.
Para obtener un certificado firmado por una CA
-
Conéctese a la instancia y vaya a /etc/pki/tls/private/. Este es el directorio donde almacena la clave privada del servidor para TLS. Si prefiere utilizar una clave de host existente para generar el CSR, vaya al paso 3.
-
(Opcional) Genere una nueva clave privada. Estas son algunas ejemplos de configuraciones clave. Cualquiera de las claves resultantes funciona con el servidor web, pero son diferentes en el grado y el tipo de seguridad que implementan.
-
Ejemplo 1: cree una clave de host RSA predeterminada. El archivo resultante,
custom.key
, es una clave privada RSA de 2048 bits.[ec2-user ~]$
sudo openssl genrsa -out custom.key
-
Ejemplo 2: cree una clave RSA más segura con un módulo mayor. El archivo resultante,
custom.key
, es una clave privada RSA de 4096 bits.[ec2-user ~]$
sudo openssl genrsa -out custom.key 4096
-
Ejemplo 3: cree una clave RSA cifrada de 4096 bits con protección con contraseña. El archivo resultante,
custom.key
, es una clave privada RSA de 4096 bits cifrada con AES-128.importante El cifrado de la clave ofrece mayor seguridad, pero dado que una clave cifrada necesita una contraseña, los servicios que dependen de él no se pueden iniciar automáticamente. Cada vez que utilice esta clave, tiene que proporcionar la contraseña (en el ejemplo anterior "abcde12345") en una conexión SSH.
[ec2-user ~]$
sudo openssl genrsa -aes128 -passout pass:abcde12345 -out custom.key 4096
-
Ejemplo 4: cree una clave con un cifrado que no sea RSA. La criptogarfía RSA puede ser relativamente lenta debido al tamaño de sus claves públicas, que se basan en el producto de dos números primos grandes. Sin embargo, es posible crear claves para TLS que utilicen cifrados que no sean RSA. Las claves que están basadas en el cálculo matemático de curvas elípticas son más pequeñas y más rápidas desde el punto de vista informático a la hora de proporcionar un nivel de seguridad equivalente.
[ec2-user ~]$
sudo openssl ecparam -name prime256v1 -out custom.key -genkey
El resultado es una clave privada de curva elíptica de 256 bits que utiliza prime256v1, una "curva con nombre" que admite OpenSSL. Su seguridad criptográfica es ligeramente mayor que la de una clave RSA de 2048 bits, de acuerdo con NIST
. nota No todas las CA ofrecen el mismo nivel de soporte de claves basadas en curvas elípticas que de claves RSA.
Asegúrese de que la nueva clave privada posee una propiedad y unos permisos muy restrictivos (propietario=raíz, grupo=raíz, lectura/escritura solo para el propietario). Los comandos serán como se muestra en el siguiente ejemplo.
[ec2-user ~]$
sudo chown root:root custom.key
[ec2-user ~]$
sudo chmod 600 custom.key
[ec2-user ~]$
ls -al custom.key
Los comandos anteriores devuelven el siguiente resultado.
-rw------- root root custom.key
Una vez que haya creado y configurado una clave satisfactoria, puede crear una CSR.
-
-
Para crear una CSR, utilice su clave preferida. El siguiente ejemplo utiliza
custom.key
.[ec2-user ~]$
sudo openssl req -new -key custom.key -out csr.pem
OpenSSL abre un cuadro de diálogo y le pide la información que se muestra en la siguiente tabla. Todos los campos, excepto Common Name (Nombre común), son opcionales para un certificado de host de dominio validado básico.
Nombre Descripción Ejemplo Country Name La abreviatura ISO de dos letras del país. US (= Estados Unidos) State or Province Name Nombre del país o de la región donde se ubica su organización. Este nombre no se puede abreviar. Washington Locality Name La ubicación de su organización, como una ciudad. Seattle Organization Name Nombre legal completo de su organización. No abrevie el nombre de la organización. Empresa de ejemplo Organizational Unit Name Información adicional de la organización, si existe. Departamento de ejemplo Common Name Este valor debe ser exactamente igual que la dirección web que espera que introduzcan los usuarios en un navegador. Normalmente, tiene que ser un nombre de dominio precedido por un nombre de host o alias con el formato
www.example.com
. Para realizar pruebas con un certificado autofirmado y sin resolución de DNS, el nombre común puede constar únicamente del nombre de host. Las CA también disponen de certificados más caros que aceptan nombres con comodines, como*.example.com
.www.ejemplo.com Email Address Dirección de correo electrónico del administrador del servidor. alguien@ejemplo.com Por último, OpenSSL le solicita una contraseña de comprobación opcional. Esta contraseña solo se aplica a la CSR y a las transacciones entre usted y la CA, así que siga las recomendaciones de la CA a este respecto y el otro campo opcional, es decir, el nombre de empresa opcional. La contraseña de comprobación de CSR no afecta al funcionamiento del servidor.
El archivo resultante,
csr.pem
contiene la clave pública, la firma digital de la clave pública y los metadatos que ha especificado. -
Envíe la CSR a una CA. Este proceso suele consistir en abrir el archivo CSR en un editor de texto y copiar el contenido en un formulario web. Es posible que, en este momento, se le solicite que introduzca uno o varios nombres de asunto alternativos (SAN) para que aparezcan en el certificado. Si el nombre común es
www.example.com
,example.com
sería un buen SAN y viceversa. Un visitante de su sitio que introdujese cualquiera de estos nombres no recibiría ningún error de conexión. Si el formato web de la CA lo permite, incluya el nombre común en la lista de SAN. Algunas CA lo incluyen automáticamente.Una vez aprobada su solicitud, recibe un nuevo certificado de host firmado por la CA. Es posible que también tenga que descargar un archivo de certificado intermedio que contiene los certificados adicionales necesarios para completar la cadena de confianza de la CA.
nota La CA puede enviarle archivos en diversos formatos destinados a diversos fines. Para este tutorial, solo debe utilizar un archivo de certificado en formato PEM, que normalmente (aunque no siempre) está marcado con la extensión de archivo
.pem
o.crt
. Si no tiene claro qué archivo debe utilizar, abra los archivos con un editor de texto y busque el que contiene uno o varios bloques que comienzan con la siguiente línea.- - - - -BEGIN CERTIFICATE - - - - -
El archivo debería terminar también con la siguiente línea.
- - - -END CERTIFICATE - - - - -
También puede probar el archivo en la línea de comandos, tal y como se muestra a continuación.
[ec2-user certs]$
openssl x509 -in
certificate.crt
-textVerifique que estas líneas aparecen en el archivo. No utilice archivos que terminen con
.p7b
,.p7c
o extensiones de archivos similares. -
Coloque el nuevo certificado firmado por la CA y cualquier certificado intermedio en el directorio
/etc/pki/tls/certs
.nota Hay varias formas de cargar el nuevo certificado en la instancia EC2, pero la más sencilla e informativa consiste en abrir un editor de texto (por ejemplo, vi, nano o notepad) en el equipo local y en la instancia y, a continuación, copiar y pegar el contenido del archivo de uno al otro. Para realizar estas operaciones en la instancia EC2, necesita permisos de raíz [sudo]. De esta forma, puede ver inmediatamente si hay algún problema con los permisos o las rutas. Procure, no obstante, no añadir más líneas al copiar el contenido o cambiarlo de ninguna forma.
Compruebe, desde el interior del directorio
/etc/pki/tls/certs
, que los ajustes de propiedad del archivo, grupo y permisos se corresponden con los ajustes predeterminados enormemente restrictivos de Amazon Linux 2 (propietario=raíz, grupo=raíz, lectura/escritura solo para el propietario). En el siguiente ejemplo, se muestran los comandos que se utilizarán.[ec2-user certs]$
sudo chown root:root custom.crt
[ec2-user certs]$
sudo chmod 600 custom.crt
[ec2-user certs]$
ls -al custom.crt
Estos comandos deberían devolver el siguiente resultado.
-rw------- root root custom.crt
Los permisos del archivo de certificado intermedio son menos estrictos (propietario=raíz, grupo=raíz, propietario puede escribir, grupo puede leer, mundo puede leer). En el siguiente ejemplo, se muestran los comandos que se utilizarán.
[ec2-user certs]$
sudo chown root:root intermediate.crt
[ec2-user certs]$
sudo chmod 644 intermediate.crt
[ec2-user certs]$
ls -al intermediate.crt
Estos comandos deberían devolver el siguiente resultado.
-rw-r--r-- root root intermediate.crt
-
Coloque la clave privada que utilizó para crear la CSR en el directorio
/etc/pki/tls/private/
.nota Hay varias formas de cargar la clave personalizada en la instancia EC2, pero la más sencilla e informativa consiste en abrir un editor de texto (por ejemplo, vi, nano o notepad) en el equipo local y en la instancia y, a continuación, copiar y pegar el contenido del archivo de uno al otro. Para realizar estas operaciones en la instancia EC2, necesita permisos de raíz [sudo]. De esta forma, puede ver inmediatamente si hay algún problema con los permisos o las rutas. Procure, no obstante, no añadir más líneas al copiar el contenido o cambiarlo de ninguna forma.
Utilice, desde el interior del directorio
/etc/pki/tls/private
, los siguientes comandos para verificar que la propiedad del archivo, grupo y permisos se corresponden con los ajustes predeterminados enormemente restrictivos de Amazon Linux 2 (propietario=raíz, grupo=raíz, lectura/escritura solo para el propietario).[ec2-user private]$
sudo chown root:root custom.key
[ec2-user private]$
sudo chmod 600 custom.key
[ec2-user private]$
ls -al custom.key
Estos comandos deberían devolver el siguiente resultado.
-rw------- root root custom.key
-
Edite
/etc/httpd/conf.d/ssl.conf
para reflejar el nuevo certificado y los archivos de claves.-
Proporcione la ruta y el nombre de archivo del certificado de host firmado por la CA en la directiva
SSLCertificateFile
de Apache:SSLCertificateFile /etc/pki/tls/certs/custom.crt
-
Si ha recibido un archivo de certificado intermedio (
intermediate.crt
en este ejemplo), proporcione su ruta y nombre de archivo utilizando la directivaSSLCACertificateFile
de Apache:SSLCACertificateFile /etc/pki/tls/certs/intermediate.crt
nota Algunas CA combinan el certificado de host y los certificados intermedios en un solo archivo, por lo que, en ese caso, la directiva
SSLCACertificateFile
es innecesaria. Consulte las instrucciones que le ha proporcionado su CA. -
Proporcione la ruta y el nombre de archivo de la clave privada (
custom.key
en este ejemplo) en la directivaSSLCertificateKeyFile
de Apache:SSLCertificateKeyFile /etc/pki/tls/private/custom.key
-
-
Guarde
/etc/httpd/conf.d/ssl.conf
y reinicie Apache.[ec2-user ~]$
sudo systemctl restart httpd
-
Pruebe el servidor introduciendo su nombre de dominio en una barra de direcciones URL del navegador con el prefijo
https://
. El navegador debería cargar la página de prueba sobre HTTPS sin generar errores.
Paso 3: Probar y reforzar la configuración de seguridad
Cuando su TLS esté en funcionamiento y expuesto al público, debería probar su seguridad.
Esta operación es muy sencilla con servicios online como Qualys SSL Labs
Las pruebas reales son cruciales para la seguridad del servidor. Cualquier pequeño error de configuración puede provocar graves infracciones de seguridad y la pérdida de datos. Dado que las prácticas de seguridad recomendadas cambian continuamente en respuesta a las investigaciones y a las continuas amenazas, es esencial realizar auditorías de seguridad periódicas para mantener una buena administración del servidor.
En el sitio de Qualys SSL Labswww.example.com
. Dos minutos después recibirá una puntuación (de A a F) de su sitio y un desglose
detallado de los descubrimientos. En la siguiente tabla, se resume el informe de un
dominio que tiene la misma configuración que la predeterminada de Apache en Amazon
Linux 2 y con un certificado de Certbot predeterminado:
Calificación global | B |
Certificate | 100% |
Compatibilidad del protocolo | 95% |
Intercambio de clave | 70 % |
Seguridad del cifrado | 90% |
Aunque la información general muestra que la configuración es correcta, el informe detallado indica algunos posibles problemas, indicados aquí en orden de gravedad:
✗ Algunos navegadores más antiguos admiten el uso del cifrado RC4. Un cifrado es el núcleo matemático de un algoritmo de cifrado. Se sabe que RC4, un
cifrado rápido que sirve para cifrar flujos de datos TLS, tiene varios puntos débiles importantes
✗ Se admiten las versiones antiguas de TLS. La configuración admite TLS 1.0 (ya obsoleto) y TLS 1.1 (en vías de ser declarado obsoleto). Desde 2018 solo se ha recomendado TLS 1.2.
✗ La confidencialidad directa no se admite por completo. La confidencialidad directa
Para corregir y preparar para el futuro la configuración de TLS
-
Abra el archivo de configuración
/etc/httpd/conf.d/ssl.conf
en un editor de texto y comente la línea siguiente introduciendo "#" al principio de la línea.#SSLProtocol all -SSLv3
-
Añada la siguiente directiva:
#SSLProtocol all -SSLv3 SSLProtocol -SSLv2 -SSLv3 -TLSv1 -TLSv1.1 +TLSv1.2
Esta directiva deshabilita explícitamente las versiones 2 y 3 de SSL, además de las versiones 1.0 y 1.1 de TLS. Ahora, el servidor se niega a aceptar conexiones cifradas con clientes que no utilicen versiones compatibles de TLS 1.2. El texto de la directiva transmite con más claridad a un lector humano las acciones que se han configurado que haga el servidor.
nota Al deshabilitar las versiones 1.0 y 1.1 de TLS de esta manera, bloquea un pequeño porcentaje de navegadores web desactualizados y evita que obtengan acceso a su sitio.
Para modificar la lista de cifrados permitidos
-
En el archivo de configuración
/etc/httpd/conf.d/ssl.conf
, encuentre la sección con la directivaSSLCipherSuite
y comente la línea existente al introducir “#· al principio de la línea.#SSLCipherSuite HIGH:MEDIUM:!aNULL:!MD5
-
Especifique conjuntos de cifrado explícitos y un orden de cifrado que dé prioridad a la confidencialidad directa y evite los cifrados inseguros. La directiva
SSLCipherSuite
que se utiliza aquí se basa en el resultado del Mozilla SSL Configuration Generator, que personaliza una configuración de TLS al software específico que se ejecuta en su servidor. (Para obtener más información, consulte el útil recurso de Mozilla Security/Server Side TLS .) En primer lugar, determine sus versiones de Apache y OpenSSL utilizando la salida de los comandos siguientes. [ec2-user ~]$
yum list installed | grep httpd
[ec2-user ~]$
yum list installed | grep openssl
Por ejemplo, si la información devuelta es Apache 2.4.34 y OpenSSL 1.0.2, lo introducimos en el generador. Después elegimos el modelo de compatibilidad «moderno», esto crea una directiva
SSLCipherSuite
que aplica seguridad de forma agresiva pero sigue funcionando para la mayoría de navegadores. Si el navegador no admite la configuración moderna, puede actualizar el software o elegir la configuración «intermedia» en su lugar.SSLCipherSuite ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305: ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256: ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256
Los cifrados con la calificación más alta tienen ECDHE en su nombre, una abreviatura de Elliptic Curve Diffie-Hellman Ephemeral. El término ephemeral indica confidencialidad directa. Como subproducto, estos cifrados no admiten RC4.
Le recomendamos utilizar una lista de cifrados explícita en lugar de utilizar valores predeterminados o directivas escuetas cuyo contenido no es visible.
Copie la directiva generada en
/etc/httpd/conf.d/ssl.conf
nota Aunque aquí se muestran en varias líneas para que la lectura sea más sencilla, la directiva debe estar en una sola línea cuando se copia a
/etc/httpd/conf.d/ssl.conf
con un solo símbolo de dos puntos (sin espacios) entre los nombres de los cifrados. -
Por último, cancele el comentario de la siguiente línea eliminando el "#" al principio de la línea.
#SSLHonorCipherOrder on
Esta directiva obliga al servidor a preferir cifrados con una calificación alta, incluidos (en este caso) los que admiten la confidencialidad directa. Con esta directiva activada, el servidor intenta establecer una conexión muy segura antes de recurrir a los cifrados permitidos con menor seguridad.
Después de completar ambos procedimientos, guarde los cambios en /etc/httpd/conf.d/ssl.conf
y reinicie Apache.
Si vuelve a probar el dominio en Qualys SSL Labs
Calificación global | A |
Certificate | 100% |
Compatibilidad del protocolo | 100% |
Intercambio de clave | 90% |
Seguridad del cifrado | 90% |
En cada actualización de OpenSSL, se introducen nuevos cifrados y se elimina la compatibilidad
con los antiguos. Mantenga actualizada la instancia EC2 de Amazon Linux 2, esté pendiente
de las novedades sobre seguridad de OpenSSL
Solucionar problemas
-
Mi servidor web Apache no se inicia a menos que especifique una contraseña
Es el comportamiento esperado si ha instalado una clave de servidor privado cifrada y protegida mediante contraseña.
Puede eliminar el cifrado y el requisito de contraseña de la clave. Supongamos que tiene una clave RSA cifrada privada que se denomina
custom.key
en el directorio predeterminado y que su contraseña esabcde12345
. Ejecute los siguientes comandos en la instancia EC2 para generar una versión no cifrada de la clave.[ec2-user ~]$
cd /etc/pki/tls/private/
[ec2-user private]$
sudo cp custom.key custom.key.bak
[ec2-user private]$
sudo openssl rsa -in custom.key -passin pass:abcde12345 -out custom.key.nocrypt
[ec2-user private]$
sudo mv custom.key.nocrypt custom.key
[ec2-user private]$
sudo chown root:root custom.key
[ec2-user private]$
sudo chmod 600 custom.key
[ec2-user private]$
sudo systemctl restart httpd
Ahora, Apache debería iniciarse sin solicitarle una contraseña.
-
Recibo errores cuando ejecuto sudo yum install -y mod_ssl.
Al instalar los paquetes necesarios para SSL, puede que aparezcan errores similares a los siguientes:
Error: httpd24-tools conflicts with httpd-tools-2.2.34-1.16.amzn1.x86_64 Error: httpd24 conflicts with httpd-2.2.34-1.16.amzn1.x86_64
Esto normalmente significa que la instancia de EC2 no está ejecutando Amazon Linux 2. Este tutorial solo admite instancias recién creadas a partir de una AMI de Amazon Linux 2 oficial.
Certificate Automation: Let's Encrypt with Certbot on Amazon Linux 2
La entidad de certificación Let's Encrypt
Oficialmente Certbot no es compatible con Amazon Linux 2, pero está disponible para descarga y funciona correctamente cuando se instala. Le recomendamos que realice las siguientes copias de seguridad para proteger sus datos y evitar problemas:
-
Antes de comenzar, tome una instantánea de su volumen raíz de Amazon EBS. Esto le permitirá restaurar el estado original de su instancia EC2. Para obtener más información acerca de la creación de instantáneas de EBS, consulte Crear instantáneas de Amazon EBS.
-
El procedimiento siguiente requiere que edite su archivo
httpd.conf
, que controla el funcionamiento de Apache. Certbot realiza sus propios cambios automatizados en este y en otros archivos de configuración. Realice una copia de seguridad de todo su directorio/etc/httpd
en caso de que tenga que restaurarlo.
Preparativos para la instalación
Lleve a cabo los procedimientos siguientes antes de instalar Certbot.
-
Descargue los paquetes del repositorio de los paquetes extra de Enterprise Linux (EPEL) 7. Son obligatorios para proporcionar las dependencias que necesita Certbot.
-
Vaya al directorio de inicio (
/home/ec2-user
). Descargue EPEL con el siguiente comando.[ec2-user ~]$
sudo wget -r --no-parent -A 'epel-release-*.rpm' https://dl.fedoraproject.org/pub/epel/7/x86_64/Packages/e/
-
Instale los paquetes del repositorio como se muestra en el siguiente comando.
[ec2-user ~]$
sudo rpm -Uvh dl.fedoraproject.org/pub/epel/7/x86_64/Packages/e/epel-release-*.rpm
-
A continuación, ejecute EPEL como se muestra en el siguiente comando.
[ec2-user ~]$
sudo yum-config-manager --enable epel*
Puede confirmar que EPEL está habilitado con el siguiente comando.
[ec2-user ~]$
sudo yum repolist all
Debería devolver información similar a la siguiente.
[ec2-user ~]$
... epel/x86_64 Extra Packages for Enterprise Linux 7 - x86_64 enabled: 12949+175 epel-debuginfo/x86_64 Extra Packages for Enterprise Linux 7 - x86_64 - Debug enabled: 2890 epel-source/x86_64 Extra Packages for Enterprise Linux 7 - x86_64 - Source enabled: 0 epel-testing/x86_64 Extra Packages for Enterprise Linux 7 - Testing - x86_64 enabled: 778+12 epel-testing-debuginfo/x86_64 Extra Packages for Enterprise Linux 7 - Testing - x86_64 - Debug enabled: 107 epel-testing-source/x86_64 Extra Packages for Enterprise Linux 7 - Testing - x86_64 - Source enabled: 0 ...
-
-
Edite el archivo de configuración principal de Apache,
/etc/httpd/conf/httpd.conf
. Localice la política "Listen 80
" y añada las siguientes líneas detrás, sustituyendo los nombres de dominio de ejemplo por el nombre común y el nombre alternativo del firmante (SAN) reales.<VirtualHost *:80> DocumentRoot "/var/www/html" ServerName "
example.com
" ServerAlias "www.example.com
" </VirtualHost>Guarde el archivo y reinicie Apache.
[ec2-user ~]$
sudo systemctl restart httpd
Instalar y ejecutar Certbot
Este procedimiento se basa en la documentación de la EFF para la instalación de Certbot
en Fedora
-
Instale los paquetes y dependencias de Certbot utilizando el comando siguiente.
[ec2-user ~]$
sudo yum install -y certbot python2-certbot-apache
-
Ejecute Certbot.
[ec2-user ~]$
sudo certbot
-
Cuando aparezca "Enter email address (used for urgent renewal and security notices)," introduzca una dirección de contacto y pulse Intro.
-
Acepte las condiciones de servicio de Let's Encrypt en el mensaje. Introduzca "A" y pulse Intro para continuar:
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Please read the Terms of Service at https://letsencrypt.org/documents/LE-SA-v1.2-November-15-2017.pdf. You must agree in order to register with the ACME server at https://acme-v02.api.letsencrypt.org/directory - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - (A)gree/(C)ancel:
A
-
En la autorización para que EFF le incluya en su lista de correo, introduzca "Y" o "N" y pulse Intro.
-
Certbot muestra el nombre común y el nombre alternativo del firmante (SAN) que proporcionó en el bloque VirtualHost.
Which names would you like to activate HTTPS for? - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 1:
example.com
2:www.example.com
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Select the appropriate numbers separated by commas and/or spaces, or leave input blank to select all options shown (Enter 'c' to cancel):Déjelo en blanco y pulse Intro.
-
Certbot muestra la siguiente salida cuando crea certificados y configura Apache. A continuación, le indica que redirija las consultas HTTP a HTTPS.
Obtaining a new certificate Performing the following challenges: http-01 challenge for
example.com
http-01 challenge forwww.example.com
Waiting for verification... Cleaning up challenges Created an SSL vhost at /etc/httpd/conf/httpd-le-ssl.conf Deploying Certificate forexample.com
to VirtualHost /etc/httpd/conf/httpd-le-ssl.conf Enabling site /etc/httpd/conf/httpd-le-ssl.conf by adding Include to root configuration Deploying Certificate forwww.example.com
to VirtualHost /etc/httpd/conf/httpd-le-ssl.conf Please choose whether or not to redirect HTTP traffic to HTTPS, removing HTTP access. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 1: No redirect - Make no further changes to the webserver configuration. 2: Redirect - Make all requests redirect to secure HTTPS access. Choose this for new sites, or if you're confident your site works on HTTPS. You can undo this change by editing your web server's configuration. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Select the appropriate number [1-2] then [enter] (press 'c' to cancel):Para permitir a los visitantes que se conecten a su servidor a través de HTTP sin cifrar, introduzca "1". Si desea aceptar solo las conexiones cifradas a través de HTTPS, introduzca "2". Pulse Intro para enviar su elección.
-
Certbot completa la configuración de Apache, confirma si se ha realizado correctamente y notifica otra información.
Congratulations! You have successfully enabled https://example.com and https://www.example.com You should test your configuration at: https://www.ssllabs.com/ssltest/analyze.html?d=example.com https://www.ssllabs.com/ssltest/analyze.html?d=www.example.com - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - IMPORTANT NOTES: - Congratulations! Your certificate and chain have been saved at: /etc/letsencrypt/live/certbot.oneeyedman.net/fullchain.pem Your key file has been saved at: /etc/letsencrypt/live/certbot.oneeyedman.net/privkey.pem Your cert will expire on 2019-08-01. To obtain a new or tweaked version of this certificate in the future, simply run certbot again with the "certonly" option. To non-interactively renew *all* of your certificates, run "certbot renew" - Your account credentials have been saved in your Certbot configuration directory at /etc/letsencrypt. You should make a secure backup of this folder now. This configuration directory will also contain certificates and private keys obtained by Certbot so making regular backups of this folder is ideal.
-
Cuando termine la instalación, pruebe y optimice la seguridad del servidor, tal y como se describe en Paso 3: Probar y reforzar la configuración de seguridad.
Configurar la renovación automática de certificados
Certbot está diseñado para ser una parte invisible y resistente a errores del sistema del servidor. De manera predeterminada, genera certificados del host con un período de vencimiento corto de 90 días. Si no ha configurado el sistema para llamar al comando de manera automática, debe volver a ejecutar el comando certbot de manera manual antes de que venza. Este procedimiento le enseña a automatizar Certbot configurando un trabajo cron.
Para automatizar Certbot
-
Abra el archivo
/etc/crontab
con cualquier editor de texto (como vim o nano) mediante sudo. Para otras opciones, consulte sudo crontab -e. -
Añada una línea similar a la siguiente y guarde el archivo.
39 1,13 * * * root certbot renew --no-self-upgrade
Aquí se explica cada componente:
39 1,13 * * *
-
Programa la ejecución de un comando a las 01:39 y 13:39 todos los días. Los valores seleccionados son arbitrarios, pero los desarrolladores de Certbot sugieren que el comando se ejecute al menos dos veces al día. Esto garantiza que cualquier certificado comprometido que se encuentre se revocará y sustituirá rápidamente.
root
-
El comando se ejecuta con permisos de raíz.
certbot renew --no-self-upgrade
-
El comando que se va a ejecutar. El subcomando renew hace que Certbot compruebe cualquier certificado que se haya obtenido previamente y que renueve los que están próximos a la fecha de vencimiento. El indicador
--no-self-upgrade
evita que Certbot se actualice sin su intervención.
-
Reinicie el demonio cron:
[ec2-user ~]$
sudo systemctl restart crond