Cómo crear un certificado SSL autofirmado para Nginx en Debian 10

Introducción

TLS, o seguridad de la capa de transporte, y su predecesor SSL, que significa capa de sockets seguros, son protocolos web utilizados para envolver el tráfico normal en un contenedor protegido y cifrado.

Con esta tecnología, los servidores pueden enviar tráfico de forma segura entre el servidor y los clientes sin posibilidad de que los mensajes sean interceptados por terceros. El sistema de certificados también ayuda a los usuarios a verificar la identidad de los sitios a los que se conectan.

En esta guía, le mostraremos cómo configurar un certificado SSL autofirmado para usar con un servidor web Nginx en un servidor Debian 10.

Nota: Un certificado autofirmado cifrará la comunicación entre su servidor y cualquier cliente. Sin embargo, dado que no está firmado por ninguna de las autoridades de certificación de confianza incluidas en los navegadores web, los usuarios no pueden utilizar el certificado para validar la identidad de su servidor automáticamente.

Un certificado autofirmado puede ser adecuado si no tiene un nombre de dominio asociado con su servidor y para casos en los que la interfaz web cifrada no está orientada al usuario. Si tiene un nombre de dominio, en muchos casos es mejor utilizar un certificado firmado por una CA. Para aprender a configurar un certificado de confianza gratuito con el proyecto Let's Encrypt, consulte Cómo proteger Nginx con Let's Encrypt en Debian 10.

Prerrequisitos

• Un servidor Debian 10, un usuario no root con sudoprivilegios y un cortafuegos activo. Para configurar todo esto, siga el tutorial de configuración inicial del servidor para Debian 10.
• Nginx instalado en su servidor, siguiendo Cómo instalar Nginx en Debian 10.

Paso 1: Creación del certificado SSL

TLS/SSL funciona mediante una combinación de un certificado público y una clave privada. La clave SSL se mantiene en secreto en el servidor y se utiliza para cifrar el contenido enviado a los clientes. El certificado SSL se comparte públicamente con cualquier persona que solicite el contenido. Se puede utilizar para descifrar el contenido firmado por la clave SSL asociada.

Podemos crear un par de clave y certificado autofirmado con OpenSSL en un solo comando:

sudo openssl req -x509 -nodes -days 365 -newkey rsa:2048 -keyout /etc/ssl/private/nginx-selfsigned.key -out /etc/ssl/certs/nginx-selfsigned.crt

Se le harán una serie de preguntas. Antes de analizarlas, veamos qué sucede en el comando que estamos emitiendo:

• openssl : esta es la herramienta de línea de comandos básica para crear y administrar certificados, claves y otros archivos OpenSSL.
• req : este subcomando especifica que queremos utilizar la gestión de solicitudes de firma de certificados (CSR) X.509. “X.509” es un estándar de infraestructura de clave pública al que SSL y TLS adhieren para la gestión de claves y certificados. Queremos crear un nuevo certificado X.509, por lo que estamos utilizando este subcomando.
• -x509 : Esto modifica aún más el subcomando anterior al indicarle a la utilidad que queremos crear un certificado autofirmado en lugar de generar una solicitud de firma de certificado, como sucedería normalmente.
• -nodes : Esto le indica a OpenSSL que omita la opción de proteger nuestro certificado con una frase de contraseña. Necesitamos que Nginx pueda leer el archivo sin la intervención del usuario cuando se inicia el servidor. Una frase de contraseña evitaría que esto suceda porque tendríamos que ingresarla después de cada reinicio.
• -days 365 : esta opción establece el período de tiempo durante el cual se considerará válido el certificado. Aquí lo configuramos en un año.
• -newkey rsa:2048 : esto especifica que queremos generar un nuevo certificado y una nueva clave al mismo tiempo. No creamos la clave que se requiere para firmar el certificado en un paso anterior, por lo que debemos crearla junto con el certificado. La rsa:2048parte le indica que cree una clave RSA de 2048 bits de longitud.
• -keyout : esta línea le dice a OpenSSL dónde colocar el archivo de clave privada generado que estamos creando.
• -out : Esto le dice a OpenSSL dónde colocar el certificado que estamos creando.

Como hemos indicado anteriormente, estas opciones crearán tanto un archivo de clave como un certificado. Se nos harán algunas preguntas sobre nuestro servidor para poder incorporar la información correctamente en el certificado.

Complete las indicaciones de forma adecuada. La línea más importante es la que solicita el Common Name (e.g. server FQDN or YOUR name). Debe ingresar el nombre de dominio asociado con su servidor o la dirección IP pública de su servidor.

La totalidad de las indicaciones se verá así:

