Come puntare un dominio al tuo VPS e attivare HTTPS gratis

Questa guida spiega come puntare un dominio al tuo VPS, in modo che example.com e www.example.com portino al tuo sito, e come attivare HTTPS con un certificato gratuito di Let's Encrypt. [1] È pensata per chi ha un dominio e un VPS con Ubuntu 24.04 LTS e nginx o Apache, con il DNS gestito dal registrar o da Cloudflare. Sostituisci example.com e 203.0.113.10 con il tuo dominio e l’indirizzo del tuo server.

Cosa ti serve prima di iniziare

Ti servono quattro cose:

• L’accesso al DNS del dominio, presso il registrar o, se il dominio usa i nameserver di Cloudflare, su Cloudflare.
• L’accesso SSH con privilegi sudo, tramite chiave SSH anziché password di root, come indicato nella nostra checklist per mettere in sicurezza SSH.
• nginx o Apache, installato e in esecuzione.
• L’indirizzo IPv4 pubblico del server, che il tuo provider indica tra i dettagli del server. Ogni VPS Linux di StealthRDP ha un indirizzo IPv4 dedicato.

IPv6 è facoltativo: un record AAAA associa un nome a un indirizzo IPv6, quindi aggiungi record AAAA solo se il server ne ha uno. [2] Devi ancora scegliere il server? Può esserti utile la nostra guida al dimensionamento di un VPS per l’hosting web.

Come puntare un dominio al tuo VPS con i record DNS

Per puntare un dominio al tuo VPS, crea dei record A che associno example.com e www.example.com all’indirizzo IPv4 del server. [2] Apporta la modifica presso il servizio che gestisce il DNS del dominio.

dig -t A example.com @8.8.8.8
dig -t A www.example.com @8.8.8.8

nslookup -type=A example.com 8.8.8.8
nslookup -type=A www.example.com 8.8.8.8

Apri le porte 80 e 443 con UFW

Di norma HTTP usa la porta TCP 80 e HTTPS la 443, e Certbot ha bisogno che la porta 80 sia raggiungibile dal resto di Internet. [4] UFW è inizialmente disattivato, con una policy predefinita che blocca le connessioni in ingresso; attivarlo può far cadere le connessioni esistenti, come la tua sessione SSH, e se lo attivi via SSH ti chiede una conferma. [5]

sudo ufw allow 22/tcp
sudo ufw allow 80/tcp
sudo ufw allow 443/tcp
sudo ufw enable
sudo ufw status

Se nelle regole preferisci indicare un profilo applicativo invece dei numeri di porta, sudo ufw app list mostra i profili presenti sul server e sudo ufw app info le porte che apre ciascuno; metti tra virgolette i nomi che contengono spazi. [5] Con IPv6 attivo in UFW, come da impostazione predefinita, ogni regola vale sia per IPv4 sia per IPv6. [5] Se il tuo provider ha un firewall davanti al server, apri le stesse porte anche lì. [4]

Pubblica example.com con nginx o Apache

Configura example.com sul web server prima di aggiungere HTTPS, perché Certbot si aspetta un sito che risponda già in semplice HTTP. [4]

nginx: un unico server block per entrambi i nomi

Su Ubuntu, nginx tiene ogni server block in /etc/nginx/sites-available e lo attiva con un link simbolico in /etc/nginx/sites-enabled; indica entrambi i nomi nella riga server_name. [6]

server {
    listen 80;
    listen [::]:80;
    server_name example.com www.example.com;

    root /srv/example.com/html;
    index index.html;

    location / {
        try_files $uri $uri/ =404;
    }
}

sudo mkdir -p /srv/example.com/html
echo "example.com works" | sudo tee /srv/example.com/html/index.html
sudo ln -s /etc/nginx/sites-available/example.com /etc/nginx/sites-enabled/
sudo nginx -t
sudo systemctl reload nginx

Apache: l’equivalente con un virtual host

