Cet article a été publié il y a 5 ans 4 mois 15 jours, il est donc possible qu’il ne soit plus à jour. Les informations proposées sont donc peut-être expirées.Petit aide mémoire et astuces pour avoir des certificats qui vont bien dans un environnement postfix/dovecot ; et non pas des certif auto-signés comme vous avez peut-être.
Dernièrement, en voulant configurer un iFoune pour atteindre un serveur de mails à moi (tournant sur postfix/dovecot), j’ai vu que l’option « accepter tous les certificats » n’était plus de ce monde. Peut-être que Appeul a décidé que le SSL étant tellement basique maintenant, il n’y avait plus aucune raison d’avoir des certificats moisis (par exemple ceux auto-signés qu’on a à la création d’un postfix/dovecot). C’est pas faux.
Sauf que ça me faisait suer, car j’avais gardé en tête que postfix ne sait pas gérer du multi-certificats suivant le nom de domaine de mails. Techniquement, c’est une histoire de SNI pas supporté par postfix dans TLS. J’abrège, mais l’idée est là. Donc soit on fait une instance smtpd par domaine, avec obligatoirement une IP dédiée (ça peut être très lourd d’avoir plein d’IP juste pour ça), soit on trouve une autre ruse.
Une ruse serait de faire utiliser touours le même smtp.domaine.com et imap.domaine.com pour la configuration de toutes vos boîtes mails, qu’elles soient sur domaine.com ou autre_domaine.com. Mais c’est moins classe car si on veut scinder un peu, on préfèrera expliquer à Mr autre_domaine.com que sont imap est bien imap.autre_domaine.com et pas un truc qu’il ne connait pas forcément et qui s’appelle domaine.com.
La ruse la plus simple consiste donc à générer un certificat (par exemple par « let’s encrypt », cf. mes articles précédents sur le sujet) contenant tous les noms des FQDN dont vous avez besoin : smtp.domaine.com et imap.domaine.com et smtp.autre_domaine.com et imap.autre_domaine.com etc imap.machinbidule.com…
Ce « super certificat » sera tout à fait valide. Le seul hic à la limite est que si on interroge le certificat (exemple : true | openssl s_client -connect smtp.domaine.fr:465 | openssl x509 -noout -text | grep DNS: Alors on récupère tous les alias, ce qui quelque part indique sur un serveur tous les domaines que vous gérez… Bon, est-ce des gens vont voir et exploiter ça d’une quelconque manière ? si votre serveur est de toute manière protégé (iptables, fail2ban etc), on peut supposer que ça ne change pas grand chose.
Pour ce faire dans letsencrypt / dehydrated, vous indiquez simplement la liste des noms de domaines sur la même ligne du fichier domains.txt. Vous générez votre certificat, ça prend un peu de temps le temps de réussier tous les « challenges » d’authentification de letsencrypt. A la fin, vous avez un cert.pem et un privkey.pem que vous indiquez dans la conf de 1) postfix/main.cf dans les paramètres smtpd_tls_cert_file et smtpd_tls_key_file et vous indiquez le chain.pem dans smtpd_tls_CAfile et 2) pour la partie IMAP, dans dovecot/conf.d/10-ssl.conf dans les paramètres ssl_cert et ssl_key
Pour Dovecot, afin d’avoir les informations complètes de la « chaîne » d’authentification des certifs, la doc dit :
Put all the certificates in the ssl_cert file. For example when using a certificate signed by TDC the correct order is:
Dovecot’s public certificate
TDC SSL Server CA
TDC Internet Root CA
Globalsign Partners CA
Il faut donc présenter le fullchain.pem en guise de certif public, et non pas le cert.pem tout seul, nin le chain.pem tout seul.
Et voilà, avec la commande openssl mentionnée ci-dessus, vous pouvez tester que tout semble bien – après un restart des services.
Et si vous avez planifié votre regénération des certifs letsencrypt en crontab, pensez à ajouter un reload des services postfix et dovecot.
Et testez que tout va bien :
https://www.sslshopper.com/ssl-checker.html#hostname=smtp.gmail.com:465 en remplaçant par votre smtp:465 et ou imap:993.