OutputCountry Name (2 letter code) [AU]:USState or Province Name (full name) [Some-State]:New YorkLocality Name (eg, city) []:New York CityOrganization Name (eg, company) [Internet Widgits Pty Ltd]:Bouncy Castles, Inc.Organizational Unit Name (eg, section) []:Ministry of Water SlidesCommon Name (e.g. server FQDN or YOUR name) []:your_domain_or_server_IP_addressEmail Address []:admin@your_domain.com

Ambos archivos que ha creado se colocarán en los subdirectorios apropiados del /etc/ssldirectorio.

Mientras usamos OpenSSL, también deberíamos crear un grupo Diffie-Hellman fuerte, que se utiliza para negociar la confidencialidad perfecta hacia adelante con los clientes.

Podemos hacer esto escribiendo:

sudo openssl dhparam -out /etc/nginx/dhparam.pem 4096

Esto tomará un tiempo, pero cuando esté hecho tendrás un grupo DH fuerte /etc/nginx/dhparam.pemque podrás usar en tu configuración.

Paso 2: Configuración de Nginx para utilizar SSL

Hemos creado nuestros archivos de clave y certificado en el /etc/ssldirectorio. Ahora solo necesitamos modificar nuestra configuración de Nginx para aprovecharlos.

Realizaremos algunos ajustes en nuestra configuración.

1. Crearemos un fragmento de configuración que contiene nuestras ubicaciones de archivos de certificado y clave SSL.
2. Crearemos un fragmento de configuración que contiene configuraciones SSL seguras que se pueden usar con cualquier certificado en el futuro.
3. Ajustaremos nuestros bloques de servidor Nginx para manejar solicitudes SSL y usaremos los dos fragmentos anteriores.

Este método de configuración de Nginx nos permitirá mantener bloques de servidor limpios y poner segmentos de configuración comunes en módulos reutilizables.

Creación de un fragmento de configuración que apunte a la clave SSL y al certificado

Primero, creemos un nuevo fragmento de configuración de Nginx en el /etc/nginx/snippetsdirectorio.

Para distinguir adecuadamente el propósito de este archivo, lo llamaremos self-signed.conf:

sudo nano /etc/nginx/snippets/self-signed.conf

En este archivo, debemos establecer la ssl_certificatedirectiva para nuestro archivo de certificado y la ssl_certificate_keyclave asociada. Agregue las siguientes líneas al archivo:

/etc/nginx/snippets/self-signed.conf

ssl_certificate /etc/ssl/certs/nginx-selfsigned.crt;ssl_certificate_key /etc/ssl/private/nginx-selfsigned.key;

Cuando hayas agregado esas líneas, guarda y cierra el archivo.

Creación de un fragmento de configuración con configuraciones de cifrado seguro

A continuación, crearemos otro fragmento que definirá algunas configuraciones de SSL. Esto configurará Nginx con un conjunto de cifrado SSL sólido y habilitará algunas funciones avanzadas que ayudarán a mantener seguro nuestro servidor.

Los parámetros que configuraremos se pueden reutilizar en futuras configuraciones de Nginx, por lo que le daremos al archivo un nombre genérico:

sudo nano /etc/nginx/snippets/ssl-params.conf

Para configurar Nginx SSL de forma segura, utilizaremos las recomendaciones de Remy van Elst en el sitio Cipherli.st . Este sitio está diseñado para proporcionar configuraciones de cifrado fáciles de usar para software popular.

Nota: Las configuraciones sugeridas en el sitio Cipherli.st ofrecen una seguridad sólida. A veces, esto se produce a costa de una mayor compatibilidad con el cliente. Si necesita brindar soporte a clientes más antiguos, existe una lista alternativa a la que puede acceder haciendo clic en el enlace de la página con la etiqueta Sí, deme un conjunto de cifrado que funcione con software heredado/antiguo. Esa lista se puede sustituir por los elementos que se indican a continuación.

La elección de la configuración que utilice dependerá en gran medida de lo que necesite admitir. Ambas proporcionarán una gran seguridad.

Para nuestros propósitos, podemos copiar la configuración proporcionada en su totalidad. Solo necesitamos realizar algunas pequeñas modificaciones.

En primer lugar, agregaremos nuestro solucionador de DNS preferido para las solicitudes ascendentes. Usaremos el de Google para esta guía.

En segundo lugar, comentaremos la línea que establece el encabezado de seguridad de transporte estricto. Antes de descomentar esta línea, debería tomarse un momento para leer sobre la seguridad de transporte estricto HTTP o HSTS, y específicamente su funcionalidad de "precarga". La precarga de HSTS proporciona mayor seguridad, pero puede tener consecuencias de gran alcance si se habilita accidentalmente o de manera incorrecta.

