Progetto

Generale

Profilo

UsareLetsEncrypt » Cronologia » Versione 45

Simone Piccardi, 13-05-2024 14:46

1 9 Simone Piccardi
h1. Usare Let's Encrypt
2 1 Simone Piccardi
3 14 Elena Grandi
{{>toc}}
4
5 37 Simone Piccardi
h2. Panoramica
6 14 Elena Grandi
7 37 Simone Piccardi
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. 
8 36 Simone Piccardi
9 37 Simone Piccardi
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.
10 1 Simone Piccardi
11 43 Simone Piccardi
In sostanza il procedimento prevede diverse una modalità con cui dimostrare di essere titolari del nome a dominio per cui si richiede il rilascio di un certificato, riassumibili in sostanza nel rendere 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 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.
12 1 Simone Piccardi
13 39 Simone Piccardi
h2. Installazione e configurazione iniziale
14 1 Simone Piccardi
15 37 Simone Piccardi
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:
16 22 Simone Piccardi
17 1 Simone Piccardi
<pre>
18 16 Elena Grandi
apt-get install certbot
19 1 Simone Piccardi
</pre>
20 24 Simone Piccardi
21 38 Simone Piccardi
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/.
22 1 Simone Piccardi
23 44 Simone Piccardi
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 quando rileva che l'automatismo è impossibile:
24 1 Simone Piccardi
25 38 Simone Piccardi
<pre>
26 1 Simone Piccardi
root@bookworm:~# certbot
27
Saving debug log to /var/log/letsencrypt/letsencrypt.log
28
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.
29
</pre>
30
31 44 Simone Piccardi
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 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.
32 1 Simone Piccardi
33 44 Simone Piccardi
Questa procedura può essere realizzata direttamente dal programma se si usa dopo il sottocomando @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 server web che sia già attivo sul dominio. 
34 1 Simone Piccardi
35 39 Simone Piccardi
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.
36 1 Simone Piccardi
37 39 Simone Piccardi
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/@.
38 1 Simone Piccardi
39 41 Simone Piccardi
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@, 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 dalla configurazione del proprio webserver.
40 1 Simone Piccardi
41 41 Simone Piccardi
Nel caso di Nginx la modalità suggerita per consentire questa richiesta è quella creare un frammento di configurazione (ad esempio @/etc/nginx/snippets/letsencrypt-acme-challenge.conf@) contenente le direttive necessarie per consentire l'accesso: 
42 1 Simone Piccardi
43 39 Simone Piccardi
<pre>
44
location ^~ /.well-known/acme-challenge/ {
45
    default_type "text/plain";
46
    root         /var/www/letsencrypt;
47
}
48
location = /.well-known/acme-challenge/ {
49
    return 404;
50
}
51
</pre>
52
53 41 Simone Piccardi
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à 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:
54 39 Simone Piccardi
55
<pre>
56
server {
57
        listen 80;
58
        root /var/www/html;
59
        server_name www.truelite.it;
60
        include /etc/nginx/snippets/letsencrypt-acme-challenge.conf;
61
        location / {
62
            rewrite ^/(.*)$ https://www.truelite.it/$1 permanent;
63
        }       
64
}
65 1 Simone Piccardi
</pre>
66
67 41 Simone Piccardi
che autorizza la richiesta fatta da  "Let's Encrypt":https://letsencrypt.org/ ma redirige su HTTPs tutte le altre.
68 39 Simone Piccardi
69 41 Simone Piccardi
Se invece si utilizza come webserver Apache una configurazione analoga si può effettuare utilizzando il seguente frammento di configurazione (da scrivere ad esempio in @/etc/apache2/conf-available/letsencrypt.conf@) :
70
71 39 Simone Piccardi
<pre>
72
Alias /.well-known/acme-challenge/ /var/www/letsencrypt/.well-known/acme-challenge/
73
<Directory "/var/www/letsencrypt/.well-known/acme-challenge/">
74
    Options None
75
    AllowOverride None
76
    ForceType text/plain
77 1 Simone Piccardi
    # avoid access to anything not resembling a challenge
78
    RedirectMatch 404 "^(?!/\.well-known/acme-challenge/[\w-]{43}$)"