Su Apache, un virtual host in /etc/apache2/sites-available usa ServerName per example.com e ServerAlias per www.example.com; parti da una copia del file predefinito e attivalo con a2ensite. [7]

sudo cp /etc/apache2/sites-available/000-default.conf /etc/apache2/sites-available/example.com.conf

<VirtualHost *:80>
    ServerName example.com
    ServerAlias www.example.com
    DocumentRoot /var/www/example.com
</VirtualHost>

sudo mkdir -p /var/www/example.com
echo "example.com works" | sudo tee /var/www/example.com/index.html
sudo a2ensite example.com
sudo systemctl restart apache2.service

Apri http://example.com e http://www.example.com: entrambi devono mostrare la pagina di prova.

Attiva HTTPS gratis con Let's Encrypt e Certbot

Certbot ottiene un certificato da Let's Encrypt e può configurare nginx o Apache per usarlo. [4]

sudo apt-get remove certbot
sudo snap install --classic certbot
sudo ln -s /snap/bin/certbot /usr/local/bin/certbot

sudo certbot --nginx

sudo certbot --apache

sudo certbot renew --dry-run
systemctl list-timers

Quanto durano i certificati Let's Encrypt

Per impostazione predefinita, i certificati di Let's Encrypt sono validi 90 giorni. [1] Dal 10 febbraio 2027, i certificati emessi o rinnovati avranno per impostazione predefinita una validità di 64 giorni, gli ultimi certificati da 90 giorni dovrebbero scadere l’11 maggio 2027 e per il 2028 Let's Encrypt prevede una durata predefinita di 45 giorni. [8] Se hai scritto un tuo cron job con un intervallo fisso, Let's Encrypt consiglia invece di rinnovare a circa due terzi della durata del certificato e di controllare che negli script non ci siano numeri scritti direttamente nel codice, come 60, 80 o 83. [8]

Con il proxy di Cloudflare attivo, usa Full (strict)

Quando il proxy di Cloudflare è attivo, imposta la modalità di cifratura SSL/TLS su Full (strict). La modalità si applica sia alla connessione tra i visitatori e Cloudflare sia a quella tra Cloudflare e il tuo server. [9]

Evita Flexible: il browser mostra HTTPS, ma il traffico tra Cloudflare e il tuo server non è cifrato, e la stessa Cloudflare consiglia vivamente Full o Full (strict). [9] Flexible, inoltre, entra in conflitto con il reindirizzamento da HTTP a HTTPS che Certbot può aggiungere alla configurazione. [4] Cloudflare contatta il server in semplice HTTP, il server reindirizza a HTTPS e il browser entra in un ciclo infinito di reindirizzamenti. [9] Full (strict) verifica il certificato del server, che può essere rilasciato da una CA pubblica come Let's Encrypt. [9]

Se il certificato scade, Cloudflare non riporta la zona da Full (strict) a Full, quindi il rinnovo deve continuare a funzionare. [9] L’ordine più semplice è: prima il certificato, poi il proxy.

1. Ottieni il certificato mentre entrambi i record sono su DNS only.
2. Passa entrambi i record a Proxied.
3. Nella pagina SSL/TLS Overview scegli Full (strict); se la zona usa Automatic SSL/TLS, seleziona prima Custom. [9]
4. Esegui di nuovo sudo certbot renew --dry-run.

Anche con il proxy già attivo, l’emissione del certificato può funzionare: in Full e Full (strict), quando la richiesta è in HTTP, Cloudflare raggiunge il server in HTTP, quindi la richiesta di verifica di Certbot sulla porta 80 può arrivare al server. [9] Strict (SSL-Only Origin Pull) si connette sempre in HTTPS, quindi non funziona finché il certificato non esiste. [9] Se l’emissione fallisce, riporta i record su DNS only, ottieni il certificato e poi riattiva il proxy.

Con il proxy attivo, però, l’IP del server risponde ancora a chiunque lo conosca. Per chiudere questa falla, consenti l’accesso solo agli IP di Cloudflare sulle porte 80 e 443.

