Cómo instalar un certificado SSL en NGINX

Esta guía te muestra cómo instalar un certificado SSL/TLS en NGINX. Cubre la parte que más confunde a la mayoría: crear la cadena de certificados correcta («fullchain») que requiere NGINX, apuntar las directivas correctas a los archivos correctos, probar la configuración antes de recargar, y añadir una redirección limpia de HTTP a HTTPS para que cada visitante llegue a la versión segura de tu sitio.

Generar un código CSR para NGINX

Si ya generaste tu CSR y tienes en mano los archivos del certificado emitido, salta directamente a Instalar un certificado SSL en NGINX.

Antes de que una Autoridad de Certificación pueda emitir tu certificado, debes enviar un CSR (Certificate Signing Request o Solicitud de Firma de Certificado): un pequeño bloque de texto que contiene los datos de tu dominio y una clave pública, junto con una clave privada que se guarda en el servidor. Tienes dos opciones:

• Generar el CSR automáticamente con nuestro Generador de CSR. La herramienta devuelve tanto el CSR como la clave privada correspondiente, que luego debes subir al servidor.
• Generar el CSR directamente en el servidor con OpenSSL siguiendo nuestro tutorial sobre cómo generar un CSR en NGINX. La clave privada permanece en el servidor.

Abre el archivo .csr resultante en cualquier editor de texto; el bloque de texto que contiene (incluidas las líneas —–BEGIN CERTIFICATE REQUEST—– y —–END CERTIFICATE REQUEST—–) es lo que debes pegar en el formulario de solicitud SSL durante el proceso de compra. Si quieres confirmar el contenido del CSR antes de enviarlo, pégalo en nuestro decodificador de CSR.

Instalar un certificado SSL en NGINX

Una vez que la CA haya emitido el certificado, normalmente recibirás:

• Tu certificado principal (del servidor), generalmente un archivo .crt con el nombre de tu dominio.
• Los certificados intermedios (y a veces el certificado raíz), como archivos .crt separados o agrupados en un único archivo .ca-bundle.
• La clave privada (un archivo .key) que se generó junto con tu CSR.

NGINX necesita que el certificado del servidor y la cadena de intermedios se combinen en un único archivo (el «fullchain») al que apunta ssl_certificate; la clave privada se indica por separado con ssl_certificate_key. Omitir la cadena es el error de instalación más común: el certificado se ve bien en un navegador de escritorio, pero falla en Android, en clientes de API y en herramientas como nuestro SSL Checker.

Paso 1: Combina los certificados en un solo archivo

El orden de los certificados en el archivo combinado es importante. Primero va tu certificado de servidor, luego cada intermedio desde la CA emisora hacia arriba, y el certificado raíz al final (u omitido, ya que los navegadores ya confían en las raíces de su almacén integrado):

• Tu certificado principal para el nombre de dominio.
• Certificado(s) intermedio(s).
• Certificado raíz (opcional).

Puedes construir el archivo fullchain manualmente en un editor de texto (pegando cada bloque PEM en orden), o con un único comando cat. Si recibiste archivos separados de intermedios y raíz, ejecuta:

cat your_domain.crt intermediate.crt root.crt > ssl-bundle.crt

Si los intermedios y la raíz ya están en un único archivo .ca-bundle, ejecuta:

cat example_com.crt example_com.ca-bundle > ssl-bundle.crt

Reemplaza los nombres de archivo con los tuyos. Mueve el archivo combinado (y la clave privada, si aún no está allí) al directorio SSL de tu servidor, por ejemplo /etc/ssl/ o /etc/nginx/ssl/. Mantén el archivo de clave legible solo por root:

sudo chmod 600 /etc/ssl/your_domain.key
sudo chown root:root /etc/ssl/your_domain.key

Paso 2: Edita el archivo de configuración de NGINX

Abre el archivo de configuración de NGINX para tu sitio. En Debian y Ubuntu se encuentra en /etc/nginx/sites-available/ (con un enlace simbólico en sites-enabled/); en RHEL, CentOS, AlmaLinux y Rocky Linux se encuentra en /etc/nginx/conf.d/. Añade o edita el bloque server que escucha en el puerto 443 para que apunte al archivo fullchain y a la clave privada:

