Cómo generar un CSR en NGINX

Este tutorial muestra cómo generar un CSR en NGINX. NGINX no genera las Solicitudes de Firma de Certificado (Certificate Signing Requests) por sí mismo: usted crea la clave privada y el CSR con OpenSSL en el mismo servidor que alojará el certificado, y luego envía el CSR a su Autoridad de Certificación. Cuando el certificado emitido llega, usted lo indica a NGINX mediante las directivas ssl_certificate y ssl_certificate_key.

Los pasos siguientes funcionan en todas las distribuciones de Linux compatibles que incluyen NGINX (Debian, Ubuntu, RHEL, AlmaLinux, Rocky Linux, Amazon Linux), ya que cada una incluye OpenSSL 1.1.1 o 3.x. El OpenSSL moderno firma las solicitudes con SHA-256 de forma predeterminada, por lo que no es necesario añadir un indicador de resumen (digest).

Paso 1: Conéctese a su servidor NGINX

Conéctese al servidor que ejecuta NGINX a través de SSH desde su máquina local (Terminal en macOS o Linux, PowerShell o Windows Terminal en Windows). Reemplace el nombre de usuario y el host por los suyos:

ssh your-user@your-nginx-server

Genere el CSR en el servidor que servirá el certificado. La clave privada se crea junto al CSR y debe permanecer en ese servidor. Ejecutar estos comandos localmente y luego copiar la clave a otro lugar anula el propósito de tener una clave privada en primer lugar.

Paso 2: Genere la clave privada y el CSR

Ejecute el siguiente comando. Este crea una clave privada RSA de 2048 bits y un CSR correspondiente en un solo paso, con el sujeto y los Nombres Alternativos del Sujeto (SANs) proporcionados en línea para que OpenSSL no se detenga a hacer preguntas:

openssl req -new -newkey rsa:2048 -nodes 
-keyout yourdomain.key 
-out yourdomain.csr 
-subj "/C=US/ST=YourState/L=YourCity/O=YourCompany/CN=yourdomain.com" 
-addext "subjectAltName=DNS:yourdomain.com,DNS:www.yourdomain.com"

Qué hace cada parte:

• -newkey rsa:2048 genera una nueva clave RSA de 2048 bits. 2048 bits es el mínimo actual que aceptan las CA públicas; puede usar rsa:4096 para una clave más grande, o cambiar a ECDSA (ver más abajo).
• -nodes deja la clave privada sin cifrar para que NGINX pueda leerla al iniciar sin pedir una frase de contraseña. Si prefiere cifrar la clave, elimine -nodes y use la directiva ssl_password_file de NGINX para proporcionar la frase de contraseña al iniciar y recargar.
• -keyout y -out nombran los archivos de la clave privada y del CSR.
• -subj proporciona el sujeto del certificado. Ponga aquí el nombre real de su empresa, el estado y la ciudad, no los marcadores de posición. CN (Common Name, Nombre Común) es su dominio principal.
• -addext «subjectAltName=…» enumera todos los nombres de host que debe cubrir el certificado. Las CA públicas validan contra la lista de SAN, así que incluya también el Nombre Común aquí. El indicador -addext requiere OpenSSL 1.1.1 o más reciente; toda distribución de Linux compatible incluye al menos esa versión.

Reemplace yourdomain.com por su dominio real en todo el proceso. Para cubrir nombres de host adicionales, añádalos a la lista de SAN separados por comas, por ejemplo DNS:api.yourdomain.com. Para un comodín (wildcard), incluya tanto el comodín como el dominio simple: DNS:*.yourdomain.com,DNS:yourdomain.com.

Si prefiere una clave ECDSA (más pequeña y rápida, con P-256 ampliamente compatible), genere la clave y el CSR de esta forma en su lugar:

