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.

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

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/.

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.

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.

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.

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");
?>

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

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.

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.

È 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

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

È 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.

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.

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.