Nella prima parte dell’articolo, pubblicato in precedenza (clicca qui per leggerlo), abbiamo visto  come farsi rilasciare un certificato da Let’s Encrypt; il passo successivo è quello di configurare i vari servizi per poterlo utilizzare.

Dopo aver completato 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 tutto ciò 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). Per finire fullchain.pem è l’insieme completo del certificato e di tutta la sua catena di validazione.

In tutte le tipologie di configurazione è necessario 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 modalità specifiche per gestire la configurazione, che possono riferirsi all’uno o all’altro.

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

Come configurare Apache

In tutte le versioni finora rilasciate, fino alla versione 2.2 di Apache (ormai superata), occorreva usare separatamente i file cert.pem, chain.pem e ovviamente privkey,pem. Per esempio, riferendosi a quelli ottenuti in precedenza, cosi da 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

Nella nuova versione 2.4 di Apache questa regola è 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

Nel momento in cui si usano i medesimi certificati per più virtual host è opportuno inserire questo file (insieme alle altre configurazoni di SSL) in un file distinto, da includere dove necessario.

Cos è Postfix?

Quello che viene richiesto dal server SMTP Postfix per la spedizione della posta è il file fullchain.pem. 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

Cos è Dovecot?

Anche quando usiamo il server POP/IMAP Dovecot è necessario indicare 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

Cos è Nginx?

Se invece si vuole usare Nginx come server web viene, si dovrà di nuovo usare 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;
   ...

Cos è Ejabberd?

Per finire, se vogliamo configurare un server jabber/XMMP come ejabberd occorrerà una modalità ancora diversa, il programma infatti richiede di fornire chiave e certificato tutto all’interno di un unico file contenente in testa la chiave privata (non consente di specificarli separatamente), se quindi /etc/ejabberd/ejabberd.pem è il file usato dal programma, sarà necessario 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" 

Come rinnovare i certificati

Al contrario di quanto abbiamo visto con le Certification Authority tradizionali, la scadenza dei certificati emessi da Let’s Encrypt è di soli tre mesi, invece che di durata annuale (o maggiore). 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 i certificati possono essere rinnovati molto facilmente con certbot utilizzando il sottocomando renew.

E’ possibile eseguire il comando in qualunque momento, e quando rileva un certificato prossimo alla scadenza provvederà a rinnovarlo, 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 esempio se 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). E’ possibile automatizzare il processo inserendo nel cron il comando, ad esempio creando il file /etc/cron.d/letencrypt con il contenuto:

00 23 * * 6  root certbot renew

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

Se invece ci troviamo su Debian e derivate, nelle versioni più recenti del pacchetto, ci accorgeremo che 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 questo caso non è necessario configurare il cron come indicato.

Se volessimo indicare quale sia una delle funzionalità più interessanti di questa procedura automatica di rinnovo fornita da cerbot renew diremmo che è la possibilità di usare anche degli hook che controllano delle operazioni ausiliarie da eseguire in caso di rinnovo. Questo è possibile realizzarlo direttamente 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.

Inoltre utilizzando l’opzione --pre-hook si riesce 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 quando è finita la procedura di rinnovo (ad esempio per far ripartire il server web fermato precedentemente). Questi comandi dopo essere stati indicati vengono eseguiti una sola volta e solo 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.

In ogni caso l’opzione che a noi sembra più utile è --deploy-hook che permette 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 permette 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 utilizzando uno script di shell si possono fare anche operazioni più complesse (come generare il file per ejabberd.pem visto in precedenza).

Un modo alternativo allo specificare queste opzioni nell’invocazione del comando è quello di inserire degli script da eseguire sotto /etc/letsencrypt/renewal-hooks nelle corrispondenti directory deploy, pre e post. In questo caso gli script eseguibili presenti in ciascuna di queste directory verranno realizzati in ordine alfabetico come se li si fossero indicati con le corrispondenti opzioni. Questo permette di inserire le operazioni da eseguire al rinnovo di un certificato in /etc/letsencrypt/renewal-hooks/deploy in altrettanti script, senza cambiare altro. Per riuscire a identificare quale certificato sia 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 articolo/tutorial che abbiamo pubblicato in due momenti diversi (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