Errori di reindirizzamento HTTPS e certificato SSL Nginx
introduzione
Cerbot per aiutare ad automatizzare il processo di ottenimento di un certificato e assistere nel reindirizzamento al processo HTTPS, ci sono ancora errori che possono verificarsi con il tuo server web Nginx.
Gli esempi in questa guida sono stati testati su un server Ubuntu 22.04 ma dovrebbero essere applicabili alla maggior parte delle installazioni Nginx. La maggior parte di questi errori può essere risolta nell'ambito del file di configurazione standardizzato di Nginx, sebbene directory e percorsi possano differire leggermente.
In questo tutorial, imparerai gli errori comuni che possono emergere durante l'impostazione dei certificati TLS/SSL e delle connessioni di reindirizzamento HTTPS per il tuo server Nginx. Imparerai anche come identificare le possibili cause di questi errori di reindirizzamento e risolverli.
Ispezione del registro degli errori di Nginx
Gli errori e le soluzioni presentati in questo tutorial sono casi comuni, ma non esaustivi. A causa della natura degli errori di sintassi che interrompono la struttura di ciò che Nginx riconosce come dichiarazioni valide, i seguenti errori sono solo linee guida per la risposta di Nginx. Spesso, un errore può sovrapporsi a un altro e un errore può essere sintomatico di un problema più ampio o separato. La tua situazione specifica e la configurazione possono variare.
Tieni presente che puoi sempre fare riferimento al registro degli errori di Nginx per visualizzare un elenco in esecuzione:
- sudo cat /var/log/nginx/error.log
Verifica della tua direttiva di reindirizzamento per il tuo blocco server
Se riscontri problemi con il tuo sito web che non reindirizza da HTTP a HTTPS, potrebbe esserci un problema con la direttiva che hai impostato nel tuo file di configurazione. Nello specifico, la direttiva listen dovrebbe puntare alla porta appropriata, in questo caso, 443, che indica il traffico HTTPS crittografato. Per il contesto, se imposti un blocco del dominio del server per il tuo server web Nginx, la tua configurazione potrebbe seguire questa struttura:
server {
listen 80;
listen [::]:80;
root /var/www/example.com/html;
index index.html index.htm index.nginx-debian.html;
server_name example.com www.example.com;
location / {
try_files $uri $uri/ =404;
}
}
Il contenuto di questo file fornisce dettagli su diverse direttive, ma la più importante a cui prestare attenzione è quella listen. Al momento, questa direttiva consente solo le richieste in entrata per la porta 80, che è l'impostazione predefinita per Nginx. Questa porta è anche per il traffico HTTP, non HTTPS. Per consentire il reindirizzamento del traffico HTTP a HTTPS, è necessario aggiornare la direttiva listen per includere la porta 443.
Un modo per farlo in modo efficiente è ottenere un certificato TLS/SSL da un'autorità di certificazione (CA) come Let's Encrypt. Avere un certificato per il tuo sito web aiuta ad abilitare HTTPS crittografato per i server web.
Inoltre, l'ottenimento e l'installazione di questo certificato è completamente automatizzato per Nginx tramite un client software chiamato Certbot, che ha un plug-in per Nginx. Puoi consentire a Certbot di configurare automaticamente il tuo file di configurazione Nginx per reindirizzare tutto il traffico HTTP a HTTPS e impedire il traffico HTTP diretto. Puoi anche farlo manualmente se preferisci, e si applicano gli stessi principi. Scopri di più su come farlo con il nostro tutorial su Come proteggere Nginx con Let's Encrypt. Ai fini di questo tutorial, abbiamo ottenuto un certificato tramite Let's Encrypt e il file di configurazione è aggiornato come segue:
server {
root /var/www/example.com/html;
index index.html index.htm index.nginx-debian.html;
server_name example.com www.example.com;
location / {
try_files $uri $uri/ =404;
}
listen [::]:443 ssl ipv6only=on; # managed by Certbot
listen 443 ssl; # managed by Certbot
ssl_certificate /etc/letsencrypt/live/example.com/fullchain.pem; # managed by Certbot
ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem; # managed by Certbot
include /etc/letsencrypt/options-ssl-nginx.conf; # managed by Certbot
ssl_dhparam /etc/letsencrypt/ssl-dhparams.pem; # managed by Certbot
}
server {
if ($host = www.example.com) {
return 301 https://$host$request_uri;
} # managed by Certbot
if ($host = example.com) {
return 301 https://$host$request_uri;
} # managed by Certbot
listen 80;
listen [::]:80;
server_name example.com www.example.com;
return 404; # managed by Certbot
}
Se si confronta questo blocco del dominio del server con il primo esempio, è possibile valutare le modifiche apportate a seguito dei passaggi automatizzati gestiti da Certbot per impostare il certificato SSL. Ancora più importante, la direttiva listen ora punta alla porta 443, il che significa che le connessioni HTTPS sono consentite. Anche il certificato e la chiave generati da Certbot tramite Let's Encrypt sono ora associati al blocco del server.
Inoltre, Certbot ristruttura il blocco del tuo server per reindirizzare tutto il traffico HTTP su HTTPS. Ora hai un blocco server aggiuntivo, che gestisce la tua direttiva di ascolto originale sulla porta 80. Questo nuovo blocco del server cattura tutto il traffico verso i tuoi domini eseguendo un controllo condizionale sulla variabile $host. Questo viene eseguito con le istruzioni della direttiva condizionale if. Queste direttive controllano se la variabile corrisponde ai tuoi domini, quindi Nginx utilizza un reindirizzamento 301 per inviare la richiesta alla versione HTTPS del sito. Inoltre, come misura di sicurezza, tutto il traffico che riesce a superare il reindirizzamento condizionale verrà rilevato come errore 404.
Se i problemi persistono, tuttavia, potresti voler controllare le impostazioni del firewall e modificarle se necessario.
Regolazione delle impostazioni del firewall
Se il tuo browser web non risponde anche dopo aver configurato il certificato TLS/SSL, potresti avere un problema con le impostazioni del firewall. Come accennato nella sezione precedente, il reindirizzamento da HTTP e HTTPS viene impostato automaticamente come direttiva listen nel tuo file di configurazione se hai seguito il tutorial Let's Encrypt. Pertanto, una possibile causa di errore è che il firewall non consente il traffico HTTPS sulla porta 443.
Per verificare lo stato di quali porte sono attualmente aperte sul tuo firewall, puoi eseguire il seguente comando. Tieni presente che questo tutorial utilizza Uncomplicated Firewall, UFW, quindi potrebbe variare a seconda della tua distribuzione:
- sudo ufw status
Status: active
To Action From
-- ------ ----
OpenSSH ALLOW Anywhere
Nginx HTTP ALLOW Anywhere
OpenSSH (v6) ALLOW Anywhere (v6)
Nginx HTTP (v6) ALLOW Anywhere (v6)
Se il tuo output riflette un elenco simile al seguente, significa che il tuo firewall è attualmente aperto solo per accettare richieste da HTTP. Per regolare queste impostazioni, aggiungi il profilo Nginx HTTPS che consente il traffico crittografato TLS/SSL tramite la porta 443. Per fare ciò, esegui il seguente comando:
- sudo ufw allow 'Nginx HTTPS'
Se hai ricevuto un output di Regola aggiunta, allora hai aggiunto correttamente questo profilo al tuo elenco. Puoi confermare controllando lo stato:
- sudo ufw status
Status: active
To Action From
-- ------ ----
OpenSSH ALLOW Anywhere
Nginx HTTP ALLOW Anywhere
Nginx HTTPS ALLOW Anywhere
OpenSSH (v6) ALLOW Anywhere (v6)
Nginx HTTP (v6) ALLOW Anywhere (v6)
Nginx HTTPS (v6) ALLOW Anywhere (v6)
Nota: è disponibile un profilo Nginx chiamato Nginx Full che apre le connessioni alla porta HTTP e HTTPS. Se vuoi ripulire l'elenco, puoi rimuovere le due regole con sudo ufw delete allow Nginx HTTP e sudo ufw delete allow Nginx HTTPS e aggiungere la seguente regola:
- sudo ufw allow 'Nginx Full'
Il tuo firewall è quindi pronto ad accettare connessioni dal traffico HTTP e HTTPS.
Ora sono elencati entrambi i profili Nginx HTTP e HTTPS, la porta 443 è aperta e le richieste verranno reindirizzate a HTTPS.
Impostazione sicura del reindirizzamento con un certificato TLS/SSL
Il reindirizzamento da HTTP a HTTPS significa che stai consentendo connessioni di traffico crittografate e questo è in genere verificato con un certificato TLS/SSL. Tuttavia, ci sono ancora possibili messaggi di errore a livello di browser. Tieni presente che questi messaggi di errore non indicano che qualcosa non va nel tuo server Nginx, ma piuttosto nel certificato stesso.
Ad esempio, se utilizzi un certificato SSL autofirmato, questo non viene verificato da un'autorità di certificazione (CA) come con Let's Encrypt. Di conseguenza, quando accedi al browser all'indirizzo https://example.com, è probabile che venga visualizzato un messaggio di avviso per avvisare i visitatori che questo sito non è sicuro:
In questo scenario, c'è un errore che legge La tua connessione non è privata e ha un errore specifico che indica NET::ERR_CERT_AUTHORITY_INVALID. È possibile superarlo nonostante il certificato non sia sicuro se si preme sull'opzione Avanzate:
L'opzione Avanzate specifica che example.com non può essere adeguatamente identificato. Anche se questo potrebbe non essere vero perché hai configurato il tuo server web con un certificato SSL autofirmato, è così che viene percepito da chiunque visiti il tuo sito.
Sebbene tu possa continuare sul tuo sito Web premendo l'opzione Procedi a..., è un'esperienza utente scadente ricevere questo tipo di messaggio di sicurezza e privacy quando visiti il tuo sito. Ti consigliamo di utilizzare un certificato verificato da una CA. Puoi configurarlo leggendo il nostro tutorial su Come proteggere Nginx con Let's Encrypt.
Tuttavia, è possibile ricevere il seguente messaggio anche se si dispone di un certificato TLS/SSL impostato tramite Let's Encrypt:
Questo messaggio differisce dall'originale La tua connessione non è un messaggio privato perché l'errore di rete indica NET::ERR_CERT_DATE_INVALID, il che significa che il tuo attuale certificato SSL/TLS è scaduto. È importante notare che un certificato Let's Encrypt è valido solo per 90 giorni. Se hai utilizzato il pacchetto certbot durante l'installazione di Let's Encrypt, verrà programmato un controllo per i certificati in scadenza entro i prossimi 30 giorni, che verrà eseguito due volte al giorno tramite systemd.
Puoi controllare lo stato del timer con quanto segue:
- sudo systemctl status snap.certbot.renew.service
L'output confermerà che il rinnovo del certificato è attivo.
Tuttavia, se il tuo certificato è scaduto e vuoi forzare il rinnovo, puoi farlo con il seguente comando. Questo è utile anche se hai diversi domini per i quali desideri rinnovare un certificato:
- certbot certonly –force-renew -d example.com
Anche se il pacchetto certbot viene fornito con uno script di rinnovo del certificato con /etc/cron.d, ci sono anche altre opzioni. Ad esempio, puoi impostare l'opzione renew_hook con Certbot in modo da poter eseguire altre attività dopo il rinnovo. Per fare ciò, devi aggiungere renew_hook al file di configurazione del rinnovo di Certbot. Inizia aprendo il file con il tuo editor di testo preferito:
- sudo nano /etc/letsencrypt/renewal/example.com.conf
Una volta che sei all'interno del file, aggiungi l'hook all'ultima riga per ricaricare i servizi rivolti al Web in modo che possano essere configurati per utilizzare il certificato rinnovato:
renew_hook = systemctl reload your_service
Al termine, puoi salvare e chiudere il file. Se stai utilizzando nano, premi CTRL + X, Y e poi INVIO.
Indipendentemente da ciò che scegli quando imposti il processo di rinnovo del certificato, puoi sempre confermare che certbot sta eseguendo il processo di rinnovo come previsto con il seguente comando:
- sudo certbot renew --dry-run
Infine, controlla eventuali errori di sintassi con sudo nginx -t e quindi riavvia Nginx con sudo systemctl restart nginx per assicurarti che le tue modifiche siano implementate. Dopo aver eseguito tutte queste operazioni, accedi al tuo browser Web all'indirizzo https://example.com per verificare che il reindirizzamento funzioni correttamente.
Conclusione
In questo tutorial, hai imparato come risolvere gli errori comuni con i reindirizzamenti del server Web Nginx, in particolare da HTTP a HTTPS. Alcune di queste soluzioni includono la verifica che il file di configurazione sia impostato correttamente per ascoltare la porta appropriata, l'apertura del firewall per ricevere tali connessioni e come gestire i messaggi di errore di sicurezza che potresti ricevere relativi ai certificati SSL/TLS non verificati o scaduti . Se sei interessato a saperne di più su Nginx, puoi dare un'occhiata a come installare Nginx su Ubuntu 22.04.