UsareLetsEncrypt » Cronologia » Versione 41
Versione 40 (Simone Piccardi, 09-05-2024 14:09) → Versione 41/47 (Simone Piccardi, 09-05-2024 17:49)
h1. Usare Let's Encrypt
{{>toc}}
h2. Panoramica
L'uso dei certificati SSL, necessario per l'accesso in HTTPs ai siti web, è ormai divenuto uno dei passi fondamentali nella gestione della sicurezza della rete, in quanto consente sia di cifrare le comunicazioni, evitando una possibile intercettazione dei dati, che di identificare l'autenticità del corrispondente, garantendone opportunamente l'identità. A lungo però il loro impiego era strettamente legato all'acquisto degli stessi presso una Certification Authority, a titolo talvolta anche molto oneroso, ed alla necessità di reinstallazione periodica degli stessi.
Il progetto di "Let's Encrypt":https://letsencrypt.org/ che ha portato alla una nuova Certification Authority libera e gratuita promossa da "EFF":https://www.eff.org, "Mozilla":https://www.mozilla.org, Google, Meta e molti altri nacque per poter mettere a disposizione a costo zero e rendere più semplice e fruibile una tecnologia che è fondamentale per la sicurezza di Internet. In particolare il progetto, oltre a fornire la possibilità a chiunque di ottenere gratuitamente un certificato valido, 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) degli stessi.
In sostanza il procedimento prevede diverse una modailità con cui dimostrare di essere titolari del nome a dominio per cui si richiede il rilascio di un certificato, riassumbili in sostanza nel redere disponibile ad una opportuna interrogazione sul dominio stesso un segreto, fornito da "Let's Encrypt":https://letsencrypt.org/ durante la richiesta. Di queste vedremo come usare la più comune, che passa attraverso la pubblicazione (eseguita dal programma di gestione dei certificati) del suddetto segreto via web ad uno specifico indirizzo all'interno del dominio di cui si chede la validazione.
h2. Installazione e configurazione iniziale
Dato che il procedimento di rilascio dei certificati avviene attraverso uno protocollo standardizzato (nell'"RFC 8555":https://datatracker.ietf.org/doc/html/rfc8555), esistono diversi programmi che consentono di gestire certificati "Let's Encrypt":https://letsencrypt.org/ ed 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:
<pre>
apt-get install certbot
</pre>
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":https://letsencrypt.org/.
Benché in alcuni casi @certbot@ consenta anche di gestire, oltre le richieste ed i rinnovi dei certificati, anche le configurazione automatica del server web 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). Per questo normalmente si deve ricorrere all'uso del sottocomando @certonly@, come del resto viene indicato anche dal programma stesso se questi rileva che l'automatismo è impossibile:
<pre>
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.
</pre>
L'uso del sottocomando @certonly@ consente soltanto di ottenere un primo rilascio dei certificati, la configurazione dei servizi dovrà essere eseguita manualmente. Come accennato per emettere un certificato "Let's Encrypt":https://letsencrypt.org/ deve effettuare la validazione del dominio per cui questo viene richiesto, cosa che 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 comando @certonly@ l'opzione @--standalone@, in tal caso è @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 webserver che sia già attivo sul dominio.
Per questo quando è già disponibile un server web che è in grado di servire 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 pertanto verificare che la configurazione del server web renda accessibile questa directory, ed è in genere necessaria una configurazione specifica che vedremo a breve.
Se si hanno diversi siti con diverse _document root_ il comando consente di specificarne in una singola esecuzione una diversa per ciascun dominio, ed in questo caso In questo caso tutte dovranno essere egualmente accessibili. Alternativamente si potrà ripetere l'operazione separatamente per ciascun dominio. Siccome tutto questo risulta scomodo e non è sempre applicabile, è 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 è anche la modalità 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/@.
L'accesso che viene fatto da "Let's Encrypt":https://letsencrypt.org/ per effettuare la validazione del dominio quando si usa @certbot@ con la modalità @--webroot@ richiede che siano raggiungibili i contenuti corrispondenti ad una URL nella forma @http://mio.dominio.it/.well-known/acme-challenge/XXXX@, @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":https://letsencrypt.org/; questo deve essere raggiungibile e la cosa che dipende dipendee dalla configurazione del proprio webserver.
Nel caso di Nginx la modalità suggerita per consentire questa richiesta è quella creare un frammento di configurazione (ad esempio (nel caso @/etc/nginx/snippets/letsencrypt-acme-challenge.conf@) contenente le direttive necessarie per consentire l'accesso:
<pre>
location ^~ /.well-known/acme-challenge/ {
default_type "text/plain";
root /var/www/letsencrypt;
}
location = /.well-known/acme-challenge/ {
return 404;
}
</pre>
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; basterà coinvolti (basta inserirlo solo nelle direttive relative alle risposte sulla porta 80, dato che la richiesta viene sempre fatta in chiaro. Un esempio di questa configurazione è il seguente: chiaro), con qualcosa del tipo:
<pre>
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;
}
}
</pre>
che autorizza la richiesta fatta da "Let's Encrypt":https://letsencrypt.org/ ma redirige su HTTPs tutte le altre.
Se invece si utilizza come webserver Una analoga configurazione per Apache una configurazione analoga si può effettuare utilizzando il seguente frammento di configurazione (da scrivere ad esempio in @/etc/apache2/conf-available/letsencrypt.conf@) : configurazione:
<pre>
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>
</pre>
nel caso si usino Debian o derivate lo si può sfruttare la gestione dei frammenti di configurazione da usare inserire 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/@ ed abilitare con @a2enconf@; per poi abilitarlo con il comando @a2enconf letsencrypt@. Nel caso si usino altre distribuzioni si utilizzi una posizione adeguata e lo si includa nella configurazione generale di Apache.
La precedente configurazione è corretta nella configurazione ordinaria, ma Si tenga presente però che qualora si usi 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 si dovrà aggiungere alla configurazione del virtual host una riga:
<pre>
ProxyPass /.well-known/acme-challenge !
</pre>
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:
<pre>
<VirtualHost *:80>
ServerName ci.truelite.it
Redirect permanent / https://ci.truelite.it/
</VirtualHost>
</pre>
con una più specifica che escluda la redirezione per la URL utilizzata da Let's Encrypt:
<pre>
<VirtualHost *:80>
ServerName ci.truelite.it
RedirectMatch 301 ^/((?!.well-known\/acme-challenge).*)$ https://ci.truelite.it/$1
</VirtualHost>
</pre>
Se non si sono usati virtual host separati (pratica sconsigliabile, che rende più complessa la gestione) e si vuole ottenere lo stesso risultato usando solo con il virtual host virtualhost 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 è più possibile utilizzare una direttiva semplice come la precedente @RedirectMatch@ perché in quanto in tal caso non è noto a priori il nome l'hostname con cui si viene contattati e a cui contattati, ma si dovrebbero redirigere le richieste. In tal caso è comunque possibile utilizzare le Rewrite Rules per può inserire una configurazione regola generica nella forma: in @/etc/apache2/sites-available/000-default.conf@ con:
<pre>
<VirtualHost *:80>
[...]
RewriteEngine On
RewriteCond %{HTTPS} off [OR]
RewriteRule ^/((?!.well-known\/acme-challenge).*)$ https://%{HTTP_HOST}/$1 [NC,R=301,L]
[...]
</VirtualHost>
</pre>
(se si usano Debian o derivate questa andrà inserita in @/etc/apache2/sites-available/000-default.conf@).
h2. La gestione dei certificati
h3. La richiesta iniziale
Una volta che si sia configurato il proprio server web webserver per consentire le risposte alle richieste di verifica di "Let's Encrypt":https://letsencrypt.org/, una volta indicata a @certbot@ Encrypt":https://letsencrypt.org/ assicurandosi che la directory da usare indicata con l'opzione @-w@ (nel caso consente la corretta creazione dei precedenti esempi @/var/www/letsencrypt) contenuti per la risposta, si dovrà aggiungere l'opzione @-d@ per indicare relativo dominio. In generale, qualora Qualora si abbiano delle _document root_ diverse per domini diversi si può comunque 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. Il comando infatti 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, @-w@.
Questo è sconsigliata.
Essa infatti è del tutto equivalente ad invocare più volte il comando indicando ogni volta tutte le volte un dominio diverso, ma si deve tener presente che in questo caso verrà creato un diverso certificato per ciascun dominio. In generale però è possibile indicare più domini per uno stesso certificato, specificando più volte l'opzione @-d@ per ciascuno di essi, e questi saranno inseriti nello stesso certificato come nomi alternativi. Questo consente di generare un solo certificato che copre copra più domini, cosa che rende la successiva configurazione dei servizi più semplice; ed è per questo che è sempre consigliato opportuno applicare le configurazioni illustrate, illustrate che consentono di usare una sola "_webroot_" per tutti i domini.
Se pertanto si vuole ottenere il certificato per il dominio @mail.truelite.it@ il comando da usare sarà:
<pre>
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.
...
</pre>
La prima volta che si esegue @certbot@ per un nuovo dominio verrà richiesta una email di contatto (per comunicazione e recupero delle chiavi) che nell'esempio è info@truelite.it. La e la prima volta che lo si esegue su una macchina si dovranno anche accettare le condizioni di "Let's Encrypt":https://letsencrypt.org/ (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).
Posto Let's Encrypt.
Il comando illustrato, posto che si siano 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
Come accennato se un certificato deve essere valido per più domini, sarà sufficiente invocarlo ripetendo l'opzione @-d@ si possono salvare in un file, nell'esempio @valid_hosts.txt@ (un dominio per ciascun dominio, cioè nella forma: riga) ed usare il comando:
<pre>
# certbot certonly --webroot -w /var/www/letsencrypt/ -d mail.truelite.it -d smtp.truelite.it ... $(xargs < domainlist.txt | sed 's/ /,/g')
</pre>
Quando la lista dei domini è molto lunga, la oppure lo si può salvare in un file con un nome a dominio per riga, ad esempio @valid_hosts.txt@, e si potrà evitare di scriverli tutti invocare esplicitamente usando le capacità della shell di Linux, invocando @certbot@ come:
ripetendo l'opzione @-d@ nella forma:
<pre>
# certbot certonly --webroot -w /var/www/letsencrypt/ -d $(xargs < domainlist.txt | sed 's/ /,/g') mail.truelite.it -d smtp.truelite.it ...
</pre>
In entrambi i casi 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.
I certificati rilasciati da "Let's Encrypt":https://letsencrypt.org/ hanno una durata durano tre mesi, e vengono salvati da @certbot@ creati sotto @/etc/letsencrypt/live@. @/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 allora @/etc/letsencrypt/live/mail.truelite.it/@.
h3. Creazione Aggiunta di un nuovo certificato per un nuovo dominio nuovi certificati distinti
Come accennato ogni volta che Se si invoca il comando indicando un nuovo dominio, verrà creato un nuovo certificato, è pertanto sempre possibile utilizza SNI (oggi utilizzabile con tutti i browser, ma non utilizzabile con servizi diversi dal web), e si vogliono avere certificati distinti per domini distinti. Questo significa che se dopo distinti, basterà ripetere il precedente esempio comando per @mail.truelite.it@ ciascuno di essi. Ogni invocazione successiva con nomi a dominio diversi si ripete il comando per @www.truelite.it@ come: limiterà a creare i certificati richiesti in maniera distinta, pertanto con qualcosa del tipo:
<pre>
# 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. 2016-07-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
</pre>
si Si otterrà un altro certificato, posto stavolta sotto @/etc/letsencrypt/live/www.truelite.it@. Come accennato però avere
Con lo script @listlecert.sh@ allegato si può stampare un elenco dei certificati distinti complica la gestione, se infatti per creati, e dei domini da essi coperti, ma le versioni correnti di @certbot@ supportano l'uso del comando @certbot certificates@ che stampa un server web, grazie all'uso delle estensioni SNI (oggi utilizzabili elenco con tutti i browser) è possibile avere dettagli comprese le data di scadenza ed i pathname dei file.
h2. Gestione dei certificati distinti per domini distinti pur ascoltando sempre sulla stessa porta, questo non è possibile per altri servizi (e quindi non è praticabile quando si forniscano accessi a servizi come la posta elettronica).
h3. Aggiunta di un nuovo dominio ad un certificato esistente
Data la complessità di gestione di avere tanti certificati separati, @certbot@ supporta anche la possibilità di Qualora si voglia 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.
Per estendere un certificato esistente basterà ripetere l'invocazione di @certbot@ del comando 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: esempio:
<pre>
# certbot certonly --webroot -w /var/www/letsencrypt/ -d mail.truelite.it -d posta.truelite.it rainloop.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. rainloop.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
...
</pre>
In questo caso verrà chiesto se espandere il certificato presente, e scegliendo il default (E) questo verrà aggiunto. Si tenga presente 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.
h3. Rimozione di domini certificati non più raggiungibili
Nel caso si siano richiesti certificati con più nomi di dominio e alcuni di questi non fossero più verificabili (in quanto non più raggiungibili, o spostati su altra macchina) si riceverà 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: valido):
<pre>
# certbot renew --allow-subset-of-names
</pre>
tutti i domini non verificati verranno quindi rimossi dal certificato, e i rinnovi successivi andranno a buon fine anche senza tale opzione (ovviemente per i domini rimasti presenti). opzione.
Naturalmente Ovviamente, si deve avere cura di non lanciare questo comando in caso di non raggiungibilità _temporanea_ di alcuni dei domini, perché questi verrebbero rimossi; ed è quindi opportuno non usare questa opzione in contesti automatizzati.
h3. Cancellazione di un certificato
Qualora si voglia eliminare un certificato, ad esempio perché il nome principale con cui lo si è creato non è più in uso, occorre usare il comando @cerbot delete@ e selezionare dalla lista, lista se sono più di uno, quello da cancellare. Alternativamente se ne può o eventualmente indicare direttamente il nome con l'opzione @--cert-name@. Si tenga presente che questo cancellerà il certificato completamente, e se questo era stato creato per più domini, anche questi verranno rimossi, se alcuni di essi devono essere mantenuti, occorrerà creare un nuovo certificato. rimossi.
h3. Modifica delle informazioni di registrazione
Qualora si vogliano modificare le informazioni inserite in fase di registrazione, in particolare qualora 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:
<pre>
# 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.
</pre>
h2. Alcuni esempi Esempi di configurazione dei servizi
Abbiamo visto finora come farsi rilasciare un certificato da "Let's Encrypt":https://letsencrypt.org/; il passo successivo è quello di configurare i vari servizi per utilizzarlo.
Una volta completata la validazione del proprio dominio dominio, nella directory di installazione dei certificati (@/etc/letsencrypt/live/mio.dominio.it@) vengono sempre creati i seguenti file:
| *file* | *contenuto* |
|cert.pem | cerficato |
|chain.pem | catena dalla CA |
|fullchain.pem | catena + certificato|
|privkey.pem | chiave privata |
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":https://letsencrypt.org/, appunto). Infine che è il certificato del proprio dominio, mentre @fullchain.pem@ è l'insieme completo del certificato e di tutta della catena. Infine la catena di validazione.
chiave privata è in @privkey.pem@.
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 link simbolici, in quanto @letsencrypt@ aggiornerà automaticamente gli stessi 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é "Let's Encrypt":https://letsencrypt.org/ prevede una procedura di aggiornamento automatico, rinnovo automatico che consentirà i cambiare i file sottostanti con le nuove versioni facendo comunque sempre riferimenti a questi nomi in modo da non dover toccare le configurazioni. vedremo più avanti.
h3. La Apache
I file @cert.pem@ e @chain.pem@ sono quelli che si usano nella configurazione di Apache
Fino Apache, che 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 li vuole separati, ad esempio con 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: precedenza la configurazione utilizzata è:
<pre>
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
</pre>
Con se invece si usa 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), deprecata, e si deve invece passare ad usare il file @fullchain.pem@ che è l'insieme del certificato e di tutta la sua catena di firma con una configurazione del tipo:
<pre>
SSLCertificateFile /etc/letsencrypt/live/mail.truelite.it/fullchain.pem
SSLCertificateKeyFile /etc/letsencrypt/live/mail.truelite.it/privkey.pem
</pre>
Quando si usano gli stessi certificati per più virtual host
h3. Postfix
Il file @fullchain.pem@ è anche quello che viene richiesto anche dal server SMTP da Postfix, Dovecot e Nginx. Per 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:
<pre>
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
</pre>
h3. Dovecot
Anche il server POP/IMAP mentre per Dovecot richiede che si indichi l'insieme del certificato e della catena di validazione di @fullchain.pem@; dovanno utilizzare in questo caso una configurazione possibile è quella di inserire in @/etc/dovecot/conf.d/90-user.conf@ le direttive:
<pre>
ssl = yes
ssl_cert = </etc/letsencrypt/live/mail.truelite.it/fullchain.pem
ssl_key = </etc/letsencrypt/live/mail.truelite.it/privkey.pem
</pre>
h3. Nginx
Qualora si usi invece ed infine per 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:
<pre>
server {
listen 443 ssl;
server_name mail.truelite.it; bd.truelite.it;
root /var/www/html;
ssl_certificate /etc/letsencrypt/live/mail.truelite.it/fullchain.pem; /etc/letsencrypt/live/bd.truelite.it/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/mail.truelite.it/privkey.pem; /etc/letsencrypt/live/bd.truelite.it/privkey.pem;
...
</pre>
h3. ejabberd
Infine per configurare un server jabber/XMMP come ejabberd (server jabber) occorre una modalità ancora diversa, il programma infatti richiede generare dai file di fornire chiave e certificato in Let's Encrypt un unico file contenente in testa la chiave privata (non (il programma 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:
<pre>
cat /etc/letsencrypt/live/jabber.truelite.it/privkey.pem \
/etc/letsencrypt/live/jabber.truelite.it/fullchain.pem > ejabberd.pem
</pre>
ed inserire in @/etc/ejabberd/ejabberd.yml@ le righe: In tutti i casi deve essere effettuato un riavvio completo dei servizi.
<pre>
certfiles:
- "/etc/ejabberd/ejabberd.pem"
</pre>
h2. Il rinnovo dei certificati
A differenze di quanto accade con le Certification Authority tradizionali, che normalmentne forniscono certificati di durata annuale (o più lunga) la La scadenza dei certificati emessi da "Let's Encrypt":https://letsencrypt.org/ Let's Encrypt è di soli tre mesi. La scelta è voluta, per ridurre l'impatto di una compromissione, mesi, ma come accennato all'inizio ul grande vantaggio di "Let's Encrypt":https://letsencrypt.org/ è che una volta ottenuti questi possono essere facilmente rinnovati molto facilmente con @certbot@ utilizzando il sottocomando @renew@.
Il comando può essere eseguito @renew@, in qualunque momento, e quando rileva un certificato prossimo alla scadenza provvederà ad eseguire il rinnovo, per cui particolare se ad esempop si esegue il comando dopo averli ottenuti si otterrà qualcosa del tipo:
<pre>
# 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.
</pre>
la cosa si può automatizzare inserendo banalmente nel cron il comando, ad esempio creando il file @/etc/cron.d/letencrypt@ con il contenuto:
<pre>
00 23 * * 6 root certbot renew
</pre>
oppure usare lo script @le-renew@ allegato, che esegue anche il riavvio dei servizi quando rileva un aggiornamento dei certificati, avendo cura di adattarlo alle proprie esigenze; in tal caso il suggerimento è di inserirlo fra quelli di @/etc/cron.weekly@.
Su Debian e derivate, nelle 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 usare lo script allegato, ma si tenga conto che questo comando, da solo, non esegue altra azione che il rinnovo.
E' comunque possibile inserire degli _hook_ da eseguire in caso di rinnovo. Questo si può fare esplicitamente nel comando, con @--renew-hook@ nelle vecchie versioni o con i vari @--pre-hook@, @--post-hook@ e @--deploy-hook@ (quest'ultimo equivalente di @--renew-hook@) nelle versioni più recenti. Per queste ultime si possono anche inserire gli script da eseguire sotto @/etc/letsencrypt/renewal-hooks@ nelle corrispondenti directory @deploy@, @pre@ e @post@. In tal caso gli script vengono eseguiti una volta per ogni certificato rinnovato, e si hanno le variabili @RENEWED_LINEAGE@ per indicare il certificato rinnovato e @RENEWED_DOMAINS@ per l'elenco dei domini (separto da spazi) in esso contenuti.