Installare un certificato Let's Encrypt per i server qmail e dovecot

Changelog

• 25 luglio 2026 (v. 4.0) Script hook e documentazione sottostante completamente revisionati.
  - Aggiunto un nuovo script wrapper dehydrated-renew per eseguire il rinnovo del certificato e la sincronizzazione del servizio per SNI solo quando uno o più certificati sono effettivamente cambiati.
  - Introdotto un meccanismo di flag di modifica (dehydrated.changed) per evitare ricaricamenti e riavvii non necessari del servizio se un certificato è stato effettivamente distribuito.
  - Consolidate le operazioni post-rinnovo nella nuova funzione cert_sync(), fornendo un unico punto di ingresso per la sincronizzazione della configurazione dei certificati di qmail, Dovecot e Apache dopo i rinnovi riusciti. La stessa funzione cert_sync() può essere chiamata tramite uno script autonomo, che non coinvolge l'esecuzione di dehydrated. Ridotte le interruzioni non necessarie del servizio eseguendo la sincronizzazione una volta per ogni ciclo di rinnovo anziché una volta per ogni certificato rinnovato.
  - Il certificato qmail viene creato solo se è impostato MAKE_MAIL_CERTS=1. Se MAKE_MAIL_CERTS=0, lo script hook distribuisce solo i certificati (da utilizzare per il server web).
  - Le funzionalità Server Name Indication (SNI) per qmail e dovecot possono essere disabilitate impostando ENABLE_SNI=0 (impostazione predefinita).
  - Le voci ServerName e ServerAlias ​​per Apache e i domini SNI possono essere impostate facoltativamente con ENABLE_APACHE_SNI_CONF=1.

To enable HTTPS on your website, you need to get a certificate (a type of file) from a Certificate Authority (CA). Let’s Encrypt is a CA. In order to get a certificate for your website’s domain from Let’s Encrypt, you have to demonstrate control over the domain. With Let’s Encrypt, you do this using software that uses the ACME protocol which typically runs on your web host.

• Sito Let's Encrypt
• Pagina github dehydrated
• Pagina di AlienBob  (per utenti Slackware, ma con istruzioni generiche)