Copie lo siguiente en su ssl-params.confarchivo de fragmento:

/etc/nginx/snippets/ssl-params.conf

ssl_protocols TLSv1.2;ssl_prefer_server_ciphers on;ssl_dhparam /etc/nginx/dhparam.pem;ssl_ciphers ECDHE-RSA-AES256-GCM-SHA512:DHE-RSA-AES256-GCM-SHA512:ECDHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-SHA384;ssl_ecdh_curve secp384r1; # Requires nginx = 1.1.0ssl_session_timeout  10m;ssl_session_cache shared:SSL:10m;ssl_session_tickets off; # Requires nginx = 1.5.9ssl_stapling on; # Requires nginx = 1.3.7ssl_stapling_verify on; # Requires nginx = 1.3.7resolver 8.8.8.8 8.8.4.4 valid=300s;resolver_timeout 5s;# Disable strict transport security for now. You can uncomment the following# line if you understand the implications.# add_header Strict-Transport-Security "max-age=63072000; includeSubDomains; preload";add_header X-Frame-Options DENY;add_header X-Content-Type-Options nosniff;add_header X-XSS-Protection "1; mode=block";

Debido a que estamos usando un certificado autofirmado, no se utilizará el encuadernado SSL. Nginx mostrará una advertencia, pero seguirá funcionando correctamente.

Guarde y cierre el archivo cuando haya terminado.

Cómo ajustar la configuración de Nginx para utilizar SSL

Ahora que tenemos nuestros fragmentos, podemos ajustar nuestra configuración de Nginx para habilitar SSL.

En esta guía, asumiremos que está utilizando un archivo de configuración de bloque de servidor personalizado en el /etc/nginx/sites-availabledirectorio, como se describe en el Paso 5 del tutorial de requisitos previos para la instalación de Nginx. Lo utilizaremos para este ejemplo. Sustituya el nombre del archivo de configuración o el nombre de dominio según sea necesario./etc/nginx/sites-available/your_domain

Antes de continuar, hagamos una copia de seguridad de nuestro archivo de configuración actual:

sudo cp /etc/nginx/sites-available/your_domain /etc/nginx/sites-available/your_domain.bak

Ahora, abra el archivo de configuración para realizar ajustes:

sudo nano /etc/nginx/sites-available/your_domain

Si siguió los requisitos previos, su bloque de servidor se verá así:

/etc/nginx/sites-available/su_dominio

server {    listen 80;    listen [::]:80;    root /var/www/your_domain/html;    index index.html index.htm index.nginx-debian.html;    server_name your_domain www.your_domain;    location / {            try_files $uri $uri/ =404;    }}

Es posible que su archivo esté en un orden diferente y, en lugar de las directivas rooty index, puede tener algunas location, proxy_passu otras declaraciones de configuración personalizadas. Esto está bien, ya que solo necesitamos actualizar las listendirectivas e incluir nuestros fragmentos de SSL. Modificaremos este bloque de servidor existente para que brinde tráfico SSL en el puerto 443y luego crearemos un nuevo bloque de servidor para responder en el puerto 80y redirigir automáticamente el tráfico al puerto 443.

Nota: Utilizaremos una redirección 302 hasta que hayamos verificado que todo funciona correctamente. Después, podemos cambiar esto a una redirección 301 permanente.

En el archivo de configuración existente, actualice las dos listendeclaraciones para usar el puerto 443y SSL, y luego incluya los dos archivos de fragmentos que creamos en los pasos anteriores:

/etc/nginx/sites-available/su_dominio

server {    listen 443 ssl;    listen [::]:443 ssl;    include snippets/self-signed.conf;    include snippets/ssl-params.conf;    root /var/www/your_domain/html;    index index.html index.htm index.nginx-debian.html;        server_name your_domain www.your_domain;    . . .}

A continuación, pegue un segundo bloque de servidor en el archivo de configuración, después del corchete de cierre ( }) del primer bloque:

/etc/nginx/sites-available/su_dominio