Problemi comuni e come risolverli

La maggior parte degli errori dipende dal DNS, dal firewall o da troppi tentativi.

Il DNS non si è ancora aggiornato. Se vedi un indirizzo vecchio, un resolver sta ancora restituendo la risposta che ha in cache, e può continuare a farlo finché il TTL non scade. [2] Dopo un cambio di server DNS o di registrar, anche Google Public DNS può restituire risposte vecchie, e puoi cancellarle con il suo strumento Flush Cache. [3]

Un record sbagliato o mancante. Verifica che l’indirizzo non contenga errori di battitura, che non sia rimasto un vecchio record del registrar, che esista il record www e che tu non abbia modificato i record presso un provider DNS che il dominio non usa più. Se manca il record www, non ottieni nemmeno il certificato HTTPS, perché ogni nome incluso nella richiesta deve superare la convalida. [10] Rimuovi i record AAAA, a meno che il server non risponda davvero su quell’indirizzo IPv6.

La porta 80 è bloccata. Secondo Let's Encrypt, le convalide HTTP-01 fallite dipendono di solito da impostazioni di rete o del firewall che impediscono ai suoi server di raggiungere il tuo. [10] Controlla l’output di sudo ufw status e il firewall del tuo provider, e lascia aperta la porta 80 anche dopo il passaggio a HTTPS, perché i plugin nginx e Apache di Certbot ne hanno bisogno. [4]

Troppi tentativi falliti. Un account può accumulare al massimo 5 convalide fallite all’ora per lo stesso nome; i tentativi disponibili si ricaricano al ritmo di uno ogni 12 minuti e, finché non se ne libera uno, Let's Encrypt rifiuta nuovi ordini per quel nome. [10] Inoltre emette al massimo 5 certificati per lo stesso identico insieme di nomi ogni 7 giorni, e capita spesso di raggiungere questo limite reinstallando il client durante la risoluzione dei problemi. [10] Let's Encrypt non può azzerare un limite in anticipo, e nemmeno la revoca dei certificati lo azzera, quindi risolvi la causa prima di riprovare; per i test consiglia il suo ambiente di staging, che ha limiti molto più alti. [10]

Se dominio e certificato funzionano ma la pagina mostra 502 Bad Gateway, segui la nostra guida per risolvere l’errore 502 Bad Gateway.

Domande frequenti

Quanto tempo ci vuole perché un dominio punti a un nuovo VPS?

Dipende dal TTL dei record e da ciò che i resolver hanno già in cache. Su Cloudflare, i record con proxy attivo hanno un TTL predefinito di 300 secondi e i record DNS only usano il valore che imposti tu. Un resolver, inoltre, può conservare una risposta vecchia finché il suo TTL non scade. [2]

Per www è meglio un record A o un CNAME?

Funzionano entrambi. Un record A fa puntare www direttamente all’indirizzo IPv4 del server, mentre un CNAME lo fa puntare a un altro nome, come example.com, e quindi segue quel record se l’indirizzo cambia. [2]

Let's Encrypt è gratuito?

Sì. Let's Encrypt non fa pagare i suoi certificati, che per impostazione predefinita sono validi 90 giorni. [1]

Per quanto tempo sono validi i certificati Let's Encrypt?

Oggi i certificati di Let's Encrypt sono validi, per impostazione predefinita, 90 giorni. [1] Dal 10 febbraio 2027, i certificati nuovi e rinnovati avranno per impostazione predefinita una validità di 64 giorni, e per il 2028 Let's Encrypt prevede una durata predefinita di 45 giorni. [8]

Quale modalità SSL/TLS di Cloudflare devo usare con Let's Encrypt?

Usa Full (strict). Questa modalità verifica il certificato del tuo server, che può essere rilasciato da Let's Encrypt, mentre Flexible lascia non cifrata la connessione tra Cloudflare e il server. [9]