openssl req -new -newkey ec -pkeyopt ec_paramgen_curve:prime256v1 -pkeyopt ec_param_enc:named_curve -nodes 
-keyout yourdomain.key 
-out yourdomain.csr 
-subj "/C=US/ST=YourState/L=YourCity/O=YourCompany/CN=yourdomain.com" 
-addext "subjectAltName=DNS:yourdomain.com,DNS:www.yourdomain.com"

Si su OpenSSL no admite -addext

En sistemas muy antiguos con una versión de OpenSSL anterior a la 1.1.1, el indicador -addext no está disponible. Cree un pequeño archivo de configuración llamado san.cnf con este contenido:

[ req ]
default_bits       = 2048
prompt             = no
default_md         = sha256
distinguished_name = dn
req_extensions     = req_ext

[ dn ]
C  = US
ST = YourState
L  = YourCity
O  = YourCompany
CN = yourdomain.com

[ req_ext ]
subjectAltName = @alt_names

[ alt_names ]
DNS.1 = yourdomain.com
DNS.2 = www.yourdomain.com

Luego ejecute:

openssl req -new -newkey rsa:2048 -nodes 
-keyout yourdomain.key -out yourdomain.csr -config san.cnf

Paso 3: Localice sus archivos

Liste el directorio actual para confirmar que ambos archivos se crearon:

ls

Debería ver dos archivos nuevos:

• yourdomain.key: su clave privada. Manténgala en el servidor, haga una copia de seguridad segura y nunca la envíe a nadie, incluida la Autoridad de Certificación. Quien tenga la clave puede suplantar su sitio.
• yourdomain.csr: su Solicitud de Firma de Certificado. Este es el archivo que envía al proveedor de SSL.

Establezca permisos estrictos en la clave privada de inmediato para que solo root pueda leerla:

sudo chmod 600 yourdomain.key
sudo chown root:root yourdomain.key

Paso 4: Verifique el CSR (opcional pero recomendado)

Antes de enviarlo, compruebe que el CSR contiene el sujeto y los SAN correctos y que su firma es válida. Esto decodifica la solicitud localmente con OpenSSL:

openssl req -noout -text -verify -in yourdomain.csr

Confirme que la línea Subject muestra sus datos, que X509v3 Subject Alternative Name enumera todos los nombres de host que espera, y que la comprobación de firma imprime verify OK. El algoritmo de firma debería mostrar sha256WithRSAEncryption (o ecdsa-with-SHA256 para una clave ECDSA). Si prefiere no usar la línea de comandos, pegue el CSR en nuestro decodificador de CSR en línea para leer los mismos campos en un navegador.

Paso 5: Envíe su CSR

Para copiar el CSR para su pedido, muestre su contenido:

cat yourdomain.csr

Verá un bloque de texto como este:

-----BEGIN CERTIFICATE REQUEST-----
MIIBozCB... (a long string of characters)
-----END CERTIFICATE REQUEST-----

Copie el bloque completo, incluidas las líneas —–BEGIN CERTIFICATE REQUEST—– y —–END CERTIFICATE REQUEST—– (cada marcador tiene cinco guiones a cada lado). Ese bloque completo es su CSR. Péguelo en el formulario de pedido durante su compra, y mantenga la clave privada correspondiente en su lugar en el servidor.

Si prefiere no usar la línea de comandos, también puede generar la solicitud con nuestro Generador de CSR en línea. Tenga en cuenta que este genera la clave privada en su navegador, así que guarde esa clave usted mismo y muévala al servidor.

Qué sucede después de que la CA emite el certificado

Una vez que la CA valida el CSR y emite el certificado, normalmente recibirá su certificado de servidor (un archivo .crt nombrado según su dominio) más uno o más certificados intermedios, a veces incluidos en un archivo .ca-bundle. NGINX espera que el certificado de servidor y la cadena intermedia se combinen en un solo archivo (la «cadena completa» o fullchain) al que apunte ssl_certificate; la clave privada que generó anteriormente se indica por separado mediante ssl_certificate_key. El procedimiento completo (construir la fullchain, editar el bloque del servidor, probar y recargar) se explica en nuestro tutorial de instalación de SSL en NGINX.