79 39 Simone Piccardi
</Directory>
80
</pre>
81
82 41 Simone Piccardi
nel caso si usino 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 usino altre distribuzioni si utilizzi una posizione adeguata e lo si includa nella configurazione generale di Apache.
83 39 Simone Piccardi
84 41 Simone Piccardi
La precedente configurazione è corretta nella configurazione ordinaria, ma 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:
85 39 Simone Piccardi
86
<pre>
87
ProxyPass /.well-known/acme-challenge !
88
</pre>
89
90
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:
91
92
<pre>
93
<VirtualHost *:80>
94
    ServerName ci.truelite.it
95
    Redirect permanent / https://ci.truelite.it/
96
</VirtualHost>
97
</pre>
98
99
con una più specifica che escluda la redirezione per la URL utilizzata da Let's Encrypt:
100
101 1 Simone Piccardi
<pre>
102 39 Simone Piccardi
<VirtualHost *:80>
103
    ServerName ci.truelite.it
104
    RedirectMatch 301 ^/((?!.well-known\/acme-challenge).*)$ https://ci.truelite.it/$1
105
</VirtualHost>
106
</pre>
107
108 41 Simone Piccardi
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 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 è più possibile utilizzare una direttiva semplice come la precedente @RedirectMatch@ perché in tal caso non è noto a priori il nome con cui si viene contattati e a cui si dovrebbero redirigere le richieste. In tal caso è comunque possibile utilizzare le Rewrite Rules per inserire una configurazione generica nella forma:
109 39 Simone Piccardi
110
<pre>
111
<VirtualHost *:80>
112
        [...]
113 1 Simone Piccardi
        RewriteEngine On
114 39 Simone Piccardi
        RewriteCond %{HTTPS} off [OR] 
115
        RewriteRule ^/((?!.well-known\/acme-challenge).*)$ https://%{HTTP_HOST}/$1 [NC,R=301,L]
116
        [...]
117
</VirtualHost>
118 1 Simone Piccardi
</pre>
119
120 41 Simone Piccardi
(se si usano Debian o derivate questa andrà inserita in @/etc/apache2/sites-available/000-default.conf@).
121 39 Simone Piccardi
122
h2. La gestione dei certificati
123
124
h3. La richiesta iniziale
125
126 45 Simone Piccardi
Una volta che si sia configurato il proprio server web per consentire le risposte alle richieste di verifica di "Let's Encrypt":https://letsencrypt.org/, una volta indicata 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. In generale, 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, è sconsigliata.
127 39 Simone Piccardi
128 41 Simone Piccardi
Essa infatti è 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. 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 più domini, cosa che rende 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. 
129 39 Simone Piccardi
130 23 Simone Piccardi
Se pertanto si vuole ottenere il certificato per il dominio @mail.truelite.it@ il comando da usare sarà:
131 38 Simone Piccardi
132
<pre>
133
root@bookworm:~# certbot certonly --webroot -w /var/www/letsencrypt/ -d mail.truelite.it
134
Saving debug log to /var/log/letsencrypt/letsencrypt.log
135 24 Simone Piccardi
Enter email address (used for urgent renewal and security notices)
136 38 Simone Piccardi
 (Enter 'c' to cancel): info@truelite.it
