Traduction de la page : https://workaround.org/ispmail/stretch/letsencrypt-certificate

(Si vous n'êtes pas familiarisé avec l'abbréviation « TLS » : c'est le successeur de SSL.)

L'Internet est la plus belle invention depuis le pain en tranches mais il est devenu un endroit infernal, plus qu'il ne l'a jamais été. Nous avons affaire à grande échelle à des script kiddies, des services secret incontrôlés et des organisations criminelles. Il est totalement hors de question de faire tourner des services non chiffrés sur Internet. Je considère qu'un mot de passe envoyé en clair sur Internet est immédiatement perdu. Nous allons donc créer une clé de chiffrement et certificat pour Postfix (SMTP), Dovecot (IMAP/POP3) et Roundcube (Webmail/HTTPS).

Vous me direz peut-être qu'utiliser une connexion chiffrée entre l'ordinateur de l'utilisateur et le serveur de mail est futile. Après-tout le mail est ensuite transféré vers un autre serveur de mail en clair. Bien que cela puisse être vrai pour quelques serveurs de mail, la plupart des administrateurs s'efforcent d'utiliser TLS également dans les communications entre serveurs.  Vous ne pouvez pas compter là-dessus pour des correspondances confidentielles, mais c'est mieux que rien. Anecdote amusante : il n'y a pas très longtemps deux grands fournisseurs allemands de mails gratuits on fondée une alliance « email fait en Allemagne ». Devinez le truc sympa qu'ils ont fait pour rendre le monde meilleur... ils ont activé TLS.  🙂

Avertissement : N'utilisez pas des certificats différents pour Postfix et Dovecot. Le client de Mail de MacOS refuserait la connexion avec des messages d'erreur trompeurs, et il est possible que d'autres clients de Mail se plaignent également.

Pourquoi faire en sorte que les clients de messagerie aient confiance dans un certificat ?

Inclue dans votre navigateur favorit il existe dans le monde une liste d'autorités de certification « de confiance ». Oui votre navigateur fait confiance à des sociétés dont vous n'avez sans doute jamais entendu parler. Et c'est la même chose avec votre client de messagerie. Il y a quelques décennies des sociétés ont oeuvré pour convaincre les développeurs de navigateurs Internet de faire en sorte que leurs navigateurs fassent confiance à tous les certificats signés par ces sociétés. Ces certificats étaient techniquement les mêmes que les certificats auto-signés. Ils portaient juste une signature créée par un ordinateur d'une certaine société. La plupart du temps il n'y a aucune vérification humaine de la demande de signature. Je considère le système actuel de certificats comme défectueux.

Dans le précédent guide pour Debian Jessie il y a un long développement comparant les certificats auto-signés, les sociétés de PKI, Let's Encrypt et les certificats payants. Pour faire plus court, nous allons utiliser Let's Encrypt. Il n'y a aucune raison de donner de plus en plus d'argent à la mafia des certificats. Pourquoi les comparer à la mafia ? Parce que c'est tout à fait mauvais d'échanger de l'argent contre de la confiance. Et l'histoire récente de quelques échecs maladroits montre qu'ils ne méritent aucune confiance. Même ma bonne vieille autorité de certification préférée StartSSL (parce qu'ils produisaient des certificats gratuits) a si terriblement failli que la majorité des navigateurs considèrent maintenant qu'on ne peut plus avoir confiance en leurs certificats. Et tout récemment ils ont même arrêté leur activité.

Let's Encrypt est un projet sans but lucratif lancé par une société californienne appelée ISRG (Internet Security Research Group). Ils planifiaient de mettre en place une infrastructure permettant finalement à toute personne dans le monde d'obtenir un certificat « de confiance » gratuitement. Leur certificat d'autorité est désormais installé parmi les certificats de confiance par la plupart des navigateurs Internet et autres logiciels, comme les clients de messagerie. Si votre patron vous pose la question… Leurs certificats sont techniquement aussi sûrs q'un certificat auto-signé. Et non, il n'y a aucune raison de jamais payer un nouveau certificat. Pourquoi les autres le font encore ? Selon toute vraissemblance parce qu'ils sont victimes du marketing et du FUD.