. . .server {    listen 80;    listen [::]:80;    server_name your_domain www.your_domain;    return 302 https://$server_name$request_uri;}

Esta es una configuración básica que escucha en el puerto 80y realiza la redirección a HTTPS. Guarde y cierre el archivo cuando haya terminado de editarlo.

Paso 3: Ajuste del firewall

Si tiene el ufwfirewall habilitado, como lo recomiendan las guías de requisitos previos, deberá ajustar la configuración para permitir el tráfico SSL. Afortunadamente, Nginx registra algunos perfiles al ufwmomento de la instalación.

Podemos ver los perfiles disponibles escribiendo:

sudo ufw app list

Deberías ver una lista como ésta:

OutputAvailable applications:. . .  Nginx Full  Nginx HTTP  Nginx HTTPS. . .

Puede ver la configuración actual escribiendo:

sudo ufw status

Si siguió los requisitos previos, se verá así, lo que significa que solo se permite el tráfico HTTP al servidor web:

OutputStatus: activeTo                         Action      From--                         ------      ----OpenSSH                    ALLOW       AnywhereNginx HTTP                 ALLOW       AnywhereOpenSSH (v6)               ALLOW       Anywhere (v6)Nginx HTTP (v6)            ALLOW       Anywhere (v6)

Para permitir adicionalmente el tráfico HTTPS, podemos habilitar el perfil “Nginx Full” y luego eliminar la asignación redundante del perfil “Nginx HTTP”:

sudo ufw allow 'Nginx Full'
sudo ufw delete allow 'Nginx HTTP'

Tu estado ahora debería verse así:

sudo ufw status

OutputStatus: activeTo                         Action      From--                         ------      ----OpenSSH                    ALLOW       AnywhereNginx Full                 ALLOW       AnywhereOpenSSH (v6)               ALLOW       Anywhere (v6)Nginx Full (v6)            ALLOW       Anywhere (v6)

Con nuestro firewall configurado correctamente, podemos pasar a probar nuestra configuración de Nginx.

Paso 4: Habilitar los cambios en Nginx

Ahora que hemos realizado nuestros cambios y ajustado nuestro firewall, podemos reiniciar Nginx para implementar nuestros nuevos cambios.

En primer lugar, debemos comprobar que no haya errores de sintaxis en nuestros archivos. Para ello, podemos escribir lo siguiente:

sudo nginx -t

Si todo sale bien, obtendrás un resultado parecido a esto:

Outputnginx: [warn] "ssl_stapling" ignored, issuer certificate not found for certificate "/etc/ssl/certs/nginx-selfsigned.crt"nginx: the configuration file /etc/nginx/nginx.conf syntax is oknginx: configuration file /etc/nginx/nginx.conf test is successful

Tenga en cuenta la advertencia que aparece al principio. Como se explicó anteriormente, esta configuración en particular genera una advertencia porque nuestro certificado autofirmado no puede utilizar el encuadernado SSL. Esto es lo esperado y nuestro servidor aún puede cifrar las conexiones correctamente.

Si el resultado coincide con lo anterior, el archivo de configuración no tiene errores de sintaxis. Podemos reiniciar Nginx de manera segura para implementar nuestros cambios:

sudo systemctl restart nginx

Con nuestra configuración de Nginx probada, podemos pasar a probar nuestra configuración.

Paso 5: Prueba de cifrado

Ahora estamos listos para probar nuestro servidor SSL.

Abra su navegador web y escriba https://seguido del nombre de dominio o IP de su servidor en la barra de direcciones:

https://your_domain_or_server_IP

Debido a que el certificado que creamos no está firmado por una de las autoridades de certificación confiables de su navegador, es probable que vea una advertencia de aspecto aterrador como la que se muestra a continuación (la siguiente aparece cuando se usa Google Chrome):

Esto es normal y esperado. Solo nos interesa el aspecto de cifrado de nuestro certificado, no la validación por parte de terceros de la autenticidad de nuestro servidor. Haga clic en “AVANZADO” y luego en el enlace proporcionado para continuar con su servidor:

Deberías ser redirigido a tu sitio. Si miras la barra de direcciones del navegador, verás un candado con una “x” encima. En este caso, esto solo significa que el certificado no se puede validar. Todavía está cifrando tu conexión.

Si ha configurado Nginx con dos bloques de servidor, redirigiendo automáticamente el contenido HTTP a HTTPS, también puede comprobar si la redirección funciona correctamente:

http://server_domain_or_IP

Si el resultado es el mismo icono, significa que la redirección funcionó correctamente.

Paso 6: Cambiar a una redirección permanente

Si su redirección funcionó correctamente y está seguro de que desea permitir solo tráfico cifrado, debe modificar la configuración de Nginx para que la redirección sea permanente.

Abra nuevamente el archivo de configuración del bloque del servidor:

sudo nano /etc/nginx/sites-available/^your_domain^

Encuentra el return 302y cámbialo a return 301:

/etc/nginx/sites-available/su_dominio

return 301 https://$server_name$request_uri;

Guarde y cierre el archivo.

Comprueba tu configuración en busca de errores de sintaxis:

sudo nginx -t

Cuando esté listo, reinicie Nginx para que la redirección sea permanente:

sudo systemctl restart nginx

Conclusión

Ha configurado su servidor Nginx para utilizar un cifrado fuerte para las conexiones de los clientes. Esto le permitirá atender solicitudes de forma segura y evitará que terceros lean su tráfico.