Abbiamo visto nella prima parte come farsi rilasciare un certificato da Let’s Encrypt; il passo successivo è quello di configurare i vari servizi per utilizzarlo.

Una volta completata la validazione del proprio dominio nella directory di installazione dei certificati (/etc/letsencrypt/live/mio.dominio.it) vengono sempre creati i seguenti file:

Dove cert.pem è il certificato singolo del proprio dominio, e privkey.pem la sua chiave privata, necessaria per poterlo usare per cifrare le comunicazioni. A questo si aggiunge chain.pem, il certificato intermedio (o la catena di certificati intermedi) che validano cert.pem come rilasciato da una Certification Autority riconosciuta (Let’s Encrypt, appunto). Infine fullchain.pem è l’insieme completo del certificato e di tutta la sua catena di validazione.

In qualunque configurazione occorre sempre fare riferimento a questi file, la loro presenza è dovuta al fatto che sono molti i servizi che forniscono connessioni cifrate con SSL/TLS, non solo il web, ed ognuno ha sue modalità specifiche di gestire la configurazione, che possono richiedere l’uno o l’altro.

Si noti inoltre che tutti questi file sono dei link simbolici, che rimandano ad altri file, questo avviene perché come vedremo Let’s Encrypt prevede una procedura di aggiornamento automatico, che consentirà di cambiare i file sottostanti con le nuove versioni, facendo comunque sempre riferimento a questi nomi, in modo da non dover toccare le configurazioni.

La configurazione di Apache

Fino alla versione 2.2 di Apache (ormai obsoleta) occorreva usare separatamente i file cert.pem, chain.pem e ovviamente privkey,pem. Ad esempio, facendo riferimento a quelli ottenuti in precedenza, per abilitare in un virtual host l’uso del certificato si sarebbero dovute usare al suo interno le seguenti direttive di configurazione:

SSLCertificateFile /etc/letsencrypt/live/mail.truelite.it/cert.pem
SSLCertificateChainFile /etc/letsencrypt/live/mail.truelite.it/chain.pem
SSLCertificateKeyFile /etc/letsencrypt/live/mail.truelite.it/privkey.pem

Con la versione 2.4 di Apache questa sintassi è ancora supportata, anche se sconsigliata e non è più necessario usare SSLCertificateChainFile che è deprecata (e prima o poi sarà rimossa), e si deve invece passare ad usare il file fullchain.pem con una configurazione del tipo:

SSLCertificateFile /etc/letsencrypt/live/mail.truelite.it/fullchain.pem
SSLCertificateKeyFile /etc/letsencrypt/live/mail.truelite.it/privkey.pem

Quando si usano gli stessi certificati per più virtual host è opportuno inserire questo file (insieme alle altre configurazoni di SSL) in un file distinto, da includere dove necessario.

Postfix

Il file fullchain.pem è anche quello che viene richiesto anche dal server SMTP Postfix per la spedizione della posta. Per abilitare il supporto SSL/TLS (necessario quando si esegue una spedizione autenticata) occorrerà farvi riferimento in /etc/postfix/main.cf con le direttive:

smtpd_use_tls=yes
smtpd_tls_cert_file=/etc/letsencrypt/live/mail.truelite.it/fullchain.pem
smtpd_tls_key_file=/etc/letsencrypt/live/mail.truelite.it/privkey.pem

Dovecot

Anche il server POP/IMAP Dovecot richiede che si indichi l’insieme del certificato e della catena di validazione di fullchain.pem; in questo caso una configurazione possibile è quella di inserire in /etc/dovecot/conf.d/90-user.conf le direttive:

ssl = yes
ssl_cert = </etc/letsencrypt/live/mail.truelite.it/fullchain.pem
ssl_key = </etc/letsencrypt/live/mail.truelite.it/privkey.pem

Nginx

Qualora si usi invece Nginx come server web viene di nuovo fatto uso di fullchain.pem; in questo caso per utilizzare il certificato si dovrà inserire nella configurazione del proprio virtual host qualcosa del tipo:

