Come installare un certificato SSL su NGINX

Questa guida ti mostra come installare un certificato SSL/TLS su NGINX. Copre la parte che mette in difficoltà la maggior parte delle persone: costruire la catena di certificati corretta (“fullchain”) richiesta da NGINX, puntare le direttive giuste ai file giusti, testare la configurazione prima di ricaricarla e aggiungere un reindirizzamento pulito da HTTP a HTTPS in modo che ogni visitatore arrivi sulla versione sicura del tuo sito.

Genera un codice CSR per NGINX

Se hai già generato il tuo CSR e hai in mano i file del certificato emesso, passa direttamente a Installa un certificato SSL su NGINX.

Prima che un’Autorità di Certificazione possa emettere il tuo certificato, devi inviare un CSR (Certificate Signing Request): un piccolo blocco di testo che contiene i dettagli del tuo dominio e una chiave pubblica, abbinato a una chiave privata conservata sul server. Hai due opzioni:

• Genera il CSR automaticamente con il nostro CSR Generator. Lo strumento restituisce sia il CSR che la chiave privata corrispondente, che poi carichi sul server.
• Genera il CSR direttamente sul server con OpenSSL seguendo il nostro tutorial su come generare un CSR su NGINX. La chiave privata rimane sul server.

Apri il file .csr risultante in un qualsiasi editor di testo; il blocco di testo al suo interno (incluse le righe —–BEGIN CERTIFICATE REQUEST—– e —–END CERTIFICATE REQUEST—–) è ciò che dovrai incollare nel modulo di richiesta SSL durante il checkout. Se vuoi verificare il contenuto del CSR prima di inviarlo, incollalo nel nostro decodificatore CSR.

Installa un certificato SSL su NGINX

Una volta che la CA ha emesso il certificato, in genere riceverai:

• Il tuo certificato primario (server), di solito un file .crt con il nome del tuo dominio.
• I certificati intermedi (e talvolta root), come file .crt separati oppure raggruppati in un unico file .ca-bundle.
• La chiave privata (un file .key) generata insieme al tuo CSR.

NGINX richiede che il certificato server e la catena intermedia siano combinati in un unico file (il “fullchain”) e indicato tramite ssl_certificate; la chiave privata viene indicata separatamente tramite ssl_certificate_key. Saltare la catena è l’errore di installazione più comune in assoluto: il certificato sembra funzionare correttamente su un browser desktop ma fallisce su Android, nei client API e in strumenti come il nostro SSL Checker.

Passo 1: Combina i certificati in un unico file

L’ordine dei certificati nel file combinato è importante. Il certificato del tuo server viene per primo, poi ogni intermedio dalla CA che ha emesso il certificato foglia verso l’alto, con la root per ultima (oppure omessa, dato che i browser si fidano già delle root presenti nel loro archivio integrato):

• Il tuo certificato primario per il nome di dominio.
• Certificato/i intermedio/i.
• Certificato root (opzionale).

Puoi creare il file fullchain manualmente in un editor di testo (incollando ogni blocco PEM in ordine), oppure con un unico comando cat. Se hai ricevuto file intermedi e root separati, esegui:

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

Se gli intermedi e la root sono già in un unico file .ca-bundle, esegui:

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

Sostituisci i nomi dei file con i tuoi. Sposta il file combinato (e la chiave privata, se non è già lì) nella directory SSL del tuo server, ad esempio /etc/ssl/ o /etc/nginx/ssl/. Mantieni il file della chiave leggibile solo da root:

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

Passo 2: Modifica il file di configurazione di NGINX

Apri il file di configurazione di NGINX per il tuo sito. Su Debian e Ubuntu si trova in /etc/nginx/sites-available/ (con un symlink in sites-enabled/); su RHEL, CentOS, AlmaLinux e Rocky Linux si trova in /etc/nginx/conf.d/. Aggiungi o modifica il blocco server che ascolta sulla porta 443 in modo che punti al file fullchain e alla chiave privata:

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;
    }
}

Alcune note sulle direttive sopra riportate:

• listen 443 ssl; abilita TLS sulla porta 443. La direttiva legacy ssl on; è stata rimossa in NGINX 1.25 e non dovrebbe comparire nelle configurazioni moderne.
• http2 on; attiva HTTP/2 come direttiva autonoma (NGINX 1.25.1 e versioni successive). Le configurazioni più datate usavano listen 443 ssl http2;, che funziona ancora ma è deprecata.
• ssl_protocols TLSv1.2 TLSv1.3; disabilita gli ormai obsoleti TLS 1.0 e 1.1. A partire da NGINX 1.27.3, questa è anche l’impostazione predefinita se ometti la direttiva, ma impostarla esplicitamente resta la scelta più chiara e facile da verificare in fase di audit.
• L’elenco dei cifrari corrisponde al profilo “intermediate” di Mozilla e funziona con qualsiasi client recente. Se ti servono solo client TLS 1.3, puoi eliminare del tutto ssl_ciphers.

Passo 3: Reindirizza HTTP a HTTPS

Aggiungi un blocco server separato sulla porta 80 che reindirizzi permanentemente ogni richiesta a HTTPS, in modo che i visitatori che arrivano tramite HTTP semplice atterrino sull’URL sicuro:

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

Usare return 301 è più veloce e sicuro rispetto a una regola rewrite basata su espressioni regolari, ed è l’approccio raccomandato dalla stessa NGINX.

Passo 4: Testa la configurazione e ricarica NGINX

Convalida sempre la configurazione prima di ricaricarla, così un errore di battitura non potrà mettere offline il servizio:

sudo nginx -t

Dovresti vedere syntax is ok e test is successful. Se viene segnalato un errore, il messaggio include il file e il numero di riga; correggilo e riesegui il test. Quando il test viene superato, ricarica NGINX in modo che applichi la nuova configurazione senza interrompere le connessioni esistenti:

sudo systemctl reload nginx

Sui sistemi privi di systemd, usa invece il segnale di ricarica proprio di NGINX:

sudo nginx -s reload

Preferisci reload a restart: un reload rilegge la configurazione senza chiudere le connessioni attive, mentre un restart le interrompe.

Passo 5 (opzionale): Abilita l’OCSP stapling

L’OCSP stapling permette a NGINX di fornire uno stato di revoca aggiornato e firmato insieme al certificato, così i client non devono contattare la CA a ogni handshake. Aggiungi quanto segue all’interno del tuo blocco server 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;

Ricarica di nuovo NGINX con sudo systemctl reload nginx. Lo stapling è un piccolo ma prezioso passo di rafforzamento della sicurezza, e la maggior parte dei certificati moderni lo supporta già di serie.

Verifica l’installazione

Apri il tuo sito tramite https:// in un browser e verifica che il lucchetto sia chiuso e che il certificato corrisponda al tuo dominio. Poi esegui una scansione più approfondita con il nostro SSL Checker per un rapporto immediato sul certificato, sulla catena e sui protocolli e cifrari offerti dal tuo server. Un risultato verde in questo caso significa che i client su tutte le principali piattaforme si fideranno del certificato, inclusi i client mobili e API.

Domande frequenti