L’utilizzo dei certificati SSL è ormai divenuto uno dei passi fondamentali nella gestione della sicurezza della rete, in quanto consente sia di identificare l’autenticità del corrispondente, garantendone opportunamente l’identità, sia di cifrare le comunicazioni, evitando una possibile intercettazione dei dati, inoltre è necessario per l’accesso in HTTPs ai siti web.
A lungo però il loro impiego era strettamente legato all’acquisto, talvolta anche molto oneroso, dei certificati presso una Certification Authority, ed alla necessità di reinstallazione periodica degli stessi.
Il progetto di Let’s Encrypt , nacque per poter mettere a disposizione a costo zero e rendere più semplice e fruibile, una tecnologia che è fondamentale per la sicurezza di internet, e ha portato alla una nuova Certification Authority libera e gratuita promossa da EFF, Mozilla, Google, Meta e molti altri.
Il progetto, , definisce un protocollo di riconoscimento (ACME, Automatic Certificate Management Environment) per il rilascio dei certificati, e consente di gestire il rinnovo in maniera automatica, potendo così usare con un ciclo di vita molto più breve (e quindi anche più sicuro), oltre a fornire la possibilità a chiunque di ottenere gratuitamente un certificato valido.
Il procedimento si compone di diverse modalità con le quali dimostrare la titolarità del nome a dominio per cui si richiede il rilascio di un certificato, riassumbili in sostanza nel rendere disponibile ad una opportuna interrogazione sul dominio stesso un segreto, fornito da Let’s Encrypt durante la richiesta.
Di queste vedremo come fare ad usare la più comune, che passa attraverso la pubblicazione via web (eseguita dal programma di gestione dei certificati) del suddetto segreto ad uno specifico indirizzo all’interno del dominio di cui si chiede la validazione.
Come installare e configurare
Considerando che il procedimento di rilascio dei certificati avviene con un protocollo standardizzato (nell’RFC 8555), esistono vari programmi che consentono di gestire certificati Let’s Encrypt e, ad oggi, anche diverse Certification Authority che possono fornire il servizio, ci limiteremo comunque a trattare l’uso del programma certbot fornito dal progetto originale, che è ormai disponibile come pacchetto per la gran parte delle distribuzioni Linux e che su Debian e derivate può essere installato immediatamente con:
apt-get install certbot
questo renderà disponibile il comando certbot che è quello che ci consentirà di gestire le richieste, gli aggiornamenti ed i rinnovi dei certificati forniti da Let’s Encrypt.
Sebbene certbot in alcuni casi consenta anche di gestire la configurazione automatica del server web, oltre le richieste ed i rinnovi dei certificati, per poterli usare, in generale questo non è possibile (vengono fatte alcune assunzioni relative alla configurazione, che non tutte le distribuzioni supportano, e che comunque sono abbastanza restrittive). E’ opportuno in questi casi ricorrere all’uso del sottocomando certonly, come indicato anche dal programma stesso quando rileva che l’automatismo è impossibile:
root@bookworm:~# certbot Saving debug log to /var/log/letsencrypt/letsencrypt.log Certbot doesn't know how to automatically configure the web server on this system. However, it can still get a certificate for you. Please run "certbot certonly" to do so. You'll need to manually configure your web server to use the resulting certificate.
L’uso del sottocomando certonly permette soltanto di ottenere un primo rilascio dei certificati, mentre la configurazione dei servizi dovrà essere eseguita manualmente.
Come abbiamo visto sopra, perchè Let’s Encrypt possa emettere un certificato, deve effettuare la validazione del dominio per cui questo viene richiesto, cosa che in questo caso viene effettuata con una richiesta via web al dominio stesso, e l’uso di un meccanismo di challenge and response basato sulla possibilità di scaricare un file dal quel dominio.
Questa procedura può essere realizzata direttamente dal programma se si usa dopo il sottocomando certonly l’opzione --standalone, in questo modo è certbot stesso che si incarica di far partire un servizio web sulla porta 80 su cui fornire il file, ma in tal caso occorre fermare Apache o qualunque altro server web che sia già attivo sul dominio.
Ecco perchè quando è già disponibile un server web in grado di fornire dei contenuti, lo si può utilizzare chiamando certbot con l’opzione --webroot (o -w) ed indicando come parametro per l’opzione la document root del dominio richiesto, all’interno della quale inserire quanto necessario alla risposta. Con questa opzione infatti il programma crea i file necessari alla validazione nella sottodirectory .well-known/acme-challenge/, che però deve poter essere servita a chi la richiede da fuori contattando il dominio per cui si richiede il rilascio del certificato. Occorre quindi verificare che la configurazione del server web renda accessibile questa directory, inoltre sarà necessaria una configurazione specifica che vedremo più avanti.
Nel caso in cui si avessero diversi siti con diverse document root il comando consente di specificarne una diversa per ciascun dominio in una singola esecuzione, ed in questo caso, tutte dovranno essere egualmente accessibili. In alternativa si potrà ripetere l’operazione in maniera separata per ciascun dominio.
Considerando che tutto questo spesso risulta scomodo e non è sempre applicabile, in alcuni casi è possibile usare come parametro di -w la stessa directory per tutti i domini, anche se questa non corrisponde alla loro document root, consentendo l’accesso via web alla stessa in maniera generica. Questa modalità è anche quella consigliata dal progetto, assumeremo pertanto che si siano applicate le opportune configurazioni, e che la directory utilizzata per ospitare i file della challenge and response di .well-known/acme-challenge, da indicare come parametro di -w, sia /var/www/letsencrypt/.
Per effettuare la validazione del dominio quando si usa certbot con la modalità --webroot viene fatto l’accesso da Let’s Encrypt e richiede che siano raggiungibili i contenuti corrispondenti ad una URL nella forma http://mio.dominio.it/.well-known/acme-challenge/XXXX, dove XXXX è il nome del file che verrà creato da certbot con il segreto richiesto da Let’s Encrypt questo deve essere raggiungibile e la cosa che dipende dalla configurazione del proprio webserver.
La modalità suggerita per consentire questa richiesta, nel caso di Nginx, è quella di creare un frammento di configurazione (ad esempio /etc/nginx/snippets/letsencrypt-acme-challenge.conf) contenente le direttive necessarie per consentire l’accesso:
location ^~ /.well-known/acme-challenge/ {
default_type "text/plain";
root /var/www/letsencrypt;
}
location = /.well-known/acme-challenge/ {
return 404;
}
queste istruzioni consentono di eseguire la validazione indicando come webroot la directory /var/www/letsencrypt, posto che il frammento di cui sopra sia stato incluso come prima direttiva nelle configurazioni dei virtual host coinvolti; sarà sufficiente inserirlo solo nelle direttive relative alle risposte sulla porta 80, considerando che la richiesta viene sempre fatta in chiaro. Un esempio di questa configurazione è il seguente:
server {
listen 80;
root /var/www/html;
server_name www.truelite.it;
include /etc/nginx/snippets/letsencrypt-acme-challenge.conf;
location / {
rewrite ^/(.*)$ https://www.truelite.it/$1 permanent;
}
}
che autorizza la richiesta fatta da Let’s Encrypt ma redirige su HTTPs tutte le altre.
Se al contrario si utilizza Apache come webserver, una configurazione analoga si può effettuare utilizzando il seguente frammento di configurazione (da scrivere ad esempio in /etc/apache2/conf-available/letsencrypt.conf) :
Alias /.well-known/acme-challenge/ /var/www/letsencrypt/.well-known/acme-challenge/
<Directory "/var/www/letsencrypt/.well-known/acme-challenge/">
Options None
AllowOverride None
ForceType text/plain
# avoid access to anything not resembling a challenge
RedirectMatch 404 "^(?!/\.well-known/acme-challenge/[\w-]{43}$)"
</Directory>
nel caso invece si voglia usare Debian o derivate, si può sfruttare la gestione dei frammenti di configurazione da usare in comune per tutti i virtual host (che consente di evitare l’inclusione esplicita in ciascuno di esse) inserendolo appunto sotto /etc/apache2/conf-available/ per poi abilitarlo con il comando a2enconf letsencrypt.
Nel caso si stiano usando altre distribuzioni sarebbe opportuno utilizzare una posizione adeguata e lo si includa nella configurazione generale di Apache.
La configurazione precedente è corretta, ma qualora si usasse Apache come reverse proxy per inoltrare altrove le richieste, invece che rispondere direttamente, occorrerà anche inserire una opportuna eccezione alle regole di proxy per la suddetta URL, in sostanza aggiungendo alla configurazione del virtual host una riga:
ProxyPass /.well-known/acme-challenge !
Infine, quando si forza la redirezione su SSL delle connessioni in chiaro, occorre evitare che questo avvenga anche per le richieste di Let’s Encrypt, pertanto occorrerà sostituire una eventuale direttiva di redirezione generica come la seguente:
<VirtualHost *:80>
ServerName ci.truelite.it
Redirect permanent / https://ci.truelite.it/
</VirtualHost>
con una più specifica che escluda la redirezione per la URL utilizzata da Let’s Encrypt:
<VirtualHost *:80>
ServerName ci.truelite.it
RedirectMatch 301 ^/((?!.well-known\/acme-challenge).*)$ https://ci.truelite.it/$1
</VirtualHost>
Qualora non si fossero usati virtual host separati (pratica sconsigliabile, che rende più complessa la gestione) e si volesse ottenere lo stesso risultato usando solo il virtual host di default di Apache (quello normalmente viene usato per tutte le richieste che non hanno un virtual host dedicato, e che risponde ad esempio quando si fa una richiesta sull’indirizzo IP invece che su un nome a dominio), non sarà più possibile utilizzare una direttiva semplice come la precedente RedirectMatch non essendo noto a priori il nome con cui si viene contattati e a cui si dovrebbero redirigere le richieste. In questa circostanza è comunque possibile utilizzare le Rewrite Rules per inserire una configurazione generica nella forma:
<VirtualHost *:80>
[...]
RewriteEngine On
RewriteCond %{HTTPS} off [OR]
RewriteRule ^/((?!.well-known\/acme-challenge).*)$ https://%{HTTP_HOST}/$1 [NC,R=301,L]
[...]
</VirtualHost>
(se si usano Debian o derivate questa andrà inserita in /etc/apache2/sites-available/000-default.conf).
I certificati e la loro gestione
Come procedere con la richiesta iniziale
Configurato il proprio server web, per consentire le risposte alle richieste di verifica di Let’s Encrypt, dopo aver indicato a certbot la directory da usare con l’opzione -w (nel caso dei precedenti esempi /var/www/letsencrypt) si dovrà aggiungere l’opzione -d per indicare il relativo dominio.
Generalmente, qualora si avessero delle document root diverse per domini diversi è comunque possibile eseguire l’operazione in un solo passo usando prima l’opzione -w per indicare la prima document root e poi l’opzione -d per indicare relativo dominio, e così via per i successivi. In questo caso il comando assume per ciascun dominio indicato con -d si stia usando la directory indicata con l’ultima occorrenza precedente di -w, ma come detto questa modalità d’uso, anche se possibile, è sconsigliata.
L’utilizzo di questa modalità è del tutto equivalente ad invocare più volte il comando indicando ogni volta un dominio diverso, ma si deve tener presente che in questo caso verrà creato un diverso certificato per ciascun dominio.
Generalmente però è possibile indicare più domini per uno stesso certificato, specificando più volte l’opzione -d per ciascuno di essi, e saranno inseriti nello stesso certificato come nomi alternativi. Tutto ciò consente di generare un solo certificato che copre più domini, rendendo la successiva configurazione dei servizi più semplice; ed è per questo che è sempre consigliato applicare le configurazioni illustrate, che consentono di usare una sola “_webroot_” per tutti i domini.
Per ottenere il certificato per il dominio mail.truelite.it il comando da usare sarà:
root@bookworm:~# certbot certonly --webroot -w /var/www/letsencrypt/ -d mail.truelite.it Saving debug log to /var/log/letsencrypt/letsencrypt.log Enter email address (used for urgent renewal and security notices) (Enter 'c' to cancel): info@truelite.it - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Please read the Terms of Service at https://letsencrypt.org/documents/LE-SA-v1.4-April-3-2024.pdf. You must agree in order to register with the ACME server. Do you agree? - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - (Y)es/(N)o: Y - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Would you be willing, once your first certificate is successfully issued, to share your email address with the Electronic Frontier Foundation, a founding partner of the Let's Encrypt project and the non-profit organization that develops Certbot? We'd like to send you email about our work encrypting the web, EFF news, campaigns, and ways to support digital freedom. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - (Y)es/(N)o: N Account registered. ...
Quando eseguiremo per la prima volta certbot per un nuovo dominio verrà richiesta una email di contatto (per comunicazione e recupero delle chiavi) che nell’esempio è info@truelite.it. Inoltre si dovranno si dovranno anche accettare le condizioni di Let’s Encrypt (con una risposta Y alla relativa domanda) ed indicare se si vuole o meno essere inseriti nella newsletter della EFF (nell’esempio si è risposto N).
Una volta usate le configurazioni descritte sul server che risponde per mail.truelite.it, il comando avrà successo e consentirà di ottenere un certificato per il solo dominio mail.truelite.it. Qualora si volesse ottenere un certificato valido per più domini, sarà sufficiente invocarlo ripetendo l’opzione -d per ciascun dominio, cioè nella forma:
# certbot certonly --webroot -w /var/www/letsencrypt/ -d mail.truelite.it -d smtp.truelite.it ...
Se la lista dei domini è molto lunga, la si può salvare in un file con un nome a dominio per riga, ad esempio domainlist.txt, e si potrà evitare di scriverli tutti esplicitamente usando le capacità della shell di Linux, invocando certbot come:
# certbot certonly --webroot -w /var/www/letsencrypt/ -d $(xargs < domainlist.txt | sed 's/ /,/g')
In entrambi i casi è importante sapere che verrà comunque generato un solo certificato, e si tenga presente che, a differenza di quanto consentono le Certification Authority tradizionali, non c’è nessun vincolo ad usare nomi alternativi facenti parte dello stesso dominio di base, si possono richiedere certificati anche per domini scorrelati, come wiki.fountainpen.it o www.softwarelibero.org.
Attenzione: I certificati rilasciati da Let’s Encrypt hanno una durata di tre mesi, e vengono salvati da certbot sotto /etc/letsencrypt/live in una directory corrispondente al nome a dominio indicato per primo nell’esecuzione del comando; nel caso del precedente esempio saranno sotto /etc/letsencrypt/live/mail.truelite.it/.
Come creare un nuovo certificato per un nuovo dominio
Ogni volta che si invoca il comando indicando un nuovo dominio, verrà creato un nuovo certificato, è pertanto sempre possibile avere certificati distinti per domini distinti. Questo significa che se dopo il precedente esempio per mail.truelite.it si ripete il comando per www.truelite.it come:
# certbot certonly --webroot -w /var/www/letsencrypt/ -d www.truelite.it Checking for new version... Requesting root privileges to run letsencrypt... /root/.local/share/letsencrypt/bin/letsencrypt certonly --webroot -w /var/www/letsencrypt/ -d www.truelite.it IMPORTANT NOTES: - Congratulations! Your certificate and chain have been saved at /etc/letsencrypt/live/www.truelite.it/fullchain.pem. Your cert will expire on 2024-05-07. To obtain a new version of the certificate in the future, simply run Let's Encrypt again. - If you like Let's Encrypt, please consider supporting our work by: Donating to ISRG / Let's Encrypt: https://letsencrypt.org/donate Donating to EFF: https://eff.org/donate-le
si otterrà un altro certificato, posto stavolta sotto /etc/letsencrypt/live/www.truelite.it.
Come accennato però avere certificati distinti complica la gestione, se infatti per un server web, grazie all’uso delle estensioni SNI (oggi utilizzabili con tutti i browser) è possibile avere certificati distinti per domini distinti pur ascoltando sempre sulla stessa porta, questo non è possibile per altri servizi (e quindi non è praticabile quando si forniscono accessi a servizi come la posta elettronica).
Come aggiungere un nuovo dominio ad un certificato già esistente
Considerando il livello di complessità di gestione nell’avere tanti certificati separati, certbot permette anche la possibilità di aggiungere un nuovo dominio ad un certificato esistente. In questo caso un primo passo è sempre quello si eseguire il comando certbot certiticates che stampa una lista dei certificati presenti, identificati con il nome a dominio principale con cui sono stati creati, e riportando per ciascuno di essi i nomi a dominio coperti ed il tempo di validità residua.
Se si desidera estendere un certificato esistente sarà sufficiente ripetere il richiamo di certbot aggiungendo il nuovo dominio con una ulteriore opzione -d, ad esempio una volta creato il precedente certificato per mail.truelite.it vi si potrà aggiungere l’ulteriore dominio posta.truelite.it con:
# certbot certonly --webroot -w /var/www/letsencrypt/ -d mail.truelite.it -d posta.truelite.it Saving debug log to /var/log/letsencrypt/letsencrypt.log ------------------------------------------------------------------------------- You have an existing certificate that contains a portion of the domains you requested (ref: /etc/letsencrypt/renewal/mail.truelite.it.conf) It contains these names: mail.truelite.it You requested these names for the new certificate: mail.truelite.it, posta.truelite.it. Do you want to expand and replace this existing certificate with the new certificate? ------------------------------------------------------------------------------- (E)xpand/(C)ancel: E Renewing an existing certificate ...
In questo caso verrà chiesto se espandere il certificato presente, e scegliendo il default (E) questo verrà aggiunto.
E’ importante tenere in considerazione che perché l’espansione funzioni, occorre indicare nella richiesta tutti i domini già presenti nel certificato corrente, altrimenti verrà creata una versione alternativa (e distinta) con solo quelli elencati.
Come rimuovere quei domini non più raggiungibili
Se per caso avete richiesto certificati con più nomi di dominio e alcuni di questi non fossero più verificabili (in quanto non più raggiungibili, o spostati su altra macchina) riceverete un errore in fase di rinnovo. È possibile ovviare al problema usando l’opzione --allow-subset-of-names per rinnovare un certificato valido solo per il sottoinsieme di domini ancora verificabili (posto che il dominio principale per cui lo si è richiesto resti valido) questo si fa con:
# certbot renew --allow-subset-of-names
tutti i domini che non sono verificati verranno dunque rimossi dal certificato, e i rinnovi successivi andranno a buon fine anche senza tale opzione (ovviamente per i domini rimasti presenti).
Ovviamente si deve avere cura di non lanciare questo comando in caso di mancata raggiungibilità anche solo temporanea di alcuni dei domini, in quanto questi verrebbero rimossi; è quindi opportuno non usare questa opzione in contesti automatizzati.
Come cancellare un certificato
Se invece si volesse eliminare un certificato, perché ad esempio il nome principale con cui è stato creato non è più in uso, occorre usare il comando cerbot delete e selezionare dalla lista, se sono più di uno, quello da cancellare. In alternativa se ne può indicare direttamente il nome con l’opzione --cert-name. E’ importante tenere in considerazione che questo cancellerà il certificato completamente, e se il certificato era stato creato per più domini, anche questi ultimi saranno rimossi, se alcuni di essi devono essere mantenuti, occorrerà creare un nuovo certificato.
Come modificare le informazioni di registrazione
Nel caso in cui si vogliano modificare le informazioni inserite in fase di registrazione, o si voglia cambiare l’email a cui il progetto invia gli avvisi in caso di mancato rinnovo e le eventuali comunicazioni sul servizio, il comando da usare è il seguente:
# certbot register --update-registration --email nuovaemail@truelite.it Saving debug log to /var/log/letsencrypt/letsencrypt.log ------------------------------------------------------------------------------- Would you be willing to share your email address with the Electronic Frontier Foundation, a founding partner of the Let's Encrypt project and the non-profit organization that develops Certbot? We'd like to send you email about EFF and our work to encrypt the web, protect its users and defend digital rights. ------------------------------------------------------------------------------- (Y)es/(N)o: y IMPORTANT NOTES: - Your e-mail address was updated to nuovaemail@truelite.it.
….continua
La redazione