137
138
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
139
Please read the Terms of Service at
140
https://letsencrypt.org/documents/LE-SA-v1.4-April-3-2024.pdf. You must agree in
141
order to register with the ACME server. Do you agree?
142
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
143 1 Simone Piccardi
(Y)es/(N)o: Y
144 38 Simone Piccardi
145 1 Simone Piccardi
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
146
Would you be willing, once your first certificate is successfully issued, to
147
share your email address with the Electronic Frontier Foundation, a founding
148
partner of the Let's Encrypt project and the non-profit organization that
149 38 Simone Piccardi
develops Certbot? We'd like to send you email about our work encrypting the web,
150 1 Simone Piccardi
EFF news, campaigns, and ways to support digital freedom.
151 38 Simone Piccardi
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
152 1 Simone Piccardi
(Y)es/(N)o: N
153 38 Simone Piccardi
Account registered.
154 1 Simone Piccardi
...
155
</pre>
156
157 41 Simone Piccardi
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 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).  
158 39 Simone Piccardi
159 41 Simone Piccardi
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 un certificato valido per più domini, sarà sufficiente invocarlo ripetendo l'opzione @-d@ per ciascun dominio, cioè nella forma:
160 1 Simone Piccardi
161 39 Simone Piccardi
<pre>
162 41 Simone Piccardi
# certbot certonly --webroot -w /var/www/letsencrypt/ -d mail.truelite.it -d smtp.truelite.it ...
163 35 Simone Piccardi
</pre>
164 1 Simone Piccardi
165 45 Simone Piccardi
Quando 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: 
166 40 Simone Piccardi
167 19 Simone Piccardi
<pre>
168 41 Simone Piccardi
# certbot certonly --webroot -w /var/www/letsencrypt/ -d $(xargs < domainlist.txt | sed 's/ /,/g')
169 1 Simone Piccardi
</pre>
170 19 Simone Piccardi
171 41 Simone Piccardi
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.
172 39 Simone Piccardi
173 41 Simone Piccardi
I certificati rilasciati da "Let's Encrypt":https://letsencrypt.org/ hanno una durata 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 allora @/etc/letsencrypt/live/mail.truelite.it/@.
174 1 Simone Piccardi
175
176 41 Simone Piccardi
h3. Creazione di un nuovo certificato per un nuovo dominio
177 1 Simone Piccardi
178 41 Simone Piccardi
Come accennato 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:
179
180 14 Elena Grandi
<pre>
181
# certbot certonly --webroot -w /var/www/letsencrypt/ -d www.truelite.it 
182
Checking for new version...
183
Requesting root privileges to run letsencrypt...
184 1 Simone Piccardi
   /root/.local/share/letsencrypt/bin/letsencrypt certonly --webroot -w /var/www/letsencrypt/ -d www.truelite.it
185
186
IMPORTANT NOTES:
187
 - Congratulations! Your certificate and chain have been saved at
188
   /etc/letsencrypt/live/www.truelite.it/fullchain.pem. Your cert will
189 41 Simone Piccardi
   expire on 2024-05-07. To obtain a new version of the certificate in
190 1 Simone Piccardi
   the future, simply run Let's Encrypt again.
191
 - If you like Let's Encrypt, please consider supporting our work by:
192
193
   Donating to ISRG / Let's Encrypt:   https://letsencrypt.org/donate
194 9 Simone Piccardi
   Donating to EFF:                    https://eff.org/donate-le
195 1 Simone Piccardi
</pre>
196
197 41 Simone Piccardi
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 forniscano accessi a servizi come la posta elettronica).
198 1 Simone Piccardi
199
h3. Aggiunta di un nuovo dominio ad un certificato esistente
200
201 41 Simone Piccardi
Data la complessità di gestione di avere tanti certificati separati, @certbot@ supporta 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.
202 1 Simone Piccardi
203 41 Simone Piccardi
Per estendere un certificato esistente basterà ripetere l'invocazione 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:
204
205 1 Simone Piccardi
<pre>
206 41 Simone Piccardi
# certbot certonly --webroot -w /var/www/letsencrypt/ -d mail.truelite.it -d posta.truelite.it
207 1 Simone Piccardi
Saving debug log to /var/log/letsencrypt/letsencrypt.log
208 14 Elena Grandi
209
-------------------------------------------------------------------------------
210 1 Simone Piccardi
You have an existing certificate that contains a portion of the domains you
211
requested (ref: /etc/letsencrypt/renewal/mail.truelite.it.conf)
212 32 Simone Piccardi
213 11 Simone Piccardi
It contains these names: mail.truelite.it
214
215 1 Simone Piccardi
You requested these names for the new certificate: mail.truelite.it,
216 41 Simone Piccardi
posta.truelite.it.
217 1 Simone Piccardi
218
Do you want to expand and replace this existing certificate with the new
219
certificate?
220
-------------------------------------------------------------------------------
221
(E)xpand/(C)ancel: E
222
Renewing an existing certificate
223 6 Simone Piccardi
...
224
</pre>
225 33 Simone Piccardi
226 32 Simone Piccardi
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.
227
228 41 Simone Piccardi
h3. Rimozione di domini non più raggiungibili
229 1 Simone Piccardi
230 41 Simone Piccardi
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:
231 1 Simone Piccardi
232
<pre>
233
# certbot renew --allow-subset-of-names
234 17 Simone Piccardi
</pre>
235
236 41 Simone Piccardi
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).
237 26 Simone Piccardi
238 41 Simone Piccardi
Naturalmente si deve avere cura di non lanciare questo comando in caso di non raggiungibilità _temporanea_ di alcuni dei domini, perché questi verrebbero rimossi;  è quindi opportuno non usare questa opzione in contesti automatizzati.
239 1 Simone Piccardi
240
h3. Cancellazione di un certificato
241
242 41 Simone Piccardi
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, se sono più di uno, quello da cancellare. Alternativamente se ne può 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.
243 1 Simone Piccardi
244 17 Simone Piccardi
h3. Modifica delle informazioni di registrazione
245
246
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:
247 26 Simone Piccardi
248 17 Simone Piccardi
<pre>
249
# certbot register --update-registration --email nuovaemail@truelite.it 
250 1 Simone Piccardi
Saving debug log to /var/log/letsencrypt/letsencrypt.log
251 17 Simone Piccardi
252
-------------------------------------------------------------------------------
253 27 Simone Piccardi
Would you be willing to share your email address with the Electronic Frontier
254
Foundation, a founding partner of the Let's Encrypt project and the non-profit
255
organization that develops Certbot? We'd like to send you email about EFF and
256
our work to encrypt the web, protect its users and defend digital rights.
257 1 Simone Piccardi
-------------------------------------------------------------------------------
258
(Y)es/(N)o: y
259 27 Simone Piccardi
260
IMPORTANT NOTES:
261 1 Simone Piccardi
 - Your e-mail address was updated to nuovaemail@truelite.it.
