SSL/TLS sur un serveur mail multi-domaines avec Postfix et Dovecot

Tout le monde a l'habitude de configurer plus ou moins correctement le s de HTTPs. Ce s, c'est le chiffrement SSL/TLS basé sur une paire de certificats x509. On le retrouve aussi sur d'autres protocoles communs, mais HTTPs est le cas le plus simple :

il n'y a que SSL/TLS sur le port 443, pas de STARTTLS sur le 80;
le client annonce dans sa requête le nom de domaine sur lequel il se connecte. Le serveur peut donc s'adapter en fonction, c'est le système des virtualhost.

Qu'en est-il des serveurs mail ? SMTP, IMAP4 et POP3 sont des protocoles fonctionnant différemment de HTTP. Dans ces protocoles, le client n'annonce pas le nom de domaine sur lequel il se connecte. Impossible pour le serveur de procéder comme en HTTP et disposer d'une configuration différente en fonction du domaine, autrement dit de gérer des vhost.

Mais alors comment gérer les certificats x509 pour chaque nom de domaine géré ?

Pour l'exemple, prenons un serveur gérant deux clients, toto.com et tata.com (toute ressemblance avec des marques existantes ou ayant existé ne serait que pure coïncidence). Postfix et Dovecot sont d'ores et déjà configurés pour gérer les mails en direction de ces deux domaines. On veut maintenant pouvoir se connecter indifféremment en IMAP sur imap.toto.com et imap.tata.com, et en SMTP sur smtp.toto.com et smtp.tata.com, le tout de manière chiffrée avec SSL/TLS ou avec STARTTLS.

Pour ça, il faut que d'une façon ou d'une autre, Postfix et Dovecot soient capables de servir deux certificats x509 (un pour tata.com et un pour toto.com). Voyons comment.

Solution 1 : laisser tomber

Eh oui, la solution qui revient le plus souvent sur les forums, c'est de laisser tomber. En gros, se contenter de ne gérer qu'un domaine principal (imap.sysnove.fr et pop.sysnove.fr, par exemple), et de dire aux clients d'utiliser ces informations pour configurer leur logiciel de messagerie.

Problème : quand un utilisateur entre l'adresse nom@domaine.fr, les logiciels de messagerie utilisent justement imap.domaine.fr et smtp.domaine.fr pour s'auto-configurer. Donc gérer imap., pop3. et smtp. pour chaque domaine mail que vous gérez, ça peut être utile.

Solution 2 : plusieurs certificats dans le même crt+chain

Puisque, dans leur configuration, Postfix et Dovecot ne gèrent a priori qu'un fichier de certificat x509, pourquoi ne pas mettre plusieurs certificats dans le même fichier ?

Réponse : parce que ça ne marche pas ! :)

Solution 3 : SAN

SAN, ou Subject Alternative Names, est une technique permettant de placer plusieurs noms de domaine dans un même certificat x509.

Attention, ici je ne parle pas de wildcard, qui consiste à mettre un nom, *.toto.com par exemple, qui permet de couvrir tous les sous-domaines de toto.com, mais qui ne permettra jamais de couvrir à la fois toto.com et tata.com. On ne peut pas émettre de wildcard sur *.com, et heureusement.

Je parle de mettre plusieurs noms dans un même certificat, dans une entrée qui se nomme SubjectAlternativeNames. C'est vraiment très pratique, mais qui a deux inconvénients qu'il faut connaitre :

Pour émettre des certificat ayant cette entrée, il faut souvent payer plus cher que pour des certificats classiques. Chez StartSSL par exemple, il faut avoir validé son identité pour émettre des certificats class2, ça coute une cinquantaine d'euros alors que les class1 sont gratuits. C'est souvent le même prix que pour émettre des wildcard.
C'est pénible à mettre à jour. Typiquement chez StartSSL, on ne peut émettre qu'un certificat par nom de domaine. Donc maintenant que vous avez émis un certificat couvrant imap.toto.com, smtp.toto.com, imap.tata.com et smtp.tata.com, comment faire si vous voulez lui ajouter imap.titi.fr et smtp.titi.fr ? Vous êtes obligés de révoquer le certificat précédent, et d'en faire signer un nouveau avec les 2 nouveaux noms et les 4 anciens. Chez StartSSL, ça coûte environ 25€, et ça causera une rupture de service durant tout le temps qui séparera la révocation de l'ancien certificat et la création puis l'installation du nouveau sur les serveurs.

Donc SAN, c'est bien si vous n'avez pas prévu d'ajouter de nouveaux domaines, ce qui est peu probable.

Solution 4 : SNI

SNI, pour Server Name Indication, est une extension du protocole TLS consistant à demander au client de spécifier le domaine sur lequel il se connecte, pour permettre au serveur de présenter le bon certificat. Le concept est donc le même que les virtual hosts en HTTP.

SNI n'a qu'un problème, c'est qu'il est très récent. La RFC date de 2003. Et comme c'est un bout de protocole sous forme d'extension, il faut qu'il soit géré à la fois par le serveur et par les clients. Malheureusement :

coté serveur, Dovecot le gère mais pas Postfix (et ça n'est pas prévu)
coté client, Android 2.x ne le gère pas.

Pour Postfix, on pourrait résoudre le problème en mettant un proxy Nginx en frontend Submission, qui s'occuperait de chiffrer la connexion avec SNI. Mais coté client, c'est vraiment une source à problème. Car nous n'en avons pas parlé, mais que se passe t'il si le client est trop vieux et ne gère pas SNI, voire pire, ne gère que SSL ? Et bien il va aboutir à une erreur de sécurité, et refusera de se connecter.

C'est donc une solution à suivre, mais aujourd'hui ça n'est pas une solution à moins que vous maitrisiez bien votre parc d'utilisateurs.

Solution 5 : Proxy

Enfin, la dernière solution consiste à mettre un proxy IMAP/SMTP/POP3 pour chaque client. Ça peut se configurer simplement avec Nginx par exemple. C'est de loin la solution la plus propre, et on peut facilement répartir la charge puisque chaque client est sur sa propre IP. Mais ça vous coutera une adresse IP par client, ce qui n'est pas négligeable aujourd'hui.

Conclusion

En conclusion, on peut vraiment dire que ça n'est pas simple. Il y a plusieurs solutions, il faudra choisir laquelle en fonction de votre cas.

SAN est clairement adaptée si vous êtes certains de ne jamais gérer de nouveaux domaines dans votre système.
Si vous ajoutez des domaines régulièrement pour des clients, le proxy est une solution, à condition de pouvoir ajouter des IP facilement sur son serveur.
Enfin, envisagez peut-être la solution 1, « laisser tomber ». Ça simplifiera la vie de tout le monde. Il faudra simplement bien documenter la configuration des clients mails. C'est le choix qu'a fait Gmail, ça n'est pas pour rien…

À propos de l'auteur

Guillaume est l'un des deux fondateurs et cogérants de Sysnove. Développeur Python et administrateur système passionné de logiciel libre et des technologies liées à Internet, il participe à divers projets, notamment le fournisseur d'accès Internet Aquilenet ainsi que la Fédération FDN.

Chez Sysnove, son rôle consiste à mettre en place et administrer les infrastructures nécessaires à l'hébergement des services fournis aux clients. En tant que directeur général, il gère aussi les aspects administratifs de l'entreprise.