UsareLetsEncrypt » History » Version 36
Simone Piccardi, 05/07/2024 04:00 PM
1 | 9 | Simone Piccardi | h1. Usare Let's Encrypt |
---|---|---|---|
2 | 1 | Simone Piccardi | |
3 | 14 | Elena Grandi | {{>toc}} |
4 | |||
5 | h2. Installazione |
||
6 | |||
7 | 36 | Simone Piccardi | h3. Panoramica |
8 | |||
9 | L'uso dei certificati SSL è ormai divenuto uno dei passi fondamentali nella gestione della sicurezza della rete, non solo per i siti web, in quanto consente sia di cifrare le connessioni, evitando una possibile intercettazione dei dati, che di identificare l'autenticità del corrispondente, garantendono 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. Inoltre l'utilizzo di |
||
10 | |||
11 | 22 | Simone Piccardi | h3. Installazione da pacchetti |
12 | 1 | Simone Piccardi | |
13 | 32 | Simone Piccardi | Per l'uso della nuova Certification Authority libera e gratuita promossa da EFF, Mozilla e molti altri, il meccanismo più semplice è quello di installare i pacchetti della distribuzione, disponibili in Debian a partire da Jessie (nei backports) e direttamente con Stretch. Pertanto se necessario occorrerà abilitare @jessie-backports@ in @sources.list@, quindi eseguire: |
14 | 16 | Elena Grandi | |
15 | 1 | Simone Piccardi | <pre> |
16 | apt-get install python-certbot-apache -t jessie-backports |
||
17 | </pre> |
||
18 | |||
19 | 32 | Simone Piccardi | mentre con Stretch sarà sufficiente: |
20 | |||
21 | <pre> |
||
22 | apt-get install certbot |
||
23 | </pre> |
||
24 | |||
25 | 24 | Simone Piccardi | questo renderà disponibile il comando @certbot@. |
26 | |||
27 | 22 | Simone Piccardi | h3. Installazione dal repository ufficiale |
28 | 1 | Simone Piccardi | |
29 | 22 | Simone Piccardi | In alternativa, per distribuzioni più vecchie o senza disponibilità dei pacchetti già pronti, è possibile usare direttamente la versione distribuita tramite il repository ufficiale, ottenibile con @git@ (che dovrà essere installato a sua volta se non presente) eseguendo: |
30 | 16 | Elena Grandi | |
31 | 1 | Simone Piccardi | <pre> |
32 | 16 | Elena Grandi | git clone https://github.com/certbot/certbot |
33 | 1 | Simone Piccardi | </pre> |
34 | 11 | Simone Piccardi | |
35 | 22 | Simone Piccardi | Per verificarne il funzionamento occorrerà porsi nella directory in cui lo si è clonato il repository ufficiale e per fargli installare gli eventuali pacchetti mancanti si dovrà eseguire (da root): |
36 | 1 | Simone Piccardi | |
37 | <pre> |
||
38 | 16 | Elena Grandi | cd certbot |
39 | ./certbot-auto --help |
||
40 | 11 | Simone Piccardi | </pre> |
41 | 1 | Simone Piccardi | |
42 | 22 | Simone Piccardi | Il programma inoltre si autoaggiornerà ad ogni esecuzione, e se lanciato senza argomenti cercherà di eseguire una installazione automatica, la verifica della richiesta per poter emettere i certificati ed infine anche la configurazione del web server per usare i certificati ottenuti, fornendo indicazioni qualora tutto ciò non sia possibile. |
43 | 16 | Elena Grandi | |
44 | 22 | Simone Piccardi | Le modalità di utilizzo in questa forma completamente automatizzata dipendono infatti dalla disponibilità o meno di alcuni pacchetti nella propria distribuzione, ad esempio con Debian Wheezy non si può utilizzare l'autoconfigurazione automatica di Apache, mancando sufficiente supporto. Nel prosieguo tratteremo comunque soltanto la modalità di configurazione non automatica, coprendo con questo anche la configurazione di altri servizi che non siano i server web, come la posta elettronica o la messaggistica. |
45 | 1 | Simone Piccardi | |
46 | 16 | Elena Grandi | h3. Note storiche |
47 | 1 | Simone Piccardi | |
48 | 24 | Simone Piccardi | Le vecchie versioni del programma avevano come nome @letsencrypt@ anziché @certbot@; il funzionamento del comando, a parte alcune opzioni aggiuntive introdotte in un secondo tempo, è lo stesso per tutte le operazioni di base (come creazione e aggiornamento dei certificati), ma si ottiene usando @letsencrypt-auto@ anziché @certbot-auto@ (nei sorgenti comunque viene fornito anche @letsencrypt-auto@ come copia di @certbot-auto@). Negli esempi seguenti useremo l'invocazione assumendo una installazione da pacchetto e la presenza del comando @certbot@. |
49 | 16 | Elena Grandi | |
50 | 22 | Simone Piccardi | |
51 | 14 | Elena Grandi | h2. La generazione dei certificati |
52 | 3 | Simone Piccardi | |
53 | 1 | Simone Piccardi | h3. Creazione del primo certificato |
54 | |||
55 | 24 | Simone Piccardi | In generale, quando non è possibile o non si vuole utilizzare la configurazione automatica dei servizi, e si deve ricorrere all'uso del sottocomando @certonly@, come indicato anche dal programma stesso se questi rileva che l'automatismo è impossibile: |
56 | 1 | Simone Piccardi | |
57 | <pre> |
||
58 | 16 | Elena Grandi | root@holland:~/certbot# ./certbot-auto |
59 | 1 | Simone Piccardi | Checking for new version... |
60 | Requesting root privileges to run letsencrypt... |
||
61 | /root/.local/share/letsencrypt/bin/letsencrypt |
||
62 | No installers seem to be present and working on your system; fix that or try running letsencrypt with the "certonly" command |
||
63 | </pre> |
||
64 | |||
65 | 22 | Simone Piccardi | L'uso del sottocomando @certonly@ consente soltanto di ottenere i certificati, la configurazione dei servizi dovrà essere eseguita manualmente. Per emettere un certificato Let's Encrypt 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. |
66 | 1 | Simone Piccardi | |
67 | 22 | Simone Piccardi | Questa procedura può essere realizzata direttamente dal programma se si usa dopo il comando @certonly@ l'opzione @--standalone@, che si incarica di far partire un servizio web sulla porta 80 o 443, ma in tal caso occorre fermare Apache o qualunque altro webserver che sia attivo sul dominio. |
68 | 1 | Simone Piccardi | |
69 | 23 | Simone Piccardi | Si può evitare tutto questo utilizzando l'opzione @--webroot@ (o @-w@) se è disponibile l'accesso via web alla _document root_ del sito per cui si vuole ottenere il certificato, in tal caso infatti il programma crea i file necessari alla validazione sotto la directory @.well-known/acme-challenge/@, che però deve poter essere servita a chi la richiede da fuori; occorre pertanto verificare che la configurazione del server web mantenga accessibile questa directory, ed è in genere necessaria un configurazione ad hoc. |
70 | 1 | Simone Piccardi | |
71 | 22 | Simone Piccardi | In questo caso deve essere indicata nella richiesta come argomento dell'opzione @-w@ la directory della _document root_, mentre il dominio (o i domini, se sono più di uno, nel qual caso saranno aggiunti allo stesso certificato come nomi alternativi) devono essere richiesti con l'opzione @-d@. |
72 | 1 | Simone Piccardi | |
73 | 22 | Simone Piccardi | Se si hanno diversi siti con diverse _document root_ in teoria si può 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@. In questo caso tutte le _document root_ dovranno essere egualmente accessibili. Alternativamente si potrà ripetere l'operazione separatamente per ciascun dominio. Si tenga presente che in questo caso saranno generati altrettanti certificati separati. |
74 | |||
75 | 23 | Simone Piccardi | Siccome tutto questo risulta scomodo e non è sempre applicabile, è possibile usare una unica directory per tutti i domini, anche se questa non corrisponde alla loro _document root_, consentendo l'accesso via web alla stessa in maniera generica (vedremo come farlo con le configurazioni descritte in seguito). Questa è anche la modalità consigliata dal progetto, assumeremo pertanto che si stia usando una configurazione adeguata e che la directory utilizzata per ospitare i file della _challenge and response_ di @.well-known/acme-challenge@ sia @/var/www/letsencrypt/@. |
76 | 22 | Simone Piccardi | |
77 | 1 | Simone Piccardi | Se pertanto si vuole ottenere il certificato per il dominio @mail.truelite.it@ il comando da usare sarà: |
78 | 22 | Simone Piccardi | |
79 | 16 | Elena Grandi | <pre> |
80 | 24 | Simone Piccardi | # certbot certonly --webroot -w /var/www/letsencrypt/ -d mail.truelite.it |
81 | 1 | Simone Piccardi | [...] |
82 | IMPORTANT NOTES: |
||
83 | - Congratulations! Your certificate and chain have been saved at |
||
84 | /etc/letsencrypt/live/mail.truelite.it/fullchain.pem. Your cert will |
||
85 | expire on 2016-07-07. To obtain a new version of the certificate in |
||
86 | the future, simply run Let's Encrypt again. |
||
87 | - If you lose your account credentials, you can recover through |
||
88 | e-mails sent to xxx@truelite.it. |
||
89 | - Your account credentials have been saved in your Let's Encrypt |
||
90 | configuration directory at /etc/letsencrypt. You should make a |
||
91 | secure backup of this folder now. This configuration directory will |
||
92 | also contain certificates and private keys obtained by Let's |
||
93 | Encrypt so making regular backups of this folder is ideal. |
||
94 | - If you like Let's Encrypt, please consider supporting our work by: |
||
95 | |||
96 | Donating to ISRG / Let's Encrypt: https://letsencrypt.org/donate |
||
97 | Donating to EFF: https://eff.org/donate-le |
||
98 | </pre> |
||
99 | |||
100 | 22 | Simone Piccardi | La prima volta che lo si esegue su per un dominio verrà richiesta una email di contatto (per comunicazione e recupero delle chiavi) e la prima volta che lo si esegue su una macchina si dovranno anche accettare le condizioni di Let's Encrypt. Questo comando creerà un certificato per il solo dominio @mail.truelite.it@; se un certificato deve essere valido per più domini, si possono salvare in un file, nell'esempio @valid_hosts.txt@ (un dominio per riga) ed usare il comando: |
101 | 1 | Simone Piccardi | |
102 | <pre> |
||
103 | 35 | Simone Piccardi | # certbot certonly --webroot -w /var/www/letsencrypt/ -d $(xargs < domainlist.txt | sed 's/ /,/g') |
104 | 1 | Simone Piccardi | </pre> |
105 | |||
106 | 22 | Simone Piccardi | oppure lo si può invocare nella forma: |
107 | 12 | Elena Grandi | |
108 | 22 | Simone Piccardi | <pre> |
109 | 24 | Simone Piccardi | # certbot certonly --webroot -w /var/www/letsencrypt/ -d mail.truelite.it -d smtp.truelite.it ... |
110 | 22 | Simone Piccardi | </pre> |
111 | |||
112 | I certificati rilasciati durano tre mesi, e vengono installati sotto @/etc/letsencrypt/live@ in una directory corrispondente al nome a dominio indicato per primo (se sono più di uno); nel caso saranno sotto @/etc/letsencrypt/live/mail.truelite.it/@. |
||
113 | 1 | Simone Piccardi | |
114 | |||
115 | 21 | Simone Piccardi | h3. Aggiunta di nuovi certificati distinti |
116 | 1 | Simone Piccardi | |
117 | 32 | Simone Piccardi | Se si 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, basterà ripetere il comando per ciascuno di essi. Ogni invocazione successiva con nomi a dominio diversi si limiterà a creare i certificati richiesti in maniera distinta, pertanto con qualcosa del tipo: |
118 | 1 | Simone Piccardi | |
119 | <pre> |
||
120 | 24 | Simone Piccardi | # certbot certonly --webroot -w /var/www/letsencrypt/ -d bd2.truelite.it |
121 | 1 | Simone Piccardi | Checking for new version... |
122 | Requesting root privileges to run letsencrypt... |
||
123 | /root/.local/share/letsencrypt/bin/letsencrypt certonly --webroot -w /var/www/letsencrypt/ -d bd2.truelite.it |
||
124 | |||
125 | IMPORTANT NOTES: |
||
126 | - Congratulations! Your certificate and chain have been saved at |
||
127 | /etc/letsencrypt/live/bd2.truelite.it/fullchain.pem. Your cert will |
||
128 | expire on 2016-07-07. To obtain a new version of the certificate in |
||
129 | the future, simply run Let's Encrypt again. |
||
130 | - If you like Let's Encrypt, please consider supporting our work by: |
||
131 | |||
132 | Donating to ISRG / Let's Encrypt: https://letsencrypt.org/donate |
||
133 | Donating to EFF: https://eff.org/donate-le |
||
134 | </pre> |
||
135 | |||
136 | 22 | Simone Piccardi | Si otterrà un'altro certificato, posto stavolta sotto @/etc/letsencrypt/live/bd2.truelite.it@. |
137 | 1 | Simone Piccardi | |
138 | 31 | Simone Piccardi | Con lo script @listlecert.sh@ allegato si può stampare un elenco dei certificati creati, e dei domini da essi coperti, ma le versioni correnti di @certbot@ supportano l'uso del comando @certbot certificates@ che stampa un elenco con tutti i dettagli comprese le data di scadenza ed i pathname dei file. |
139 | 1 | Simone Piccardi | |
140 | 22 | Simone Piccardi | |
141 | 1 | Simone Piccardi | h2. Gestione dei certificati |
142 | 22 | Simone Piccardi | |
143 | h3. Aggiunta di un nuovo dominio ad un certificato esistente |
||
144 | |||
145 | Qualora si voglia aggiungere un nuovo dominio ad un certificato esistente basterà ripetere l'invocazione del comando aggiungendo il nuovo dominio con una ulteriore opzione @-d@, ad esempio: |
||
146 | |||
147 | <pre> |
||
148 | 24 | Simone Piccardi | # certbot certonly --webroot -w /var/www/letsencrypt/ -d mail.truelite.it -d rainloop.truelite.it |
149 | 22 | Simone Piccardi | Saving debug log to /var/log/letsencrypt/letsencrypt.log |
150 | |||
151 | ------------------------------------------------------------------------------- |
||
152 | You have an existing certificate that contains a portion of the domains you |
||
153 | requested (ref: /etc/letsencrypt/renewal/mail.truelite.it.conf) |
||
154 | |||
155 | It contains these names: mail.truelite.it |
||
156 | |||
157 | You requested these names for the new certificate: mail.truelite.it, |
||
158 | rainloop.truelite.it. |
||
159 | |||
160 | Do you want to expand and replace this existing certificate with the new |
||
161 | certificate? |
||
162 | ------------------------------------------------------------------------------- |
||
163 | (E)xpand/(C)ancel: E |
||
164 | Renewing an existing certificate |
||
165 | ... |
||
166 | </pre> |
||
167 | 1 | Simone Piccardi | |
168 | 22 | 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. |
169 | |||
170 | h3. Rimozione di certificati non più raggiungibili |
||
171 | |||
172 | 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: |
||
173 | |||
174 | <pre> |
||
175 | 24 | Simone Piccardi | # certbot renew --allow-subset-of-names |
176 | 22 | Simone Piccardi | </pre> |
177 | |||
178 | 1 | Simone Piccardi | tutti i domini non verificati verranno quindi rimossi dal certificato, e i rinnovi successivi andranno a buon fine anche senza tale opzione. |
179 | 22 | Simone Piccardi | |
180 | Ovviamente, si deve avere cura di non lanciare questo comando in caso di non raggiungibilità _temporanea_ di alcuni dei domini, ed è quindi opportuno non usare questa opzione in contesti automatizzati. |
||
181 | |||
182 | 34 | Simone Piccardi | h3. Cancellazione di un certificato |
183 | |||
184 | 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, o eventualmente indicare il nome con l'opzione @--cert-name@. |
||
185 | |||
186 | 19 | Simone Piccardi | h3. Modifica delle informazioni di registrazione |
187 | |||
188 | 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: |
||
189 | |||
190 | <pre> |
||
191 | 24 | Simone Piccardi | # certbot register --update-registration --email nuovaemail@truelite.it |
192 | 19 | Simone Piccardi | Saving debug log to /var/log/letsencrypt/letsencrypt.log |
193 | |||
194 | ------------------------------------------------------------------------------- |
||
195 | Would you be willing to share your email address with the Electronic Frontier |
||
196 | Foundation, a founding partner of the Let's Encrypt project and the non-profit |
||
197 | organization that develops Certbot? We'd like to send you email about EFF and |
||
198 | our work to encrypt the web, protect its users and defend digital rights. |
||
199 | ------------------------------------------------------------------------------- |
||
200 | (Y)es/(N)o: y |
||
201 | |||
202 | IMPORTANT NOTES: |
||
203 | 1 | Simone Piccardi | - Your e-mail address was updated to nuovaemail@truelite.it. |
204 | 19 | Simone Piccardi | </pre> |
205 | 23 | Simone Piccardi | |
206 | 19 | Simone Piccardi | |
207 | 1 | Simone Piccardi | h2. Configurazioni per consentire la validazione |
208 | |||
209 | Come accennato per effettuare la validazione del dominio con la modalità @--webroot@ è necessario che siano raggiungibili i contenuti corrispondenti alla URL: |
||
210 | |||
211 | <pre> |
||
212 | http://mio.dominio.it/.well-known/acme-challenge/xxx |
||
213 | 14 | Elena Grandi | </pre> |
214 | 1 | Simone Piccardi | |
215 | 14 | Elena Grandi | cosa che può dipendere dalla configurazione del proprio webserver. |
216 | |||
217 | h3. Nginx |
||
218 | |||
219 | 1 | Simone Piccardi | Nel caso di Nginx la modalità suggerita per consentire questa configurazione è creare un frammento di configurazione (nel caso @/etc/nginx/snippets/letsencrypt-acme-challenge.conf@) contenente le direttive necessarie per consentire l'accesso: |
220 | |||
221 | <pre> |
||
222 | location ^~ /.well-known/acme-challenge/ { |
||
223 | default_type "text/plain"; |
||
224 | root /var/www/letsencrypt; |
||
225 | } |
||
226 | location = /.well-known/acme-challenge/ { |
||
227 | return 404; |
||
228 | } |
||
229 | 9 | Simone Piccardi | </pre> |
230 | 1 | Simone Piccardi | |
231 | 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 (basta anche inserirlo solo nelle direttive in chiaro), ad esempio con qualcosa del tipo: |
||
232 | |||
233 | <pre> |
||
234 | server { |
||
235 | listen 80; |
||
236 | root /var/www/html; |
||
237 | server_name bd.truelite.it; |
||
238 | include /etc/nginx/snippets/letsencrypt-acme-challenge.conf; |
||
239 | location / { |
||
240 | rewrite ^/(.*)$ https://bd.truelite.it/$1 permanent; |
||
241 | } |
||
242 | } |
||
243 | 14 | Elena Grandi | </pre> |
244 | |||
245 | 1 | Simone Piccardi | h3. Apache |
246 | |||
247 | 32 | Simone Piccardi | Una analoga configurazione per Apache si può effettuare utilizzando il seguente frammento di configurazione: |
248 | 11 | Simone Piccardi | |
249 | <pre> |
||
250 | 1 | Simone Piccardi | Alias /.well-known/acme-challenge/ /var/www/letsencrypt/.well-known/acme-challenge/ |
251 | <Directory "/var/www/letsencrypt/.well-known/acme-challenge/"> |
||
252 | Options None |
||
253 | AllowOverride None |
||
254 | ForceType text/plain |
||
255 | # avoid access to anything not resembling a challenge |
||
256 | RedirectMatch 404 "^(?!/\.well-known/acme-challenge/[\w-]{43}$)" |
||
257 | </Directory> |
||
258 | 6 | Simone Piccardi | </pre> |
259 | |||
260 | 33 | Simone Piccardi | Con Debian da Jessie in poi lo si può inserire in @/etc/apache2/conf-available/@ ed abilitare con @a2enconf@, con le versioni precedenti occorreva usare @/etc/apache2/conf.d@, per altre distribuzioni si utilizzi una posizione adeguata e lo si includa nella configurazione generale di Apache. |
261 | 32 | Simone Piccardi | |
262 | Si tenga presente però che qualora si usi Apache come reverse proxy 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: |
||
263 | 6 | Simone Piccardi | |
264 | 1 | Simone Piccardi | <pre> |
265 | ProxyPass /.well-known/acme-challenge ! |
||
266 | </pre> |
||
267 | |||
268 | 17 | Simone Piccardi | 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: |
269 | |||
270 | <pre> |
||
271 | 26 | Simone Piccardi | <VirtualHost *:80> |
272 | 17 | Simone Piccardi | ServerName ci.truelite.it |
273 | Redirect permanent / https://ci.truelite.it/ |
||
274 | </VirtualHost> |
||
275 | </pre> |
||
276 | |||
277 | con una più specifica che escluda la redirezione per la URL utilizzata da Let's Encrypt: |
||
278 | |||
279 | <pre> |
||
280 | 26 | Simone Piccardi | <VirtualHost *:80> |
281 | 17 | Simone Piccardi | ServerName ci.truelite.it |
282 | RedirectMatch 301 ^/((?!.well-known\/acme-challenge).*)$ https://ci.truelite.it/$1 |
||
283 | </VirtualHost> |
||
284 | </pre> |
||
285 | |||
286 | 27 | Simone Piccardi | Se si vuole ottenere lo stesso risultato con il virtualhost di default di Apache, non è più possibile utilizzare @RedirectMatch@ in quanto in tal caso non è noto a priori l'hostname con cui si viene contattati, si può però inserire una regola generica in @/etc/apache2/sites-available/000-default.conf@ con: |
287 | |||
288 | <pre> |
||
289 | <VirtualHost *:80> |
||
290 | [...] |
||
291 | RewriteEngine On |
||
292 | RewriteCond %{HTTPS} off [OR] |
||
293 | RewriteRule ^/((?!.well-known\/acme-challenge).*)$ https://%{HTTP_HOST}/$1 [NC,R=301,L] |
||
294 | [...] |
||
295 | </VirtualHost> |
||
296 | </pre> |
||
297 | |||
298 | 1 | Simone Piccardi | |
299 | h2. Esempi di configurazione dei servizi |
||
300 | |||
301 | 4 | Simone Piccardi | Una volta completata la validazione del proprio dominio, nella directory di installazione dei certificati (@/etc/letsencrypt/live/mio.dominio.it@) vengono sempre creati i file: |
302 | 1 | Simone Piccardi | |
303 | | *file* | *contenuto* | |
||
304 | |cert.pem | cerficato | |
||
305 | |chain.pem | catena dalla CA | |
||
306 | |fullchain.pem | catena + certificato| |
||
307 | 3 | Simone Piccardi | |privkey.pem | chiave privata | |
308 | 1 | Simone Piccardi | |
309 | Dove @chain.pem@ è il certificato intermedio (o la catena di certificati intermedi) che validano @cert.pem@ che è il certificato del proprio dominio, mentre @fullchain.pem@ è l'insieme completo del certificato e della catena. Infine la chiave privata è in @privkey.pem@. |
||
310 | |||
311 | 14 | Elena Grandi | In qualunque configurazione occorre sempre fare riferimento a questi file, che sono link simbolici, in quanto @letsencrypt@ aggiornerà automaticamente gli stessi con la procedura di rinnovo automatico che vedremo più avanti. |
312 | |||
313 | 1 | Simone Piccardi | h3. Apache |
314 | |||
315 | 25 | Simone Piccardi | I file @cert.pem@ e @chain.pem@ sono quelli che si usano nella configurazione di Apache, che fino alla versione 2.2 li vuole separati, ad esempio con quelli ottenuti in precedenza la configurazione utilizzata è: |
316 | 3 | Simone Piccardi | |
317 | 1 | Simone Piccardi | <pre> |
318 | 14 | Elena Grandi | SSLCertificateFile /etc/letsencrypt/live/mail.truelite.it/cert.pem |
319 | SSLCertificateChainFile /etc/letsencrypt/live/mail.truelite.it/chain.pem |
||
320 | 5 | Simone Piccardi | SSLCertificateKeyFile /etc/letsencrypt/live/mail.truelite.it/privkey.pem |
321 | 3 | Simone Piccardi | </pre> |
322 | 1 | Simone Piccardi | |
323 | 25 | Simone Piccardi | se invece si usa la versione 2.4 non è più necessario usare @SSLCertificateChainFile@ che è 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: |
324 | |||
325 | <pre> |
||
326 | SSLCertificateFile /etc/letsencrypt/live/mail.truelite.it/fullchain.pem |
||
327 | SSLCertificateKeyFile /etc/letsencrypt/live/mail.truelite.it/privkey.pem |
||
328 | </pre> |
||
329 | |||
330 | 1 | Simone Piccardi | h3. Postfix |
331 | |||
332 | 25 | Simone Piccardi | |
333 | Il file @fullchain.pem@ è quello che viene richiesto anche da Postfix, Dovecot e Nginx. Per Postfix occorrerà farvi riferimento in @/etc/postfix/main.cf@ con le direttive: |
||
334 | 1 | Simone Piccardi | |
335 | 14 | Elena Grandi | <pre> |
336 | smtpd_tls_cert_file=/etc/letsencrypt/live/mail.truelite.it/fullchain.pem |
||
337 | 5 | Simone Piccardi | smtpd_tls_key_file=/etc/letsencrypt/live/mail.truelite.it/privkey.pem |
338 | 3 | Simone Piccardi | </pre> |
339 | |||
340 | 5 | Simone Piccardi | h3. Dovecot |
341 | 3 | Simone Piccardi | |
342 | mentre per Dovecot di dovanno utilizzare in @/etc/dovecot/conf.d/90-user.conf@ le direttive: |
||
343 | 1 | Simone Piccardi | |
344 | 3 | Simone Piccardi | <pre> |
345 | ssl_cert = </etc/letsencrypt/live/mail.truelite.it/fullchain.pem |
||
346 | 1 | Simone Piccardi | ssl_key = </etc/letsencrypt/live/mail.truelite.it/privkey.pem |
347 | </pre> |
||
348 | 14 | Elena Grandi | |
349 | h3. Nginx |
||
350 | 1 | Simone Piccardi | |
351 | 9 | Simone Piccardi | ed infine per Nginx si dovrà inserire nella configurazione del proprio virtual host qualcosa del tipo: |
352 | 1 | Simone Piccardi | |
353 | <pre> |
||
354 | server { |
||
355 | listen 443 ssl; |
||
356 | server_name bd.truelite.it; |
||
357 | root /var/www/html; |
||
358 | ssl_certificate /etc/letsencrypt/live/bd.truelite.it/fullchain.pem; |
||
359 | ssl_certificate_key /etc/letsencrypt/live/bd.truelite.it/privkey.pem; |
||
360 | 20 | Elena Grandi | ... |
361 | 1 | Simone Piccardi | </pre> |
362 | 10 | Simone Piccardi | |
363 | 1 | Simone Piccardi | h3. ejabberd |
364 | |||
365 | Infine per configurare ejabberd (server jabber) occorre generare dai file di Let's Encrypt un unico file contenente in testa la chiave privata (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: |
||
366 | |||
367 | 18 | Simone Piccardi | <pre> |
368 | 1 | Simone Piccardi | cat /etc/letsencrypt/live/jabber.truelite.it/privkey.pem \ |
369 | /etc/letsencrypt/live/jabber.truelite.it/fullchain.pem > ejabberd.pem |
||
370 | </pre> |
||
371 | |||
372 | In tutti i casi deve essere effettuato un riavvio completo dei servizi. |
||
373 | |||
374 | h2. Il rinnovo dei certificati |
||
375 | |||
376 | La scadenza dei certificati emessi da Let's Encrypt è di tre mesi, ma una volta ottenuti questi possono essere facilmente rinnovati utilizzando il sottocomando @renew@, in particolare se si esegue il comando dopo averli ottenuti si otterrà qualcosa del tipo: |
||
377 | |||
378 | <pre> |
||
379 | 24 | Simone Piccardi | # certbot renew |
380 | 1 | Simone Piccardi | Checking for new version... |
381 | Requesting root privileges to run letsencrypt... |
||
382 | /root/.local/share/letsencrypt/bin/letsencrypt renew |
||
383 | |||
384 | 7 | Simone Piccardi | ------------------------------------------------------------------------------- |
385 | 1 | Simone Piccardi | Processing /etc/letsencrypt/renewal/mail.truelite.it.conf |
386 | ------------------------------------------------------------------------------- |
||
387 | |||
388 | 20 | Elena Grandi | The following certs are not due for renewal yet: |
389 | /etc/letsencrypt/live/mail.truelite.it/fullchain.pem (skipped) |
||
390 | No renewals were attempted. |
||
391 | </pre> |
||
392 | |||
393 | la cosa si può automatizzare inserendo banalmente nel cron il comando, ad esempio creando il file @/etc/cron.d/letencrypt@ con il contenuto: |
||
394 | |||
395 | <pre> |
||
396 | 24 | Simone Piccardi | 00 23 * * 6 root certbot renew |
397 | 20 | Elena Grandi | </pre> |
398 | |||
399 | 24 | Simone Piccardi | 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@. |
400 | 28 | Simone Piccardi | |
401 | 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. |
||
402 | |||
403 | 30 | Simone Piccardi | 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. |