How to Generate a CSR on NGINX

This tutorial shows you how to generate a CSR on NGINX. NGINX does not generate Certificate Signing Requests itself: you create the private key and the CSR with OpenSSL on the same server that will host the certificate, then submit the CSR to your Certificate Authority. When the issued certificate comes back, you point NGINX at it with the ssl_certificate and ssl_certificate_key directives.

The steps below work on every supported Linux distribution that ships NGINX (Debian, Ubuntu, RHEL, AlmaLinux, Rocky Linux, Amazon Linux), since each one ships OpenSSL 1.1.1 or 3.x. Modern OpenSSL signs requests with SHA-256 by default, so you do not need to add a digest flag.

Step 1: Connect to your NGINX server

Connect to the server that runs NGINX over SSH from your local machine (Terminal on macOS or Linux, PowerShell or Windows Terminal on Windows). Replace the user name and host with your own:

ssh your-user@your-nginx-server

Generate the CSR on the server that will serve the certificate. The private key is created next to the CSR and must stay on that server. Running these commands locally and then copying the key around defeats the point of having a private key in the first place.

Step 2: Generate the private key and CSR

Run the following command. It creates a 2048-bit RSA private key and a matching CSR in one step, with the subject and Subject Alternative Names (SANs) supplied inline so OpenSSL does not stop to ask questions:

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"

What each part does:

• -newkey rsa:2048 generates a new 2048-bit RSA key. 2048-bit is the current minimum public CAs accept; you can use rsa:4096 for a larger key, or switch to ECDSA (see below).
• -nodes leaves the private key unencrypted so NGINX can read it at startup without a passphrase prompt. If you would rather encrypt the key, remove -nodes and use NGINX’s ssl_password_file directive to supply the passphrase on start and reload.
• -keyout and -out name the private key and the CSR files.
• -subj supplies the certificate subject. Put your real company name, state, and city here, not the placeholders. CN (Common Name) is your primary domain.
• -addext “subjectAltName=…” lists every hostname the certificate must cover. Public CAs validate against the SAN list, so include the Common Name here too. The -addext flag requires OpenSSL 1.1.1 or newer; every supported Linux release ships with at least that version.

Replace yourdomain.com with your actual domain throughout. To cover extra hostnames, add them to the SAN list separated by commas, for example DNS:api.yourdomain.com. For a wildcard, include both the wildcard and the bare domain: DNS:*.yourdomain.com,DNS:yourdomain.com.

If you prefer an ECDSA key (smaller and faster, with P-256 widely supported), generate the key and CSR like this instead:

openssl req -new -newkey ec -pkeyopt ec_paramgen_curve:prime256v1 -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"

If your OpenSSL does not support -addext

On very old systems with OpenSSL older than 1.1.1, the -addext flag is not available. Create a small config file called san.cnf with this content:

[ 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

Then run:

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

Step 3: Locate your files

List the current directory to confirm both files were created:

ls

You should see two new files:

• yourdomain.key: your private key. Keep it on the server, back it up securely, and never send it to anyone, including the Certificate Authority. Whoever holds the key can impersonate your site.
• yourdomain.csr: your Certificate Signing Request. This is the file you submit to the SSL provider.

Set strict permissions on the private key right away so only root can read it:

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

Step 4: Verify the CSR (optional but recommended)

Before you submit it, check that the CSR contains the right subject and SANs and that its signature is valid. This decodes the request locally with OpenSSL:

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

Confirm that the Subject line shows your details, that X509v3 Subject Alternative Name lists every hostname you expect, and that the signature check prints verify OK. The signature algorithm should read sha256WithRSAEncryption (or ecdsa-with-SHA256 for an ECDSA key). If you would rather not use the command line, paste the CSR into our online CSR decoder to read the same fields in a browser.

Step 5: Submit your CSR

To copy the CSR for your order, print its contents:

cat yourdomain.csr

You will see a block of text like this:

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

Copy the entire block, including the —–BEGIN CERTIFICATE REQUEST—– and —–END CERTIFICATE REQUEST—– lines (each marker has five hyphens on either side). That whole block is your CSR. Paste it into the order form during your purchase, and keep the matching private key in place on the server.

If you would rather not use the command line, you can also build the request with our online CSR Generator. Note that it generates the private key in your browser, so save that key yourself and move it to the server.

What happens after the CA issues the certificate

Once the CA validates the CSR and issues the certificate, you will typically receive your server certificate (a .crt file named after your domain) plus one or more intermediate certificates, sometimes bundled into a .ca-bundle file. NGINX expects the server certificate and the intermediate chain combined into a single file (the “fullchain”) and pointed to by ssl_certificate; the private key you generated above is pointed to separately by ssl_certificate_key. The full procedure (building the fullchain, editing the server block, testing, and reloading) is covered in our NGINX SSL installation tutorial.