Le certificat sera utilisé par trois logiciels :

1. L'interface webmail (affichée par Apache)
2. Postfix (pour l'identification pendant les communications SMTP avec vos utilisateurs)
3. Dovecot (Pour l'identification pendant les communications IMAP)

Préparation du serveur web Apache pour HTTP

Commençons par Apache. Votre serveur peut être utilisé pour plusieurs hôtes virtuels par nom (name-based virtual hosts). Cela signifie simplement que votre serveur web peut différencier quel fichier il est censé envoyer au client en fonction du nom de domaine utilisé dans l'URL. Comme exemple je supposerai que vous désirez permettre à vos utilisateurs d'utiliser le nom d'hôte webmail.example.org. Bien entendu votre serveur aura un autre nom dans un domaine sur lequel vous avez la main. J'utiliserai cet exemple tout au long de ce guide et conserverai ce nom écrit en gras pour vous rappeller que vous devrez utiliser à la place votre propre nom de domaine.

Pour commencer vous aurez besoin d'un répertoire racine pour ce nom d'hôte :

mkdir /var/www/webmail.example.org

Ensuite vous devrez créer un fichier de configuration d'hôte virtuel correspondant. Apache utilise sur Debian un système propre à cette distribution pour gérer les hôtes virtuels :

• /etc/apache2/sites-available/*.conf contient deux fichiers de configuration par défaut. 000-default.conf est un fichier de configuration d'hôte virtuel HTTP et default-ssl.conf est un fichier de configuration d'hôte virtuel HTTPS. Vous pouvez créer tous les fichiers que vous désirez dans ce répertoire. Apache ne les prendra pas en compte automatiquement.
• /etc/apache2/sites-enabled/*.conf contient des liens symboliques (“symlinks”) qui pointent sur les fichiers de configuration dans le répertoire  /etc/apache2/sites-available directory. Only *.conf. Ce sont les liens figurant dans ce répertoire qui seront chargés par Apache.

Ce système vous permet d'activer et de désactiver les hôtes virtuels sans avoir à effacer aucune configuration. Debian est fournie avec deux commandes  a2ensite (raccourci pour apache2 enable site) et a2dissite. En plus de quelques contrôles de validité des configuration ces commandes ont pour rôle essentiel de créer ou effacer les liens symboliques entre les répertoires sites-available et sites-enabled.

Note : les fichiers de configuration doivent comporter un suffixe en .conf sinon ils ne seront pas pris en compte.

Vous pouvez retirer les liens symboliques par défaut dans /etc/apache2/sites-enabled/* à moins que vous ne les utilisiez déjà.

Créez un nouveau fichier de configuration d'hôte virtuel /etc/apache2/sites-available/webmail.example.org-http.conf dans lequel vous écrirez :

<VirtualHost *:80>
  ServerName webmail.example.org
  DocumentRoot /var/www/webmail.example.org
</VirtualHost>

Cette simple configuration a pour effet qu'Apache répond aux requêtes (sur le port standard TCP 80)  si il trouve dans le requête du navigateur une ligne contenant Host: webmail.example.org. C'est la façon qu'a votre navigateur d'indiquer au serveur web Apache le nom de domaine qu'il recherche. Ce mécanisme autorise la présence de multiples sites sur une seule adresse IP. (D'ailleurs ceci fonctionne également de nos jours pour HTTPS grâce à un mécanisme appelé Server Name Indication.

Activez l'hôte virtuel HTTP :

a2ensite webmail.example.org-http

Vous obtiendrez le message suivant :

To activate the new configuration, you need to run:
 systemctl reload apache2

Le message indique que pour qu'Apache prenne en compte cette nouvelle configuration il faut l'obliger à relire ses fichiers de configuration avec la commande indiquée, faites-le .

Vérifions que le configuration fonctionne. Plaçons un fichier de test à la racine de votre hôte virtuel :

echo "Just a test" > /var/www/webmail.example.org/test

Maintenant quand vous saisissez dans la barre d'url de votre navigateur  http://webmail.example.org/test vous devriez voir affiché “Just a test”.

C'est une configuration suffisante pour permettre à Let's Encrypt d'émettre pour vous un certificat.

Obtenir un certificat Let's Encrypt

Debian Stretch propose l'outil le plus courant de gestion des certificats Let's Encrypt : certbot. Installez-le :

apt install certbot

Pour obtenir un certificat pour votre nom de domaine lancez la commande :

certbot certonly --webroot --webroot-path /var/www/webmail.example.org -d webmail.example.org

La première fois que vous lancerez cette commande il vous sera demandé votre adresse mail afin que let's Encrypt puisse vous envoyer des mails de rappel pour vous prévenir de l'expiration prochaine de votre certificat. Vous devrez également accepter les conditions d'utilisation de leur service.

Si tout s'est bien passé vous devriez voir s'afficher une sortie ressemblant à ça :

Saving debug log to /var/log/letsencrypt/letsencrypt.log
Obtaining a new certificate
Performing the following challenges:
http-01 challenge for webmail.example.org
Using the webroot path /var/www/webmail.example.org for all unmatched domains.
Waiting for verification...
Cleaning up challenges
Generating key (2048 bits): /etc/letsencrypt/keys/0049_key-certbot.pem
Creating CSR: /etc/letsencrypt/csr/0049_csr-certbot.pem

IMPORTANT NOTES:
- Congratulations! Your certificate and chain have been saved at
  /etc/letsencrypt/live/webmail.example.org/fullchain.pem. Your
  cert will expire on 2018-04-01. To obtain a new or tweaked version
  of this certificate in the future, simply run certbot again. To
  non-interactively renew *all* of your certificates, run "certbot
  renew"
- If you like Certbot, please consider supporting our work by:

  Donating to ISRG / Let's Encrypt: https://letsencrypt.org/donate
  Donating to EFF: https://eff.org/donate-le

Peut-être vous demandez-vous ce qui s'est réellement passé ? Et bien, certbot a créé une clé privée et secrète que seul votre serveur peut connaître. Il a alors placé un certain fichier dans /var/www/webmail.example.org/.well-known/… et l'a fait vérifier par le service Let's Encrypt qui a visité votre site. C'était une preuve suffisante que vous possédez le domaine (parce que vous avez le contrôle sur la zone DNS) et parce que vous avez accès au serveur web. 

Apache et HTTPS

Les connexions HTTP non chiffrées ne sont plus une option acceptable de nos jours. Et maintenant que nous avons un certificat, ajoutons un hôte virtuel qui puisse recevoir les requêtes HTTPS.

Créez un nouveau fichier de configuration /etc/apache2/sites-available/webmail.example.org-https.conf contenant :

<VirtualHost *:443>
 ServerName webmail.example.org
 DocumentRoot /var/www/webmail.example.org
 SSLEngine on
 SSLCertificateFile /etc/letsencrypt/live/webmail.example.org/fullchain.pem
 SSLCertificateKeyFile /etc/letsencrypt/live/webmail.example.org/privkey.pem
</VirtualHost>

Cette configuration d'hôte virtuel ressemble furieusement à celle de l'hôte virtuel HTTP configuré plus haut. Simplement elle écoute sur le port 443 (le port standard pour HTTPS) au lieu du port 80. Elle active le mode ssl d'Apache (SSLEngine) qui s'occupe du chiffrement  et elle récupère les informations du certidicat de votre serveur web (qui est fourni aux autres utilisateurs) et la clé privée (que le serveur web utilise pour déchiffrer les envois des utilisateurs). T

Activez l'hôte virtuel HTTPS:

a2ensite webmail.example.org-https

Et pour rendre disponible pour Apache le module SSL :

a2enmod ssl

Et rechargez de nouveau la configuration :

systemctl reload apache2

Maintenant quand vous pointez sur votre serveur web à l'adresse « https://webmail.example.org » votre navigateur devrait dire qu'il fait confiance au certificat de votre site :

(D'accord ce n'est pas le domaine webmail.example.org. Mais comme je ne possède pas le domaine example.org et du coup ne peux obtenir un certificat valide pour ce domaine, j'ai utilisé mon propre site. )

Du coup devez-vous garder l'hôte virtuel HTTP ? Oui, vous allez l'utiliser pour rediriger vos utilisateurs sur la version HTTPS si ils ont oublié de mettre https:// devant leur URL. Et Let's Encrypt a toujours besoin de http. Alors quelle est la solution ?

Renouvellement automatique

Obtenir un certificat ne représente que la moitié de la bataille. Les certificats de Let's Encrypt expirent au bout de 90 jours. Du coup pouvoir renouveler les certificats automatiquement et dans les temps est vital. Le paquet certbot ajoute une tâche cron dans /etc/cron.d/certbot à cet usage. Il est lancé deux fois par jour et après un délai aléatoire (de manière à ce que le service Let's Encrypt ne reçoive pas trop de requêtes en même temps) vérifie si il existe des certificats à renouveler. On obtient ce résultat avec la commande certbot -q renew. Le -q signifie silencieux (ndt : quiet en anglais) et éviter que vous receviez deux emails par jour vous disant ce que certbot a fait.

Il manque encore une pièce au puzzle. Même si le renouvellement fonctionne il va simplement mettre à jour le fichier de certificat. Mais les logiciels (Postfix, Dovecot et Apache) ne s'apercevront pas du changement. Nous avons donc besoin d'ajouter ce que certbot appelle post-hook qui redémare tous les service concernés après une mise à jour.

Créez un simple script shell dans /usr/local/bin/certbot-post-hook contenant :

#!/bin/sh
service postfix restart 2>/dev/null
service dovecot restart 2>/dev/null
service apache2 restart 2>/dev/null

Rendez ce script exécutable :

chmod u+x /usr/local/bin/certbot-post-hook

Lancez-le pour le tester :

/usr/local/bin/certbot-post-hook

Il ne va rien afficher. Il devrait juste tourner sans erreur et redémarrer les trois services qui utilisent le certificat. Vous n'aurez plus qu'à ajouter ce script au lancement de certbot renew avec l'option –post-hook /usr/local/bin/certbot-post-hook

Maintenant tout va dépendre de la façon dont le renouvellement va être activé, par cron ou par systemd. Si vous utilisez Debian Jessie ou Debian Strech vote serveur utilise systemd. Certbot sait utiliser ces deux approches, mais il faut faire attention à ne pas mettre les options au mauvais endroit. Regardes le fichier /etc/cron.d/certbot :

0 */12 * * * root test -x /usr/bin/certbot -a \! -d /run/systemd/system && perl -e 'sleep int(rand(3600))' && certbot -q renew

La partie en gras signifie que cron vérifie si vous utilisez systemd. Si vous le faites, il n'exécutera pas le renouvellement ici et laissera ce travail à systemd. Dans ce cas, vous pouvez éditer le fichier /lib/systemd/system/certbot.service à la place :

[Unit]
Description=Certbot
Documentation=file:///usr/share/doc/python-certbot-doc/html/index.html
Documentation=https://letsencrypt.readthedocs.io/en/latest/
[Service]
Type=oneshot
ExecStart=/usr/bin/certbot -q renew
PrivateTmp=true

Vous pourriez être tenté de simplement modifier ici la ligne ExecStart. Mais à la prochaine mise à jour de certbot vos modifications seraient effacées. À la place copiez ce fichier dans /etc/systemd/system/

cp /lib/systemd/system/certbot.service /etc/systemd/system/

Modifiez ainsi la ligne ExecStart dans le fichier copié :

ExecStart=/usr/bin/certbot -q --post-hook /usr/local/bin/certbot-post-hook renew

Après cela relancez systemd

systemctl daemon-reload

Vous pouvez également vérifier que votre modification est prise en compte à l'aide de la commande :

systemctl cat certbot

Pour être certain que le renouvellement fonctinnera vous pouvez simuler la précédure en lançant :

certbot --dry-run --post-hook /usr/local/bin/certbot-post-hook renew

Bien joué. Nous avez installé Let's Encrypt pour tous vos services. Maintenant continuons.