server {
   listen 443 ssl;
   server_name mail.truelite.it;
   root /var/www/html;
   ssl_certificate /etc/letsencrypt/live/mail.truelite.it/fullchain.pem;
   ssl_certificate_key /etc/letsencrypt/live/mail.truelite.it/privkey.pem;
   ...

ejabberd

Infine per configurare un server jabber/XMMP come ejabberd occorre una modalità ancora diversa, il programma infatti richiede di fornire chiave e certificato in un unico file contenente in testa la chiave privata (non consente di specificarli separatamente), se pertanto /etc/ejabberd/ejabberd.pem è il file usato dal programma, occorrerà rigenerarlo ogni volta che si generano o rinnovano i certificati con:

cat /etc/letsencrypt/live/jabber.truelite.it/privkey.pem \
    /etc/letsencrypt/live/jabber.truelite.it/fullchain.pem > ejabberd.pem

ed inserire in /etc/ejabberd/ejabberd.yml le righe:

certfiles:
  - "/etc/ejabberd/ejabberd.pem" 

Il rinnovo dei certificati

A differenza di quanto accade con le Certification Authority tradizionali, che normalmentne forniscono certificati di durata annuale (o più lunga) la scadenza dei certificati emessi da Let’s Encrypt è di soli tre mesi. La scelta è voluta, per ridurre l’impatto di una compromissione, ma come accennato all’inizio il grande vantaggio di Let’s Encrypt è che una volta ottenuti questi possono essere rinnovati molto facilmente con certbot utilizzando il sottocomando renew.

Il comando può essere eseguito in qualunque momento, e quando rileva un certificato prossimo alla scadenza provvederà ad eseguire il rinnovo, utilizzando la stessa metologia con cui lo si è ottenuto la prima volta (nel caso dei nostri esempi certonly, ma la cosa vale anche per gli altri metodi che non abbiamo considerato). Per cui se ad esempio si esegue il comando dopo averne ottenuto uno si otterrà qualcosa del tipo:

# certbot renew
Checking for new version...
Requesting root privileges to run letsencrypt...
   /root/.local/share/letsencrypt/bin/letsencrypt renew

-------------------------------------------------------------------------------
Processing /etc/letsencrypt/renewal/mail.truelite.it.conf
-------------------------------------------------------------------------------

The following certs are not due for renewal yet:
  /etc/letsencrypt/live/mail.truelite.it/fullchain.pem (skipped)
No renewals were attempted.

ed in questo caso il certificato non è stato rinnovato perché è ancora valido (il default è non rinnovare prima di 10 giorni dalla scadenza, a meno di non forzare il rinnovo con l’ulteriore opzione --force-renewal). La cosa si può automatizzare inserendo banalmente nel cron il comando, ad esempio creando il file /etc/cron.d/letencrypt con il contenuto:

00 23 * * 6  root certbot renew

che tenta il rinnovo ogni domenica sera alle 23:00.

Su Debian e derivate, nelle versioni più recenti del pacchetto viene installato un cron job /etc/cron.d/certbot (non usato se la distibuzione usa systemd) ed un timer ed un service di systemd che eseguono due volte al giorno il comando certbot -q renew. In tal caso non è necessario configurare il cron come indicato.

Una delle funzionalità più interessanti di questa procedura automatica di rinnovo fornita da cerbot renew è che è possibile anche usare degli hook che controllano delle operazioni ausiliarie da eseguire in caso di rinnovo. Questo si può fare esplicitamente nel comando certbot renew aggiungendo le opzioni --pre-hook, --post-hook o --deploy-hook specificando come parametro delle stesse il comando da eseguire in ciascuno dei casi.

L’opzione --pre-hook serve ad eseguire il comando specificato prima di iniziare la procedura di rinnovo (ad esempio per fermare un server web per consentire l’uso di --standalone), mentre l’opzione --post-hook serve ad eseguire il comando specificato finita la procedura di rinnovo (ad esempio per far ripartire il server web fermato precedentemente). Questi comandi se indicati vengono eseguiti una sola volta quando si esegue il rinnovo dei certificati (anche nel caso siano più di uno); se si è creato il certificato con certbot certonly in genere non sono necessari.

L’opzione più utile resta --deploy-hook che consente di indicare un comando da eseguire dopo avere effettivamente ottenuto il rinnovo di un certificato (non viene eseguita se certbot rileva che il certificato non deve essere rinnovato e viene eseguita per ogni certificato rinnovato). Questo consente ad esempio di riavviare i servizi che stavano usando il vecchio certificato in modo da fargli usare quello rinnovato (si potrebbe ad esempio usare --deploy-hook="systemctl restart apache2"), ma usando uno script di shell si possono fare anche operazioni più complesse (come generare il file per ejabberd.pem visto in precedenza).

Una alternativa allo specificare queste opzioni nell’invocazione del comando è quella di inserire degli script da eseguire sotto /etc/letsencrypt/renewal-hooks nelle corrispondenti directory deploy, pre e post. In tal caso gli script eseguibili presenti in ciascuna di queste directory verranno eseguiti in ordine alfabetico come se li si fossero indicati con le corrispondenti opzioni. Questo consente di inserire le operazioni da eseguire al rinnovo di un certificato in /etc/letsencrypt/renewal-hooks/deploy in altrettanti script, senza cambiare altro. Per identificare quale certificato è stato rinnovato, gli script verranno eseguiti definendo nel loro ambiente le variabili RENEWED_LINEAGE che contengono il pathname alla directory del certificato rinnovato (ad esempio /etc/letsencrypt/live/mail.truelite.it) e RENEWED_DOMAINS che contiene l’elenco dei domini (separto da spazi) in esso contenuti (ad esempio “mail.truelite.it posta.truelite.it“).

Questo tutorial che abbiamo pubblicato in due articoli (vedi prima parte) ha come obiettivo quello di aiutare gli utenti nella configurazione e nella certificazione del proprio sito web.

In caso di ulteriori approfondimenti o consulenze più mirate e personalizzate, potete contattarci al seguente indirizzo mail: info@notjustacloud.com 

                                                                                                       La redazione