Questo tutorial mostra come generare una CSR su NGINX. NGINX non genera Certificate Signing Request da solo: si crea la chiave privata e la CSR con OpenSSL sullo stesso server che ospiterà il certificato, poi si invia la CSR alla propria Certificate Authority. Quando il certificato emesso viene restituito, si punta NGINX verso di esso con le direttive ssl_certificate e ssl_certificate_key.
I passaggi seguenti funzionano su ogni distribuzione Linux supportata che include NGINX (Debian, Ubuntu, RHEL, AlmaLinux, Rocky Linux, Amazon Linux), poiché ognuna include OpenSSL 1.1.1 o 3.x. L’OpenSSL moderno firma le richieste con SHA-256 per impostazione predefinita, quindi non è necessario aggiungere un flag per il digest.
Passaggio 1: Connettersi al server NGINX
Connettiti al server che esegue NGINX tramite SSH dalla tua macchina locale (Terminale su macOS o Linux, PowerShell o Windows Terminal su Windows). Sostituisci il nome utente e l’host con i tuoi:
ssh your-user@your-nginx-server
Genera la CSR sul server che servirà il certificato. La chiave privata viene creata insieme alla CSR e deve rimanere su quel server. Eseguire questi comandi in locale e poi copiare la chiave in giro vanifica lo scopo stesso di avere una chiave privata.
Passaggio 2: Generare la chiave privata e la CSR
Esegui il comando seguente. Crea una chiave privata RSA a 2048 bit e una CSR corrispondente in un solo passaggio, con il soggetto e i Subject Alternative Names (SAN) forniti in linea in modo che OpenSSL non si fermi a fare domande:
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"
Cosa fa ciascuna parte:
- -newkey rsa:2048 genera una nuova chiave RSA a 2048 bit. 2048 bit è il minimo attualmente accettato dalle CA pubbliche; puoi usare rsa:4096 per una chiave più grande, oppure passare a ECDSA (vedi sotto).
- -nodes lascia la chiave privata non cifrata così che NGINX possa leggerla all’avvio senza richiedere una passphrase. Se preferisci cifrare la chiave, rimuovi -nodes e usa la direttiva ssl_password_file di NGINX per fornire la passphrase all’avvio e al reload.
- -keyout e -out assegnano il nome ai file della chiave privata e della CSR.
- -subj fornisce il soggetto del certificato. Inserisci qui il nome reale della tua azienda, lo stato e la città, non i segnaposto. CN (Common Name) è il tuo dominio principale.
- -addext “subjectAltName=…” elenca ogni hostname che il certificato deve coprire. Le CA pubbliche validano rispetto all’elenco SAN, quindi includi qui anche il Common Name. Il flag -addext richiede OpenSSL 1.1.1 o versioni più recenti; ogni distribuzione Linux supportata include almeno quella versione.
Sostituisci yourdomain.com con il tuo dominio effettivo ovunque. Per coprire hostname aggiuntivi, aggiungili all’elenco SAN separati da virgole, ad esempio DNS:api.yourdomain.com. Per un wildcard, includi sia il wildcard che il dominio semplice: DNS:*.yourdomain.com,DNS:yourdomain.com.
Se preferisci una chiave ECDSA (più piccola e veloce, con P-256 ampiamente supportata), genera invece la chiave e la CSR in questo modo:
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"
Se il tuo OpenSSL non supporta -addext
Su sistemi molto vecchi con OpenSSL precedente alla 1.1.1, il flag -addext non è disponibile. Crea un piccolo file di configurazione chiamato san.cnf con questo contenuto:
[ 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
Poi esegui:
openssl req -new -newkey rsa:2048 -nodes
-keyout yourdomain.key -out yourdomain.csr -config san.cnf
Passaggio 3: Individuare i tuoi file
Elenca la directory corrente per confermare che entrambi i file siano stati creati:
ls
Dovresti vedere due nuovi file:
- yourdomain.key: la tua chiave privata. Conservala sul server, eseguine un backup sicuro e non inviarla mai a nessuno, inclusa la Certificate Authority. Chiunque possieda la chiave può impersonare il tuo sito.
- yourdomain.csr: la tua Certificate Signing Request. Questo è il file che invii al provider SSL.
Imposta subito permessi restrittivi sulla chiave privata, così che solo root possa leggerla:
sudo chmod 600 yourdomain.key
sudo chown root:root yourdomain.key
Passaggio 4: Verificare la CSR (opzionale ma consigliato)
Prima di inviarla, controlla che la CSR contenga il soggetto e i SAN corretti e che la sua firma sia valida. Questo decodifica la richiesta in locale con OpenSSL:
openssl req -noout -text -verify -in yourdomain.csr
Conferma che la riga Subject mostri i tuoi dati, che X509v3 Subject Alternative Name elenchi ogni hostname previsto, e che il controllo della firma stampi verify OK. L’algoritmo di firma dovrebbe indicare sha256WithRSAEncryption (o ecdsa-with-SHA256 per una chiave ECDSA). Se preferisci non usare la riga di comando, incolla la CSR nel nostro decodificatore CSR online per leggere gli stessi campi in un browser.
Passaggio 5: Inviare la CSR
Per copiare la CSR per il tuo ordine, stampa il suo contenuto:
cat yourdomain.csr
Vedrai un blocco di testo simile a questo:
-----BEGIN CERTIFICATE REQUEST-----
MIIBozCB... (a long string of characters)
-----END CERTIFICATE REQUEST-----
Copia l’intero blocco, incluse le righe —–BEGIN CERTIFICATE REQUEST—– e —–END CERTIFICATE REQUEST—– (ogni marcatore ha cinque trattini su entrambi i lati). Quell’intero blocco è la tua CSR. Incollalo nel modulo d’ordine durante l’acquisto e mantieni la chiave privata corrispondente al suo posto sul server.
Se preferisci non usare la riga di comando, puoi anche creare la richiesta con il nostro Generatore di CSR online. Nota che genera la chiave privata nel tuo browser, quindi salva tu stesso quella chiave e spostala sul server.
Cosa succede dopo l’emissione del certificato da parte della CA
Una volta che la CA convalida la CSR ed emette il certificato, riceverai in genere il tuo certificato server (un file .crt denominato in base al tuo dominio) più uno o più certificati intermedi, a volte raggruppati in un file .ca-bundle. NGINX richiede che il certificato server e la catena intermedia siano combinati in un unico file (la “fullchain”) e indicati tramite ssl_certificate; la chiave privata generata sopra viene indicata separatamente tramite ssl_certificate_key. La procedura completa (creazione della fullchain, modifica del blocco server, test e reload) è trattata nel nostro tutorial di installazione SSL per NGINX.
Risparmia il 10% sui certificati SSL ordinando oggi stesso da SSL Dragon!
Emissione rapida, crittografia avanzata, affidabilità del browser al 99,99%, assistenza dedicata e garanzia di rimborso entro 25 giorni. Codice coupon: SAVE10