262
</pre>
263 27 Simone Piccardi
264
265 41 Simone Piccardi
h2. Alcuni esempi di configurazione dei servizi
266 1 Simone Piccardi
267 41 Simone Piccardi
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. 
268
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:
269 1 Simone Piccardi
270 4 Simone Piccardi
| *file*    | *contenuto* |
271 1 Simone Piccardi
|cert.pem      | cerficato |
272
|chain.pem     | catena dalla CA |
273
|fullchain.pem | catena + certificato|
274
|privkey.pem   | chiave privata |
275
276 41 Simone Piccardi
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 
277
@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 @fullchain.pem@ è l'insieme completo del certificato e di tutta la catena di validazione. 
278 14 Elena Grandi
279 41 Simone Piccardi
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é "Let's Encrypt":https://letsencrypt.org/ prevede una procedura di aggiornamento 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.
280 1 Simone Piccardi
281 41 Simone Piccardi
h3. La configurazione di Apache
282 1 Simone Piccardi
283 41 Simone Piccardi
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:
284 3 Simone Piccardi
285 1 Simone Piccardi
<pre>
286 14 Elena Grandi
SSLCertificateFile /etc/letsencrypt/live/mail.truelite.it/cert.pem
287 1 Simone Piccardi
SSLCertificateChainFile /etc/letsencrypt/live/mail.truelite.it/chain.pem
288 14 Elena Grandi
SSLCertificateKeyFile /etc/letsencrypt/live/mail.truelite.it/privkey.pem
289 3 Simone Piccardi
</pre>
290 1 Simone Piccardi
291 41 Simone Piccardi
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:
292 25 Simone Piccardi
293 1 Simone Piccardi
<pre>
294 25 Simone Piccardi
SSLCertificateFile /etc/letsencrypt/live/mail.truelite.it/fullchain.pem
295 1 Simone Piccardi
SSLCertificateKeyFile /etc/letsencrypt/live/mail.truelite.it/privkey.pem
296
</pre>
297
298 41 Simone Piccardi
Quando si usano gli stessi certificati per più virtual host 
299
300 25 Simone Piccardi
h3. Postfix
301 1 Simone Piccardi
302 41 Simone Piccardi
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:
303 1 Simone Piccardi
304
<pre>
305 41 Simone Piccardi
smtpd_use_tls=yes
306 1 Simone Piccardi
smtpd_tls_cert_file=/etc/letsencrypt/live/mail.truelite.it/fullchain.pem
307
smtpd_tls_key_file=/etc/letsencrypt/live/mail.truelite.it/privkey.pem
308 25 Simone Piccardi
</pre>
309
310 1 Simone Piccardi
h3. Dovecot
311 14 Elena Grandi
312 41 Simone Piccardi
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:
313 5 Simone Piccardi
314 3 Simone Piccardi
<pre>
315 41 Simone Piccardi
ssl = yes
316 3 Simone Piccardi
ssl_cert = </etc/letsencrypt/live/mail.truelite.it/fullchain.pem
317
ssl_key = </etc/letsencrypt/live/mail.truelite.it/privkey.pem
318 1 Simone Piccardi
</pre>
319 3 Simone Piccardi
320
h3. Nginx
321 1 Simone Piccardi
322 41 Simone Piccardi
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:
323 14 Elena Grandi
324
<pre>
325 1 Simone Piccardi
server {
326 9 Simone Piccardi
   listen 443 ssl;
327 41 Simone Piccardi
   server_name mail.truelite.it;
328 1 Simone Piccardi
   root /var/www/html;
329 41 Simone Piccardi
   ssl_certificate /etc/letsencrypt/live/mail.truelite.it/fullchain.pem;
330
   ssl_certificate_key /etc/letsencrypt/live/mail.truelite.it/privkey.pem;
331 1 Simone Piccardi
   ...
332
</pre>
333
334
h3. ejabberd
335
336 41 Simone Piccardi
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:
337 1 Simone Piccardi
338 10 Simone Piccardi
<pre>
339 1 Simone Piccardi
cat /etc/letsencrypt/live/jabber.truelite.it/privkey.pem \
340
    /etc/letsencrypt/live/jabber.truelite.it/fullchain.pem > ejabberd.pem
341
</pre>
342
343 41 Simone Piccardi
ed inserire in @/etc/ejabberd/ejabberd.yml@ le righe:
344 1 Simone Piccardi
345 41 Simone Piccardi
<pre>
346
certfiles:
347
  - "/etc/ejabberd/ejabberd.pem"
348
</pre>
349
350 1 Simone Piccardi
h2. Il rinnovo dei certificati
351
352 41 Simone Piccardi
A differenze 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":https://letsencrypt.org/ è di soli tre mesi. La scelta è voluta, per ridurre l'impatto di una compromissione, 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@.
353 1 Simone Piccardi
354 42 Simone Piccardi
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 averli ottenuti si otterrà qualcosa del tipo:
355 41 Simone Piccardi
356 1 Simone Piccardi
<pre>
357
# certbot renew
358
Checking for new version...
359
Requesting root privileges to run letsencrypt...
360 7 Simone Piccardi
   /root/.local/share/letsencrypt/bin/letsencrypt renew
361 1 Simone Piccardi
362
-------------------------------------------------------------------------------
363
Processing /etc/letsencrypt/renewal/mail.truelite.it.conf
364 20 Elena Grandi
-------------------------------------------------------------------------------
365
366
The following certs are not due for renewal yet:
367
  /etc/letsencrypt/live/mail.truelite.it/fullchain.pem (skipped)
368
No renewals were attempted.
369
</pre>
370
371 42 Simone Piccardi
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@). La cosa si può automatizzare inserendo banalmente nel cron il comando, ad esempio creando il file @/etc/cron.d/letencrypt@ con il contenuto:
372 24 Simone Piccardi
373 20 Elena Grandi
<pre>
374
00 23 * * 6  root certbot renew
375 24 Simone Piccardi
</pre>
376 28 Simone Piccardi
377 42 Simone Piccardi
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. 
378 1 Simone Piccardi
379 42 Simone Piccardi
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 paremetro delle stesse il comando da eseguire in ciascuno dei casi. 
380 1 Simone Piccardi
381 42 Simone Piccardi
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  @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 comunque quando si tenta il rinnovo di almeno un certificato (nel caso siano più di uno), ma se si è creato il certificato con @certbot certonly@ in genere non sono necessari. 
382
383
L'opzione più utile resta in effetti @--deploy-hook@ che consente di indicare un comando da  eseguire soltanto dopo avere effettivamente ottenuto il rinnovo del certificato (non viene eseguita se @certbot@ rileva che il certificato non deve essere 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).
384
385
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 questa directory verranno eseguiti come se li si fossero indicati con le corrispondenti opzioni, in ordine alfabetico. 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 definento nel loro ambiente le variabili @RENEWED_LINEAGE@ che contiene 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@".