This is an old revision of the document!
Table of Contents
Certificati Let's Encrypt (certbot)
Let’s Encrypt è una Autorità di Certificazione gratuita, automatica e aperta. Consente cioè di ottenere certificati SSL (ad esempio per i siti https) in modo automatico e gratuito.
Per Debian GNU/Linux esiste il client certbot che deve essere eseguito sullo stesso host che ospita il webserver. In pratica lo script dialoga con la Certification Authority ed effettua le seguenti operazioni:
- Scarica un challenge e lo pubblica via web sul dominio che si vuole certificare.
- Richiede alla Certification Authority di verificare il challenge.
- Riceve il certificato (valido per il dominio in questione) e lo salva in
/etc/letsencrypt/archive/<dominio>
.
È possibile anche estendere il certificato in modo che comprenda diversi nomi a dominio. In questo modo un unico certificato è valido per diversi VirtualHost Apache.
Un certificato rilasciato da Let's Encrypt può essere utilizzato anche per la crittografia SSL del server SMTP Exim4.
Installazione su Debian Jessie
Per Debian Jessie il pacchetto certbot esiste nei jessie-backports. Le dipendenze sono molte e ogni tanto la compilazione dei backports fallisce (il pacchetto non esiste sul repository), conviene quindi scaricare e salvare tutte le dipendenze backports in locale. Questo l'elenco dei pacchetti backports che si è dovuto scaricare per installare certbot 0.8.0 su Debian Jessie:
certbot python-acme python-certbot python-cffi-backend python-configargparse python-cryptography python-dialog python-idna python-ipaddress python-openssl python-psutil python-pyasn1 python-rfc3339
Richiesta dei certificati: modalità test
Questa è la riga di comando per scaricare dei certificati di test (per i certificati di test non ci sono limiti di richieste giornaliere):
certbot certonly --text --test-cert --webroot -w "/var/www/html/www.rigacci.org" -d "www.rigacci.org"
Lo script deve avere accesso alla DocumentRoot del dominio per scrivere temporaneamente il challenge. Viene creata a tal scopo una sottodirectory di nome .well-known
. Se tutto funziona il certificato verrà salvato in /etc/letsencrypt/archive/www.rigacci.org/
.
Richiesta dei certificati: modalità produzione
In modo del tutto simile si ottiene il certificato effettivo:
certbot certonly --text --webroot -w "/var/www/html/www.rigacci.org" -d "www.rigacci.org"
Nella configurazione Apache andranno aggiunte le direttive:
SSLCertificateFile /etc/letsencrypt/live/www.rigacci.org/fullchain.pem" SSLCertificateKeyFile /etc/letsencrypt/live/www.rigacci.org/privkey.pem"
È lo script certbot che si occupa di mantenere il link simbolico dalla directory live alla directory archive.
Estensione del certificato a più nomi a dominio
Se si desidera estendere il certificato ad altri nomi a dominio questa è la riga di comando:
certbot certonly --text --webroot \ -w "/var/www/html/www.rigacci.org" -d "www.rigacci.org" \ -w "/var/www/html/mail.rigacci.org" -d "mail.rigacci.org"
ATTENZIONE: Conviene eseguire lo script la prima volta con solo il dominio principale, in modo che il nome della directory creata sarà /etc/letsencrypt/archive/<dominio>
. Invocando certbot con nomi di dominio aggiuntivi, lo script chiederà conferma se si vuole estendere il certificato esistente, in caso affermativo questi saranno aggiunti.
C'è un solo inconveniete: il certificate subject verrà scelto in maniera casuale fra tutti i nomi elencati, senza privilegiare il nome principale (quello dichiarato per primo). Questo potrebbe anche essere un bug, vedi Let's Encrypt Forum e GitHub request 2809. NOTA: Sembra che il problema sia risolto a partire dalla versione 0.6.0 del client, questo dovrebbe essere il commit relativo.
Rimozione di un nome di dominio dai Subject Alternative Names
Pare che vi sia un bug al momento in cui si cerca di togliere un nome di dominio dall'elenco dei nomi alternativi SAN (Subject Alternative Names); alla successiva esecuzione di certbot certonly viene creata una nuova lineage di certificati in una cartella appositamente creata: /etc/letsencrypt/archive/<domain>-0001/
, anche nella directory /etc/letsencrypt/live/
venono creati i link simbolici sotto una nuova directory con il suffisso -0001
. Ovviamente i vari software (Apache, Postfix, ecc.) continueranno ad utilizzare la vecchia lineage di certificati.
Vedere in proposito questo post e questo bug.
È possibile eliminare manualmente la vecchia lineage e rinominare quella nuova togliendo il suffisso. Fare attenzione a tutte le modifiche da fare:
- /etc/letsencrypt/archive/<domain>-0001/ Rinominare la directory.
- /etc/letsencrypt/live/<domain>-0001/ Modificare i link simbolici contenuti.
- /etc/letsencrypt/live/<domain>-0001/ Rinominare la directory.
- /etc/letsencrypt/renewal/<domain>-0001.conf Rinominare il file e modificare il contenuto.
Redirect automatico da http a https
Alcuni siti possono avere il redirect automatico da http ad https con una direttiva Redirect di Apache. Ad esempio:
<VirtualHost *:80> SSLEngine off ServerName mail.rigacci.org RedirectMatch permanent /(.*) https://mail.rigacci.org/mail/ </VirtualHost>
Questo rende impossibile il funzionamento di certbot che si basa sul fatto di poter pubblicare temporaneamente il challenge sul dominio web (senza SSL).
La soluzione più elegante può essere quella di effettuare il redirect ad eccezione per la .well-known directory:
RedirectMatch permanent ^/((?!\.well-known).*)$ https://mail.rigacci.org/$1
Una alternativa può essere quella di creare una DocuemtnRoot ad-hoc, che effettui il redirect su hpps via PHP invece che con direttiva Apache. Questa stessa DocumentRoot sostanzialmente vuota può essere condivisa da diversi VirtualHost, anche con nomi a dominio diversi. La configurazione Apache diventa:
<VirtualHost *:80> SSLEngine off ServerName mail.rigacci.org DocumentRoot /var/www/html/http2https ErrorDocument 404 /404.php </VirtualHost>
e nella DocumentRoot ci saranno due file:
index.php
<?php $redirect_location = 'https://' . $_SERVER['SERVER_NAME'] . '/'; header("Location: $redirect_location"); ?>
404.php
<?php $redirect_location = 'https://' . $_SERVER['SERVER_NAME'] . $_SERVER['REQUEST_URI']; header("Location: $redirect_location"); ?>
Directory protetta da .htaccess
Se un intero sito è protetto da una direttiva tipo AuthType Basic (ad esempio con una accoppiata di file .htaccess e .htpasswd), la procedura di certbot fallisce perché il server remoto non è in grado di accedere via HTTP alla sottodirectory /.well-known/ creata appositamente (nella quale viene creato il challenge provvisorio).
È quindi necessario escludere la sottodirectory /.well-known/ dalla direttiva AuthType Basic, ad esempio creando un apposito file .htaccess che contiene:
AuthType None Require all granted
Rinnovo dei certificati
Con il semplice comando
certbot renew
si verifica e si rinnovano tutti i certificati contenuti in /etc/letsencrypt/live/
. Eventualmente si aggiunge l'opzione -q
per fare un cronjob che non genera messaggi inutili.
Reload di Apache
Dopo aver esteso un certificato (e quindi anche dopo un rinnovo automatico?) è necessario notificare il demone apache almeno con un reload, ad esempio con systemctl reload apache2.service.
Utilizzo dei certificati con Exim4
È sufficiente copiare il certificato e la chiave nei rispettivi file attesi da Exim. Non si possono utilizzare link simbolici perchè i file creati da certbot non hanno i permessi giusti.
cat /etc/letsencrypt/live/www.rigacci.org/fullchain.pem > /etc/exim4/exim.crt cat /etc/letsencrypt/live/www.rigacci.org/privkey.pem > /etc/exim4/exim.key chown root:Debian-exim /etc/exim4/exim.crt /etc/exim4/exim.key chmod 640 /etc/exim4/exim.crt /etc/exim4/exim.key systemctl reload exim4.service
Utilizzo dei certificati con Postfix
Sembra che con i permessi predefiniti Postfix riesca a leggere i certificati direttamente dalla directory di Let's Encrypt, quindi è sufficiente mettere in /etc/postfix/main.cf
:
smtpd_tls_cert_file = /etc/letsencrypt/live/www.rigacci.org/fullchain.pem smtpd_tls_key_file = /etc/letsencrypt/live/www.rigacci.org/privkey.pem
Se il file certificato viene aggiornato è necessario fare un reload del demone.
Conviene verificare il livello di crittografia offerto dal server e disabilitare tutti i sistemi deboli o difettosi. Esistono diversi servizi on-line che consentono di fare il check.
Alcuni algoritmi di crittografia utilizzano i parametri di Diffie-Hellman e per avere una sicurezza accettabile richiedono più di 1024 bit. L'impostazione predefinita (almeno su Debian Jessie) è invece limitata a 1024 bit.
Questo il comando necessario a generare un file DH di 2048 bit:
openssl dhparam -out /etc/postfix/dh2048.pem 2048
Queste le impostazioni da mettere in /etc/postfix/main.cf
per utilizzare il file DH appena generato e per disabilitare i metodi di crittografia anonimi:
smtpd_tls_dh1024_param_file = /etc/postfix/dh2048.pem smtpd_tls_exclude_ciphers = aNULL, RC4
Verifica del certificato SMTP con STARTTLS
È possibile utilizzare una installazione Nagios per verificare il corretto funzionamento del certificato, il plugin check_smtp installato con il pacchetto monitoring-plugins-basic può essere invocato direttamente (il parametro -D indica il numero minimo di giorni di validità, al di sotto dei quali scatta il warning):
/usr/lib/nagios/plugins/check_smtp -H mail.rigacci.org --port=25 --starttls -D 28 OK - Certificate 'mail.rigacci.org' will expire on Sun 10 Sep 2017 08:52:00 AM CEST.
Utilizzo dei certificati con Courier POP e IMAP
I pacchetti Debain courier-pop-ssl e courier-imap-ssl forniscono rispettivamente gli script mkpop3dcert e mkimapdcert che provvedono a creare i certificati autofirmati e salvarli in
- /etc/courier/pop3d.pem
- /etc/courier/imapd.pem
Per utilizzare invece i certificati Let's Encrypt è sufficiente accodare i due file privkey.pem e fullchain.pem dentro il file letto da Courier. Nelle vecchie distribuzioni Debian (prima della 8 Jessie) si doveva accodare a questo file anche i parametri DH, che adesso invece vengono letti separatamente da /etc/courier/dhparams.pem
; verificare che questo file contenga almeno 2048 bit, altrimenti si incappa nell'errore SSL3_READ_BYTES.
Non è necessario eseguire il reload dei demoni Courier, sembra che il certificato venga ricaricato al volo quando viene modificato.
Questo può essere uno script per generare il nuovo certificato, se il PEM di Let's Encrypt è stato aggiornato:
#!/bin/sh SRC_KEY='/etc/letsencrypt/live/mail.rigacci.org/privkey.pem' SRC_CRT='/etc/letsencrypt/live/mail.rigacci.org/fullchain.pem' DST_PEM='/etc/courier/letsencrypt.pem' fingerprint_src="$(/usr/bin/openssl x509 -fingerprint -noout -in "$SRC_CRT")" fingerprint_dst="$(/usr/bin/openssl x509 -fingerprint -noout -in "$DST_PEM")" || true if [ "$fingerprint_src" != "$fingerprint_dst" ]; then cat "$SRC_KEY" "$SRC_CRT" > "$DST_PEM" fi
Il file .pem viene indicato con la direttiva TLS_CERTFILE nei file /etc/courier/imapd-ssl e /etc/courier/pop3d-ssl.
Verifica dei certificati POP/IMAP
Anche la verifica del certificato SSL per il protocollo POP può essere fatta con il plugin Nagios check_pop. Sembra che il check vada fatto sulla porta 995/tcp pop3s (il plugin non supporta STARTTLS sulla porta 110?), quindi il demone deve essere in ascolto su quella porta:
/usr/lib/nagios/plugins/check_pop -H mail.rigacci.org --port=995 -D 28 OK - Certificate 'mail.rigacci.org' will expire on Sat 12 Jun 2021 10:57:00 AM CEST.
La stessa cosa vale per il protocollo IMAP:
/usr/lib/nagios/plugins/check_imap -H mail.rigacci.org --port=993 -D 28 OK - Certificate 'mail.markcommunication.com' will expire on Sat 12 Jun 2021 10:57:00 AM CEST.