server {
    listen 443 ssl;
    http2 on;
    server_name example.com www.example.com;

    ssl_certificate     /etc/ssl/ssl-bundle.crt;
    ssl_certificate_key /etc/ssl/your_domain.key;

    # Modern TLS only
    ssl_protocols TLSv1.2 TLSv1.3;
    ssl_prefer_server_ciphers off;
    ssl_ciphers ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305;

    ssl_session_timeout 1d;
    ssl_session_cache shared:NginxSSL:10m;
    ssl_session_tickets off;

    access_log /var/log/nginx/example.com.access.log;
    error_log  /var/log/nginx/example.com.error.log;

    root /var/www/example.com;
    index index.html;

    location / {
        try_files $uri $uri/ =404;
    }
}

Algunas notas sobre las directivas anteriores:

• listen 443 ssl; habilita TLS en el puerto 443. La directiva antigua ssl on; se eliminó en NGINX 1.25 y no debería aparecer en configuraciones modernas.
• http2 on; activa HTTP/2 como directiva independiente (NGINX 1.25.1 y posteriores). Las configuraciones antiguas usaban listen 443 ssl http2;, que aún funciona pero está en desuso.
• ssl_protocols TLSv1.2 TLSv1.3; desactiva los protocolos obsoletos TLS 1.0 y 1.1. A partir de NGINX 1.27.3, esto también es el valor predeterminado si omites la directiva, pero establecerlo explícitamente es la opción más clara y fácil de auditar.
• La lista de cifrados coincide con el perfil «intermedio» de Mozilla y funciona en todos los clientes recientes. Si solo necesitas clientes con TLS 1.3, puedes eliminar ssl_ciphers por completo.

Paso 3: Redirige HTTP a HTTPS

Añade un bloque server independiente en el puerto 80 que redirija permanentemente cada solicitud a HTTPS, de manera que los visitantes que lleguen por HTTP simple terminen en la URL segura:

server {
    listen 80;
    server_name example.com www.example.com;
    return 301 https://$host$request_uri;
}

Usar return 301 es más rápido y seguro que una regla rewrite basada en expresiones regulares, y es el patrón que la propia NGINX recomienda.

Paso 4: Prueba la configuración y recarga NGINX

Valida siempre la configuración antes de recargar, para que un error de escritura no deje el servicio fuera de línea:

sudo nginx -t

Deberías ver syntax is ok y test is successful. Si se informa un error, el mensaje incluye el archivo y el número de línea; corrígelo y vuelve a ejecutar la prueba. Cuando la prueba pase, recarga NGINX para que aplique la nueva configuración sin cortar las conexiones existentes:

sudo systemctl reload nginx

En sistemas sin systemd, usa la señal de recarga propia de NGINX:

sudo nginx -s reload

Prefiere reload en lugar de restart: una recarga vuelve a leer la configuración sin cerrar las conexiones activas, mientras que un reinicio las corta.

Paso 5 (opcional): Habilita OCSP stapling

OCSP stapling permite que NGINX entregue un estado de revocación firmado y actualizado junto con el certificado, de modo que los clientes no tengan que contactar a la CA en cada negociación (handshake). Añade lo siguiente dentro de tu bloque server de HTTPS:

ssl_stapling on;
ssl_stapling_verify on;
ssl_trusted_certificate /etc/ssl/ssl-bundle.crt;
resolver 1.1.1.1 8.8.8.8 valid=300s;
resolver_timeout 5s;

Recarga NGINX de nuevo con sudo systemctl reload nginx. El stapling es un paso de refuerzo pequeño pero valioso, y la mayoría de los certificados modernos lo admiten de forma nativa.

Verifica la instalación

Abre tu sitio con https:// en un navegador y comprueba que el candado esté cerrado y que el certificado coincida con tu dominio. Luego ejecuta un análisis más profundo con nuestro SSL Checker para obtener un informe instantáneo sobre el certificado, la cadena, y los protocolos y cifrados que ofrece tu servidor. Un resultado en verde significa que los clientes en todas las plataformas principales confiarán en el certificado, incluidos los clientes móviles y de API.

Preguntas frecuentes