Installare un certificato Let’s Encrypt da linea di comando
Innanzitutto apriamo una finestra da terminale e colleghiamoci in SSH al server. Poi rechiamoci sul sito di Certbot.
Sito di Certbot
Quindi selezioniamo il webserver e il sistema operativo del server dai menù a tendina. Ad esempio Apache e Ubuntu 16.04 xenial. Se non ricordate la versione esatta, presupponendo che siate su una macchina Debian based (come Ubuntu), digitate:
$ lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description: Ubuntu 16.04.1 LTS
Release: 16.04
Codename: xenial
Et voilà.
Selezionando quanto richiesto, vengono mostrati i comandi da eseguire (uno per volta) manualmente sul server. In pratica prendiamo il repository mantenuto da Certbot ed installiamo il bot che si occuperà di creare il certificato.
$ sudo apt-get update
$ sudo apt-get install software-properties-common
$ sudo add-apt-repository ppa:certbot/certbot
$ sudo apt-get update
$ sudo apt-get install python-certbot-apache
Ora utilizziamo questo tool per installare un certificato:
$ sudo certbot –apache
Attenzione, con questo comando abbiamo dato implicitamente il consenso di installare le chiavi necessarie al certificato nella configurazione di Apache. Se per qualche ragione non volete che certbot metta le mani nella vostra configurazione, specificate certonly, che si limiterà a generare l’occorrente senza però inserire le chiavi nella configurazione di Apache (chiaramente è un lavoro che dovreste poi fare a mano):
$ sudo certbot –apache certonly
Nel mio caso, non avendo chissà quali esigenze, ho eseguito il comando senza certonly. Verrà chiesto di inserire delle informazioni, come un indirizzo e-mail (per aggiornamenti di sicurezza o richieste urgenti di rinnovo del certificato, di cui parleremo più tardi), di accettare i termini di servizio (obbligatorio) e il permesso di iscrivervi alla newsletter di Electronic Frontier Foundation (gli autori di Certbot). Passiamo alla roba interessante. Arriverete ad un punto analogo a questo:
Which names would you like to activate HTTPS for?
——————————————————————————-
1: navarrosistemi.it
——————————————————————————-
Select the appropriate numbers separated by commas and/or spaces, or leave input
blank to select all options shown (Enter ‘c’ to cancel): __
In questa schermata vengono mostrati i vostri domini a disposizione e viene chiesto di selezionarne uno. Prestate molta attenzione qui! Nel mio caso vedo zombieprocess.it, ma come potete vedere nella barra degli indirizzi, c’è un www davanti. Dunque, se digito 1, sollevo il certificato per zombieprocess.it, non per www.zombieprocess.it. Se siete nella situazione analoga, allora potete specificare l’elenco dei domini che vi interessano mediante l’opzione -d:
sudo certbot –apache -d www.navarrosistemi.it -d navarrosistemi.it
È buona norma sollevare il certificato per il dominio di secondo livello anche se utilizzate esclusivamente quello di terzo (con il www). A questo punto Certbot dice che ha creato una nuova configurazione di Apache, relativo alla porta 443 (usata da TLS), quindi chiede se desideriamo che venga effettuato il redirect da HTTP a HTTPS o meno:
Please choose whether or not to redirect HTTP traffic to HTTPS, removing HTTP access.
——————————————————————————-
1: No redirect – Make no further changes to the webserver configuration.
2: Redirect – Make all requests redirect to secure HTTPS access. Choose this for
new sites, or if you’re confident your site works on HTTPS. You can undo this
change by editing your web server’s configuration.
——————————————————————————-
Select the appropriate number [1-2] then [enter] (press ‘c’ to cancel): __
È un momento delicato. Forse sapete già che è buona norma fare un redirect, ma probabilmente non è questo il momento più adatto. Se per qualche motivo l’installazione del certificato dovesse andare male, rischiereste di forzare un redirect ad un indirizzo HTTPS senza un certificato valido, quindi i vostri utenti vedrebbero una schermata di errore. Quindi, a meno che il vostro non sia un sito in costruzione, consiglio di specificare l’opzione numero 1.
Se invece tutto è andato bene, vedrete un messaggio positivo e tutte le informazioni utili annesse, come i path in cui sono stati salvati il certificato e le chiavi. Chiaramente, se avete usato certonly dovrete creare voi la configurazione di Apache della porta 443 e inserire i path del certificato e delle chiavi necessari.
Impostare il rinnovo automatico
Tutti i certificati hanno una scadenza, ma rinnovarli è semplicissimo, basta usare il comando renew. L’opzione –dry-run permette di fare una simulazione del rinnovo.
sudo certbot renew –dry-run
Purtroppo il certificato di Let’s Encrypt dura solo 3 mesi, perciò dovremmo fare quest’operazione con una certa cadenza. È impensabile per chiunque sano di mente farlo a mano, perciò, da grandi informatici che vogliono automatizzare tutto, inseriremo un cron job, che serve proprio per dire al server di pianificare un’azione con cadenza regolare, senza l’intervento umano. I sistemi Debian-based (come Ubuntu), hanno l’applicativo cron, di cui è possibile consultare il manuale digitando:
man cron
Nella descrizione leggiamo che cron è inserito nella directory speciale init.d, che contiene tutti gli applicativi eseguiti all’avvio del sistema. Quindi cron resta sempre attivo e ogni minuto controlla nei file crontab se ci sono job da eseguire.
Crontab di fatto è un file di testo con un formato preciso:
Dove:
min: minuti, da 0 a 59
ora: autoesplicativo, da 0 a 23
mes: mese, da 1 a 31
gds: giorno della settimana, da 0 (domenica) a 6 (sabato). Si può usare la virgola per indicare più giorni
comando: l’azione che vogliamo eseguire
Editiamo un file crontab digitando:
$ crontab -e
Aggiungiamo righe come queste (sta volta senza –dry-run, perché non vogliamo una simulazione):
3 4 * * 0 /usr/bin/certbot renew
5 6 * * 0 /usr/bin/certbot renew
Stiamo dicendo di fare il rinnovo del certificato tutti i giorni alle 04:03 e alle 06:05. Sembrerà strano tentare di rinnovare il certificato per ben due volte al giorno, invece di prendercela comoda (insomma, abbiamo tre mesi a disposizione), ma è Let’s Encrypt in primis che consiglia di farlo. La ragione è che, in realtà, facciamo dei “tentativi” di rinnovo, di cui la maggior parte non andrà a buon fine. Infatti, il rinnovo vero e proprio viene fatto a pochi giorni di distanza dalla scadenza effettiva. La documentazione consiglia anche di scegliere orari a caso, e così ho fatto, incentrandoli di notte, per non impegnare il server durante le ore con più traffico.
Salivamo il file. Mi preme dire che non c’è bisogno di mettere sudo davanti al comando. Ve lo dico perché girano soluzioni in cui si specifica la password… in chiaro. È un erroraccio da non fare mai!
Ci resta ancora una cosa da fare: il redirect, ricordate? Ora che siamo sicuri che tutto funziona possiamo farlo. Basta modificare il file di configurazione del virtual host sulla porta 80 (cioè per il sito in HTTP) e impostare il redirect sulla porta 443 (cioè HTTPS):
RewriteEngine On
RewriteCond %{HTTPS} off
RewriteRule ^ https://%{HTTP_HOST}%{REQUEST_URI}
…
Riavviamo Apache:
sudo service apache2 restart
E abbiamo finito… quasi. Ricordate di seguire tutte le buone norme per una corretta migrazione ad HTTPS. Aggiungete la versione HTTPS come proprietà nella Search Console (Dashboard > selezionate la proprietà con HTTPS > ingranaggio > Impostazioni sito > scegliere) e indicatela come preferita. Indicate il cambio di protocollo anche nel pannello di Google Analytics (Dashboard > Amministratore > Impostazioni proprietà > selezionare HTTPS sotto URL predefinito), altrimenti potreste avere statistiche non rilevate. Infine, se usate WordPress, consiglio il plugin Really Simple SSL, che vi aiuta a forzare le risorse del vostro sito ad HTTPS, importante anche per evitare il triangolino giallo invece del lucchetto verde.
Questo è tutto e rendiamo ancora grazie a Let’s Encrypt, che permette di muovere il web verso una forma più sicura in pochi passaggi.
