Proteggere Nginx con HTTPS: Una Guida Passo-Passo
Impara come proteggere il tuo server web Nginx con HTTPS in questa guida completa passo-passo. Copriamo l'ottenimento di certificati SSL/TLS gratuiti da Let's Encrypt usando Certbot, la configurazione di Nginx per connessioni crittografate e l'implementazione di misure di sicurezza essenziali come HSTS. Proteggi i tuoi dati, costruisci la fiducia degli utenti e migliora il SEO con una configurazione HTTPS correttamente impostata.
Proteggere Nginx con HTTPS: Una Guida Passo-Passo
Proteggere Nginx con HTTPS è di solito un piccolo lavoro, ma è uno di quei lavori dove piccoli errori sono rumorosi. Un file di certificato mancante impedisce a Nginx di ricaricarsi. Una regola del firewall dimenticata fa sembrare il sito inattivo. Un'intestazione HSTS affrettata può bloccare gli utenti in una configurazione HTTPS rotta più a lungo del previsto.
La buona notizia è che il percorso normale è semplice. Punti il DNS al server, ti assicuri che Nginx risponda sulla porta 80, usi Certbot per richiedere un certificato Let's Encrypt, testi la configurazione Nginx generata, ricarichi, poi verifichi il rinnovo. Questo è il percorso che questa guida segue.
Userò example.com e www.example.com qui sotto. Sostituiscili con i tuoi nomi reali e non saltare i controlli prima di ricaricare Nginx.
Prima di Richiedere un Certificato
Prima di toccare Certbot, conferma i pezzi noiosi. La maggior parte dei problemi con i certificati provengono da DNS, firewall o un blocco server che non risponde per il dominio richiesto.
Controlla il DNS da qualche parte al di fuori del server:
dig +short example.com
dig +short www.example.com
Entrambi i nomi dovrebbero risolversi all'indirizzo pubblico che raggiunge il tuo host Nginx o bilanciatore di carico.
Assicurati che le porte 80 e 443 siano aperte a ogni livello: gruppo di sicurezza cloud, firewall host, firewall di rete e qualsiasi bilanciatore di carico davanti all'host.
sudo ss -tulnp | grep nginx
sudo ufw status
Su una VM cloud, controlla anche la console del provider. Ho visto molte configurazioni Nginx pulite fallire perché il firewall dell'istanza permetteva 443 ma il gruppo di sicurezza cloud lo bloccava ancora.
Infine, conferma che Nginx serva già il dominio su HTTP semplice:
curl -I http://example.com
curl -I http://www.example.com
La risposta non deve essere bella. Può essere una pagina segnaposto. Deve solo dimostrare che le richieste per quel nome host arrivano a questo server Nginx.
Installa Certbot
Per Debian/Ubuntu:
sudo apt update
sudo apt install certbot python3-certbot-nginx
Per sistemi compatibili con RHEL:
sudo dnf install certbot python3-certbot-nginx
I sistemi CentOS più vecchi potrebbero usare yum e potrebbero aver bisogno di EPEL abilitato prima. I nomi dei pacchetti variano anche in base alla versione della distribuzione, quindi usa la documentazione dei pacchetti della tua distribuzione se quei comandi non trovano il plugin.
Richiedi il Certificato
Il plugin Nginx può richiedere il certificato e modificare il blocco server corrispondente:
sudo certbot --nginx -d example.com -d www.example.com
Certbot chiederà un indirizzo email, l'accordo ai termini e talvolta se reindirizzare HTTP a HTTPS. Per un sito web pubblico normale, scegli il reindirizzamento. Per un'API o un servizio interno, controlla prima i client. Alcuni client più vecchi o controlli di integrità potrebbero ancora chiamare http:// e aspettarsi una risposta specifica.
Se Certbot dice che non riesce a trovare un blocco server corrispondente, controlla server_name. Un blocco come questo dà a Certbot qualcosa di chiaro su cui lavorare:
server {
listen 80;
server_name example.com www.example.com;
root /var/www/example.com/public;
index index.html;
location / {
try_files $uri $uri/ =404;
}
}
Esegui un controllo della sintassi prima di chiedere a Certbot di modificare qualsiasi cosa:
sudo nginx -t
Se la configurazione attuale è già rotta, risolvila prima.
Come Dovrebbe Apparire la Configurazione Nginx
Dopo un'esecuzione riuscita, di solito vedrai un blocco HTTP che reindirizza e un blocco HTTPS che serve il sito:
server {
listen 80;
server_name example.com www.example.com;
return 301 https://$host$request_uri;
}
server {
listen 443 ssl;
server_name example.com www.example.com;
ssl_certificate /etc/letsencrypt/live/example.com/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;
include /etc/letsencrypt/options-ssl-nginx.conf;
ssl_dhparam /etc/letsencrypt/ssl-dhparams.pem;
root /var/www/example.com/public;
index index.html;
location / {
try_files $uri $uri/ =404;
}
}
Non copiare questo ciecamente su una configurazione di produzione. Preserva le tue regole location esistenti, le impostazioni del proxy, i log e i limiti di upload. Le parti importanti sono listen 443 ssl, i percorsi dei certificati e il comportamento di reindirizzamento sulla porta 80.
Testa, Ricarica e Verifica
Testa sempre prima di ricaricare:
sudo nginx -t
Poi ricarica:
sudo systemctl reload nginx
Controlla dalla riga di comando:
curl -I http://example.com
curl -I https://example.com
openssl s_client -connect example.com:443 -servername example.com </dev/null 2>/dev/null | openssl x509 -noout -subject -issuer -dates
La richiesta HTTP dovrebbe reindirizzare se hai scelto quell'opzione. La richiesta HTTPS dovrebbe restituire lo stato previsto. Il comando openssl dovrebbe mostrare un certificato il cui soggetto o nomi alternativi del soggetto coprono il dominio e le cui date sono correnti.
Il test nel browser conta ancora. Apri il sito in una finestra privata e clicca sull'icona del lucchetto per ispezionare il certificato. Se il tuo sito carica risorse da vecchi URL http://, la pagina potrebbe mostrare avvisi di contenuto misto anche se il certificato principale è a posto. Correggi quegli URL delle risorse nell'app, CMS o livello del template.
Rinnovo
I certificati Let's Encrypt hanno vita breve, quindi il rinnovo deve funzionare senza che tu te ne ricordi. Certbot di solito installa un timer systemd o un cron job. Controllalo:
systemctl list-timers | grep certbot
sudo certbot renew --dry-run
La prova a secco è la parte utile. Esegue una simulazione di rinnovo e coglie problemi comuni come validazione HTTP rotta, modifiche DNS, plugin mancanti o una configurazione che non può ricaricarsi.
Se termini TLS a un bilanciatore di carico o CDN invece che direttamente sull'host Nginx, il rinnovo potrebbe aver bisogno di una sfida DNS o di un percorso di distribuzione diverso. Non dare per scontato che la sfida HTTP predefinita funzionerà se il traffico pubblico non raggiunge mai questo server.
Impostazioni TLS Che Vale la Pena Controllare
Per la maggior parte dei siti pubblici moderni, TLS 1.2 e TLS 1.3 sono la base pratica:
ssl_protocols TLSv1.2 TLSv1.3;
Evita di ottimizzare a mano gli elenchi di cifratura a meno che tu non sappia perché. Il file options-ssl-nginx.conf incluso di Certbot e il Generatore di Configurazione SSL di Mozilla sono punti di partenza migliori di una stringa di cifratura copiata da un vecchio post del blog. Le linee guida sulle cifrature cambiano nel tempo e i requisiti di compatibilità differiscono tra un sito di marketing pubblico e un'API legacy interna.
HSTS è utile, ma merita cautela:
add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always;
Inizia con un valore breve durante il test:
add_header Strict-Transport-Security "max-age=300" always;
Usa includeSubDomains solo quando ogni sottodominio può servire HTTPS valido. Se old.example.com, mail.example.com o un sottodominio specifico del cliente non è pronto, quell'opzione può rompere utenti reali.
Fallimenti Comuni
Se Certbot non può verificare il dominio, controlla prima il DNS, poi la porta 80, poi il blocco server Nginx. La sfida HTTP-01 ha bisogno che Let's Encrypt raggiunga un token sotto /.well-known/acme-challenge/. I reindirizzamenti vanno bene quando configurati correttamente, ma un proxy, CDN o blocco catch-all può accidentalmente inviare la sfida da qualche altra parte.
Se Nginx non riesce a ricaricarsi dopo le modifiche di Certbot, esegui:
sudo nginx -t
sudo journalctl -u nginx -n 80 --no-pager
Il test di sintassi di solito ti dice il file e la riga esatti. Le cause comuni sono blocchi listen 443 ssl duplicati, un percorso del certificato rimosso o un snippet incluso da un percorso che non esiste su questo server.
Se HTTPS funziona localmente ma non per gli utenti, controlla il percorso pubblico. Un bilanciatore di carico potrebbe ancora puntare a un vecchio gruppo target. Un CDN potrebbe aver memorizzato nella cache un reindirizzamento. Il DNS IPv6 potrebbe puntare a un host diverso rispetto a IPv4. Testa entrambi:
curl -4 -I https://example.com
curl -6 -I https://example.com
La configurazione HTTPS più pulita è noiosa: DNS punta al posto giusto, Nginx ha un blocco server ovvio per il dominio, il rinnovo di Certbot passa in una prova a secco e le intestazioni vengono aggiunte solo dopo che le basi funzionano.