Dehydrated is a client for signing certificates with an ACME-server (e.g. Let's Encrypt) implemented as a relatively simple (zsh-compatible) bash-script. This client supports both ACME v1 and the new ACME v2 including support for wildcard certificates!

Trattandosi di un programma shell, dehydrated ha il vantaggio di non richiedere dipendenze, a differenza deI programma ufficiale certbot, che richiede una lunghissima serie di librerie python. Mantenere tutto questo volume di programmi si è rivelato faticoso nel tempo, ed è questo il motivo per cui mi sono deciso a passare a dehydrated.

Note per l'aggiornamento

Nel caso si debba rimpiazzare una installazione funzionante dei certificati basati su certbot, non è necessario prendere alcuna precauzione poichè questi non saranno sovrascritti dai nuovi generati da dehydrated. Pertanto è possibile eseguire i nostri test riguardanti la configurazione di dehydrated nello stesso server di produzione. Naturalmente sarà bene utilizzare un dominio di prova mentre si smanetta con Apache.

Installazione di dehydrated

E' probabile che la distribuzione in uso metta a disposizione un pacchetto dehydrated. In tal caso installarlo da lì, altrimenti scaricare e installare il programma dal sito github.

Qui di seguito un breve esempio di una installazione manuale in /usr/local (modificare secondo i propri bisogni):

VERSION=0.7.2
PREFIX=/usr/local

wget https://github.com/dehydrated-io/dehydrated/releases/download/v${VERSION}/dehydrated-${VERSION}.tar.gz
tar xzf dehydrated-${VERSION}.tar.gz
cd dehydrated-${VERSION}
chown -R root:root .
cp dehydrated $PREFIX/bin/
mkdir -p $PREFIX/man/man1 $PREFIX/share/doc/dehydrated-${VERSION}/docs/examples
cp docs/man/dehydrated.1 $PREFIX/man/man1/
mkdir -p /etc/dehydrated
cp docs/examples/config /etc/dehydrated/config.new # .new just to avoid overwrite of the existing config. Rename to config
cp CHANGELOG* LICENSE* README* $PREFIX/share/doc/dehydrated-${VERSION}
cp docs/*.md $PREFIX/share/doc/dehydrated-${VERSION}/docs
cp docs/examples/{domains.txt,hook.sh} $PREFIX/share/doc/dehydrated-${VERSION}/docs/examples

Configurazione

• Esempio di file di configurazione

Cambiare directory verso /etc/dehydrated, dove si possono trovare i file di configurazione e la cartella dove verranno installati i certificati. /etc/dehydrated/config.d è un percorso per file di configurazione addizionali contenenti un'estensione '.sh'.

Prima di tutto abilitare quanto segue nel file config

CONFIG_D="${BASEDIR}/config.d"

Quindi salvare i propri settaggi in /etc/dehydrated/config.d/local.sh, per esempio:

CA="letsencrypt-test"
CHALLENGETYPE="http-01"
WELLKNOWN="/var/www/htdocs/dehydrated"
#HOOK="${BASEDIR}/scripts/hook.sh"
HOOK_CHAIN="yes"
KEY_ALGO=rsa
CONTACT_EMAIL=postmaster@mydomain.tld
IP_VERSION=4

• CA contiene l'URL verso il server Let's Encrypt, o un parametro (in questo caso letsencrypt-test) che dice al programma quale URL usare. Nella fase di test lasciamo pure letsencrypt-test di modo che il server non venga bannato a causa dei troppi tentativi falliti. Cambieremo questo parametro in CA="letsencrypt" quando finito. Maggiori informazioni qui.
• CHALLENGETYPE="http-01" Come sappiamo, abbiamo bisogno di dimostrare di avere il controllo dei domini per i quali vogliamo ottenere un certificato. A tal fine dobbiamo consentire l'accesso a un particolare file salvato sul nostro web server, in una cartella dove Apache abbia i permessi di scrittura e per ciascun dominio da certificare.
  Ci sono anche altre CHALLENGETYPEs. Per esempio dns-01 è utile per certificare domini con caratteri jolly come *.sagredo.eu, ma è necessario avere a disposizione programmi che gestiscano in modo automatico il il server DNS. Questo aspetto non è coperto in questa guida.
• WELLKNOWN="/var/www/htdocs/dehydrated" è la directory dove dehydrated andrà a installare i ‘challenge-tokens’, i file di verifica di cui dicevamo prima, che saranno recuperati via http al fine di validare ciascun dominio.
• HOOK="${BASEDIR}/scripts/hook.sh" è lo script che verrà lanciato durante le operazioni di creazione del certificato. E' usato per assemblare il certificato per qmail, per riavviare i server e per notificare via mail all'amministratore gli eventuali problemi. E' meglio lasciarlo commentato durante le fasi iniziali di test.
• HOOK_CHAIN="yes" raggruppa tutte i challenges dei domini in una unica esecuzione del file hook invece di chiamarlo una volta per ciascun certificato.
• KEY_ALGO=rsa specifica l'algoritmo da usare per la chiave pubblica.
• IP_VERSION=4 risolve i nomi usando solo IPv4.

Per usare dehydrated è necessario registrare un account:

​# dehydrated --register --accept-terms
# INFO: Using main config file /etc/dehydrated/config 
+ Generating account key... 
+ Registering account key with ACME server... 
+ Fetching account URL... 
+ Done!

Le informazioni dell'account vengono salvate nella cartella /etc/dehydrated/accounts.

Configurazione dei domini

• Maggiori informazioni qui
• Leggere la seguente pagina prima di continuare: Server Name Indication (SNI) per qmail e dovecot

Creare un file domains.txt dove definire i domini che devono essere certificati separati da uno spazio bianco. Se una directory chiamata domains.txt.d esiste nella stessa locazione di domains.txt, i contenuti dei file di tipo *.txt in quella directory saranno appesi alla lista dei domini, in ordine alfabetico in base al nome del file. Questo è utile per automatizzare le cose, poiichè non è necessario modificare un file esistente quando si devono aggiungere nuovi domini.

Come sappiamo, non appena viene lanciato dehydrated -c, uno specifico certificato viene creato per ciascuna riga in domains.txt. Il nome di ciascun certificato coincide con il nome del primo dominio della riga. Gli altri domini nella stessa riga sono nomi alternativi (SAN) per lo stesso certificato. Se si prevede di sfruttare la funzionalità SNI per la propria installazione, è necessario porvi tutti i possibili domini a cui la configurazione automatica del client cercherà di connettersi durante la configurazione della casella di posta. Per sempio, se si sta configurando roberto@sagredo.eu, il client proverà a connettersi a smtp.sagredo.eu per il server SMTP e a imap.sagredo.eu per il server IMAP.

Di solito domains.txt contiene molte righe dedicate a scopi riguardanti SNI e solo alcune righe per i domini che hanno solo degli spazi web:

domain1.tld imap.domain1.tld pop3.domain1.tld smtp.domain1.tld --> certificato di DEFAULT di qmail
domain2.tld imap.domain2.tld pop3.domain2.tld smtp.domain2.tld --> certificato SNI di qmail
domain3.tld imap.domain3.tld pop3.domain3.tld smtp.domain3.tld --> certificato SNI di qmail
.....
webmail.mydomain.tld                                           --> altre righe usate per i siti web

In questo esempio dehydrated crea vari certificati, di cui l'ultimo è inteso per l'utilizzo con i siti di Apache (per esempio la webmail).

Se si devono ghestire centinaia di domini virtuali di vpopmail, si può estrarne l'indice con vdominfo -n e quindi scrivere linee per ciascun dominio (ma anche alias di dominio) come nell'esempio precedente. E' necessario anche aggiungere anche delle righe di questo tipo al name server:

smtp IN CNAME mail.domain.tld.
imap IN CNAME mail.domain.tld.
pop3 IN CNAME mail.domain.tld.

Ultima cosa ma non meno importante, suggerisco fortemente di mettere i siti http ordinari (webmail.mydomain.tld nell'esempio precedente) in /etc/dehydrated/domains.txt.d/otherdomains.txt di modo che per questi domini non verrà creato alcun certificato addizionale per  qmail, e nemmeno verrà aggiunto alcun file di configurazione Dovecot/apache.

Configurazione di Apache

In gener è necessario certificare molti domini (siti web o domini per la posta), ognuno con le proprie impostazioni VirtualHost e DocumentRoot. dehydrated ha bisogno di salvare dei 'challenge-tokens' in una cartella che sia accessibile a tutti questi domini, diciamo /var/www/htdocs/dehydrated, che è quella che corrisponde al parametro WELLKNOWN nel file di configurazione.

Creiamolo (lo si potrà personalizzare in seguito):

mkdir -p /var/www/htdocs/dehydrated

Siccome è necessario includere uno stesso codice moltissime volte (una per ogni VirtualHost) conviene automatizzare la procedura salvando tale codice nel file redirect.conf, da includere in ciascun VirtualHost. Salviamo questo file nella cartella di configurazione di Apache, ovvero /etc/httpd:

# Definire o cambiare LOGDIR a seconda di dove il proprio server salva i log
LOGDIR=/var/www/error
WELLKNOWN=/var/www/htdocs/dehydrated

cat > /etc/httpd/redirect.conf << __EOF__
Define LOGDIR ${LOGDIR}
Define WELLKNOWN ${WELLKNOWN}

<IfModule mod_rewrite.c> 
  RewriteEngine On 
  RewriteCond %{REQUEST_URI} !^/.well-known/acme-challenge 
  RewriteRule ^(.*) https://%{SERVER_NAME}\$1 [R,L] 
</IfModule> 

Alias /.well-known/acme-challenge \${WELLKNOWN}
<Directory \${WELLKNOWN}>
  Options None 
  AllowOverride None 
  Require all granted 
</Directory>

CustomLog "\${LOGDIR}/dehydrated_access.log" combined
ErrorLog  "\${LOGDIR}/dehydrated.f2b.log"
__EOF__

In questo modo le richieste per i file come /.well-known/acme-challenge/* saranno servite nella cartella /var/www/htdocs/dehydrated, mentre il resto del traffico sarà redirezionato (in questo esempio) all'indirizzo https dello stesso dominio (SERVER_NAME). Come si può notare, ciò assume che il modulo  mod_rewrite di Apache sia stato abilitato.

Sempre per questioni di economia del codice, è meglio definire alcune variabili nel file generale di configurazione /etc/httpd.conf (o dove si preferisce). Per esempio, possiamo salvare lì il path del file da includere e, dato che ci siamo, il file che useremo in seguito per imprtare i certificati SSL e anche il path della cartella che contiene i certificati:

Define REDIRECT /etc/httpd/redirect.conf
Define SSL      /etc/httpd/ssl.conf
Define CERTDIR  /etc/dehydrated/certs

Questo è uno schema del virtual host relativo a un dominio di posta, che a questo punto diventa semplicissimo:

<VirtualHost *:80> 
  ServerName smtp.domain1.tld
  Include ${REDIRECT}
</VirtualHost>

Vedremo dopo come gestire le righe ServerAliases per i domini SNI. Per il momento lasciamo solo uno dei domini come ServerName. Non abilitare i domini virtuali sulla porta  443 fintanto che il certificato SSL non sarà stato installato.

Creazione dei certificati

E' ora giunto il momento di creare i nostri certificati:

# dehydrated -c 
# INFO: Using main config file /etc/dehydrated/config 
Processing smtp.domain1.tld 
+ Creating new directory /etc/dehydrated/certs/smtp.domain1.tld ... 
+ Signing domains... 
+ Generating private key... 
+ Generating signing request... 
+ Requesting new certificate order from CA... 
+ Received 1 authorizations URLs from the CA 
+ Handling authorization for smtp.domain1.tld 
+ 1 pending challenge(s) 
+ Deploying challenge tokens... 
+ Responding to challenge for smtp.domain1.tld authorization... 
+ Challenge is valid! 
+ Cleaning challenge tokens... 
+ Requesting certificate... 
+ Order is processing... 
+ Checking certificate... 
+ Done! 
+ Creating fullchain.pem... 
+ Done!

Dovremo ottenere un risultato simile per ogni certificato richiesto (uno per ogni riga in domains.txt). I certificati verranno salvati nella cartella certs, il cui path è stato salvato nella variabile CERTDIR. Usare man o anche dehydrated -h per vedere come cancellare o revocare i certificati.

Ricordare che, poichè stiamo creando i certificati attraverso l'authority letsencrypt-test, la loro verifica non può funzionare. Suggerisco di continuare a usare letsencrypt-test finò a quando non avremo installato lo script hook.

A questo punto i certificati non sono ancora "visti" nè dal web server, nè da qmail e nemmeno da Dovecot. Se stai ancora facendo delle prove e hai un certificato valido in produzione, usa un dominio di prova mentre esegui i prossimi test con Apache.

Configurazione SSL per Apache SSL

Configurare Apache creando un file con le impostazioni SSL da importare poi in ciascun VirtualHost:

cat > /etc/httpd/ssl.conf << __EOF__
SSLEngine on 
SSLCertificateFile      \${CERTDIR}/\${CERTNAME}/fullchain.pem 
SSLCertificateKeyFile   \${CERTDIR}/\${CERTNAME}/privkey.pem 
SSLCertificateChainFile \${CERTDIR}/\${CERTNAME}/fullchain.pem
__EOF__

CERTNAME è il nome del certificato, da passare prima di includere il file, come nell'esempio seguente. CERTDIR è una variabile che abbiamo già definito prima nel file httpd.conf.

Ecco un esempio di VirtualHost configurato per ospitare pagine web in https, dedicato per esempio alla webmail RoundCube:

<VirtualHost *:80> 
  ServerName webmail.mydomain.tld
  ServerAlias webmail.otherdomain.tld
  # usato dal challenge di dehydrated
  Include ${REDIRECT}
</VirtualHost> 

<VirtualHost *:443> 
  # Il nome del certificato è il primo dominio della riga in /etc/dehydrated/domains.txt
  Define CERTNAME mydomain.tld
  # SSL non potrà funzionare fino a che il certificato non sarà pronto. Lasciare commentato inizialmente
  Include ${SSL} 

  ServerName webmail.mydomain.tld
  ServerAlias webmail.otherdomain.tld

  ErrorLog  ${LOGDIR}/roundcube_error.log 
  CustomLog ${LOGDIR}/roundcube_access.log combined 

  DocumentRoot ${HTDOCS}/roundcube

  <Directory ${HTDOCS}/roundcube> 
    Require all granted 
  </Directory> 
</VirtualHost>

Installazione dello script hook

• script hook.sh
• Maggiori informazioni su SNI for qmail and Dovecot

dehydrated è in grado di lanciare un programma a nostra scelta durante la creazione del certificato (HOOK="${BASEDIR}/scripts/hook.sh" nel file config). Questo script è usato per assemblare il certificato per qmail, per aggiungere le impostazioni SNI a Dovecot e Apache, per riavviare i server e per inviare notifiche via mail all'amministratore in caso di problemi.

Lo script hook.sh è distribuito dallo stesso dehydrated e potrebbe cambiare in seguito con le nuove versioni, quindi le mie funzioni sono salvate in hook.inc e quindi importate in hook.sh al fine di semplificare gli aggiornamenti futuri del file principale.

Scaricare e creare un link simbolico alla cartella "scripts":

VERSION=4.0.2

cd /etc/dehydrated
wget https://github.com/sagredo-dev/dehydrated-hook/archive/refs/tags/v${VERSION}.tar.gz
tar xzf v${VERSION}.tar.gz
ln -s dehydrated-hook-${VERSION} scripts
cp hook.conf.template hook.conf

hook.tpl è il template per le mail di notifica. Lo si può personalizzare traducendolo nella propria lingua.

La chiamata allo script hook.sh nel file di configurazione è commentata per default per evitare che di sovrascrivere il file  /var/qmail/control/servercert.pem durante i test iniziali. Ora però la abilitiamo decommentando questa riga in /etc/dehydrated/config.d/local.sh:

HOOK="${BASEDIR}/scripts/hook.sh"

E' ora possibile personalizzare il file di configurazione hook.conf. Le opzioni importanti che meritano una spiegazione sono le seguenti:

• Il certificato per qmail viene assemblato solo se si è impostato MAKE_MAIL_CERTS=1. Se invece MAKE_MAIL_CERTS=0 lo script hook crea solo il certificato nella cartella di dehydrated (uso standard per webserver).
• Le impostazioni per il Server Name Indication (SNI) di qmail e Dovecot possono essere disabilitate ponendo ENABLE_SNI=0 (default).
• Le righe ServerName e ServerAlias per Apache e i domini SNI possono essere aggiunti automaticamente nel VirtualDomain di Apache ponendo ENABLE_APACHE_SNI_CONF=1 (lo spiegherò tra un attimo).

Il certificato di default per qmail ($QMAILDIR/control/servercert.pem file) è il risultato della concatenazione della chiave privata e della fullchain. In $QMAILDIR/control/servercert.pem viene installato il primo certificato (prima riga in domains.txt), a condizione che si sia posto MAKE_MAIL_CERTS=1. I certificati SSL per domini specifici che sono raggiungibili sotto nomi differenti quando il client supporta SNI vengono invece installati in $QMAILDIR/control/servercerts/<FQDN>/servercert.pem a condizione che si sia posto ENABLE_SNI=1.

Per quanto riguarda Dovecot, è necessario impostare correttamente l'indirizzo del certificato di default nel proprio file local.conf:

ssl_server_cert_file = /etc/dehydrated/certs/mx.mydomain.tld/fullchain.pem
ssl_server_cert_file = /etc/dehydrated/certs/mx.mydomain.tld/privkey.pem

hook.sh definisce i certificati addizionali in sni.conf (non modificarlo manualmente); questi vengono presentati a secondo dell'hostname del client secondo la logica SNI. Come già detto, ciò è disabilitato se ENABLE_SNI=0.

Per quanto riguarda Apache, ENABLE_APACHE_SNI_CONF=1 farà in modo che lo script hook.sh popoli un file con le righe ServerName e ServerAlias per tutti i domini in domains.txt, per esempio:

ServerName  domain1.tld                                                    --> primo dominio della prima riga in domains.txt
ServerAlias             imap.domain1.tld pop3.domain1.tld smtp.domain1.tld --> SAN nella riga 1
ServerAlias domain2.tld imap.domain2.tld pop3.domain2.tld smtp.domain2.tld --> domaini della riga 2
ServerALias domain3.tld imap.domain3.tld pop3.domain3.tld smtp.domain3.tld --> domaini della riga 3
...

Per attivare la logica precedente definire APACHE_SNI_CONF=/etc/httpd/sni.conf, ovvero il file con le righe ServerName e ServerAlias (non modificarlo manualmente poichè viene rigenerato sulla base del contenuto di domains.txt ogni volta che si lancia dehydrated -c). Ora importare questo file nel VirtualHost di apache che deve gestire i challenge di dehydrated:

<VirtualHost *:80> 
  Include /etc/httpd/sni.conf
  Include ${REDIRECT}
</VirtualHost>

Pubblicazione dei certificati e sincronizzazione della configurazione

Avrai probabilmente notato la presenza di altri due eseguibili: cert-sync e dehydrated-renew:

• cert-sync serve a sincronizzare la configurazione di qmail, Dovecot e eventualmente apache quando si è modificato il file domains.txt, senza bisogno di lanciare dehydrated -c. Quindi, se si è cancellato un dominio da domains.txt o se si è riorganizzato il SAN di uno di essi, senza toccare i certificati esistenti, è possibile lanciare questo script.
• dehydrated-renew è un wrapper di dehydrated pensato per il cronjob, che uno di seguito all'altro chiama dehydrated -c -g, sincronizza la configurazione SNI di qmail, Dovecot e apache e infine ricarica i server sono nel caso i certificati siano stati pubblicati.
  E' usato al fine di evitare di riavviare i servizi ogni volta che un certificato viene pubblicato (che è il comportamento di default di dehydrated), cosa non gradita se si hanno centinaia di righe in domains.txt. L'opzione -g (--keep-going) è importante per non iterrompere il processo quando si incontra un problema nella creazione o pubblicazione di uno dei certificati in modalità cron.
  Si possono passare anche altre opzioni a dehydrated-renew, per esempio dehydrated-renew -x forza la rigeneraziobe dei certificati anche se non sono scaduti.

Siamo ora pronti a lanciare

/etc/dehydrated/scripts/dehydrated-renew

Verificare che il certificato per qmail e i file di configurazione SNI siano stati popolati come da programma. Quindi eliminare da domains.txt i domini zombie di cui non si è più dns autoritativo o mx, poichè quei domini causano warning e rallentano inutilmente il processo di creazione dei certificati. Eseguire dei test di invio e ricezione. Quando tutto è ok si può impostare dehydrated perchè si colleghi all'autorità letsencrypt correggendo il parametro CA:

CA="letsencrypt"

in /etc/dehydrated/config.d/local.sh file. Quindi lanciare dehydrated-renew per l'ultima volta.

Cronjob setup

Let's Encrypt raccomanda di rinnovare i certificati automaticamente quando manca un terzo del loro tempo totale di validità alla scadenza. Poichè il certificato è valido per 90 giorni, è necessario rinnovarlo 30 giorni prima della scadenza. Creiamo quindi un cronjob che giri una volta al mese:

cat > /etc/cron.d/dehydrated << __EOF__
40 2 6 * * root /etc/dehydrated/scripts/dehydrated-renew >> /var/log/dehydrated 2>&1
__EOF__

E' ora possibile rimuovere la vecchia linea update_tmprsadh dal crontab.

---

Installazione di certbot

La documentazione su certbot non è più aggiornata in quanto soppiantata da quella basata su dehydrated. Viene lasciata intatta in caso possa ancora essere di aiuto a qualcuno.

Qui di seguito viene spiegato come installare e configurare un certificato SSL valido di Let's Encrypt per i server qmail e dovecot. L'installazione è ad opera del client certbot.

Certbot is part of EFF’s effort to encrypt the entire Internet. Secure communication over the Web relies on HTTPS, which requires the use of a digital certificate that lets browsers verify the identity of web servers (e.g., is that really google.com?). Web servers obtain their certificates from trusted third parties called certificate authorities (CAs). Certbot is an easy-to-use client that fetches a certificate from Let’s Encrypt—an open certificate authority launched by the EFF, Mozilla, and others—and deploys it to a web server.

Maggiori informazioni qui:

• https://certbot.eff.org/docs/
• https://letsencrypt.org/ 

Innanzitutto è necessaria una versione di python v.3, e poi vi sono una marea di prerequisiti, perciò è consigliabile lasciar fare l'installazione al package manager della propria distribuzione. Per gli utenti Slackware c'è uno sclackbuild pronto su SBO qui e se non si ha voglia di risolvere manualmente tutte le dipendenze si può sempre usare sbotools.

Installazione del certificato

Naturalmente il certificato viene rilasciato dopo che si è data prova delle affettiva proprietà del dominio associato al certificato. Pertanto certbot dovrà installare una "ACME challenge" (ovvero un file con un nome riconoscibile) in una directory a nostra scelta dove far girare un webserver temporaneo e recuperare l'ACME via http. Se tutto va a buon fine il certificato verrà installato in /etc/letsencrypt.

Creiamo quindi la cartella dove "webroot" la ACME challenge dovrà essere salvata:

mkdir -p /path/to/webroot

Creare un virtual host apposito su apache. yourdomain.tld è il dominio al quale faremo la connessione smtp e imap/pop3:

<VirtualHost *:80>
 ServerName yourdomain.tld

DocumentRoot /path/to/webroot
 <Directory /path/to/webroot>
   Require all granted
 </Directory>
</VirtualHost>

Prepariamo uno script per installare i certificati via certbot in /usr/local/bin/my_certbot.sh: 

cat > /usr/local/bin/my_certbot.sh << __EOF__
#!/bin/sh
#

CERTBOT=/usr/bin/certbot
DOMAIN=mydomain.tld

\$CERTBOT certonly \\
 --webroot \\
 --webroot-path /path/to/webroot \\
 --preferred-challenges http-01 \\
 --key-type rsa \\
 -d \${DOMAIN} \\
 --email myemail@\${DOMAIN} \\
 --renew-by-default \\
 --agree-tos \\
 --text

# qmail cert
if [ ! -d "/var/qmail/control/certs_backup" ]; then
 mkdir -p /var/qmail/control/certs_backup
fi
cp -p /var/qmail/control/*.pem /var/qmail/control/certs_backup/
cat /etc/letsencrypt/live/\${DOMAIN}/privkey.pem /etc/letsencrypt/live/\${DOMAIN}/fullchain.pem > /var/qmail/control/servercert.pem
chown vpopmail:vchkpw /var/qmail/control/*.pem 
chmod o-r /var/qmail/control/*.pem
/usr/local/bin/qmailctl restart

# dovecot cert (you have to set the path inside 10-ssl.conf accordingly)
/usr/local/bin/dovecotctl restart
__EOF__

chmod +x /usr/local/bin/my_certbot.sh

mydomain.tld sarà usato come nome del certificato stesso. Per conoscere meglio cosa può fare certbot si può digitare:

certbot --help all

Ricordiamoci infine di settare la x flag:

chmod +x /usr/local/bin/my_certbot.sh

Possiamo quindi eseguire lo script e se non vi saranno errori avremo ottenuto il nostro certificato.

Infine settiamo un cronjob per rinnovare il certificato una volta al mese (la validità è di 3 mesi):

15 2 20 * * /usr/local/bin/my_certbot.sh >> /var/log/cron

Ricordare di disabilitare la linea di update_tmprsadh nel crontab.

Configurazione di qmail e dovecot

Per quanto riguarda qmail la private key e la fullchain devono essere unite in un unico file /var/qmail/control/servercert.pem. Questo viene fatto dallo script di cui sopra e non deve essere fatto altro.

Riguardo a dovecot invece, è sufficiente modificare il file di configurazione /usr/local/dovecot/etc/dovecot/conf.d/10-ssl.conf come segue:

#ssl_cert = </etc/ssl/certs/dovecot.pem
#ssl_key = </etc/ssl/private/dovecot.pem
ssl_cert = </etc/letsencrypt/live/yourdomain.tld/fullchain.pem
ssl_key = </etc/letsencrypt/live/yourdomain.tld/privkey.pem

Ora riavviare qmail e dovecot per abilitare il nuovo certificato.