Question Alternative à postfix avec certificats SNI + compatibilité Dovecot


Comme nous le savons, postfix ne prend pas en charge SNI (Indication du nom du serveur), ce qui signifie que si vous définissez un certificat, celui-ci sera utilisé pour tous les noms de domaine que vous avez sur ce serveur, ce qui pourrait être mauvais pour des personnes non prêt à payer beaucoup pour acheter des certificats de fantaisie. Postfix déclare sur son site Web qu’ils ne prévoient pas de mettre en œuvre SNI.

Mon serveur de messagerie est configuré avec Dovecot et Postfix. Je voudrais remplacer postfix par quelque chose qui supporte SNI et compatible avec Dovecot (ou au moins accepte le même schéma de base de données de noms d’utilisateur / mot de passe de Dovecot).

Pourriez-vous me dire quelles sont les alternatives à postfix qui remplissent ces conditions (de préférence open source).


7
2017-11-27 20:44


origine


Pouvez-vous expliquer le scénario dans lequel un seul certificat pour un seul nom ne suffirait pas dans le contexte de smtps? Je pense que ce scénario est au mieux incertain et je suppose que c'est la raison pour laquelle il n'est pas pris en charge. - Håkan Lindqvist
Bonjour, pourquoi avez-vous besoin du support SNI pour votre smtpd? La seule chose qui doit correspondre pour la vérification SSL est le CN sur le certificat SSL qui correspond au nom d'hôte de la bannière. Les certificats SSL sont tellement ridiculement bon marché maintenant (<50 USD / an) Je trouve votre argument difficile à accepter. - Andrew Domaszek
De plus, votre ptr DNS inversé doit correspondre au nom d’hôte de votre bannière pour de nombreux services de messagerie afin de ne pas vous rejeter comme spameur. - Andrew Domaszek
@TheQuantumPhysicist Mais pour smtp w / TLS le certificat serait pour le nom du serveur de messagerie, pas tous les noms de domaine traités par le serveur de messagerie. - Håkan Lindqvist
@TheQuantumPhysicist serverfault.com/questions/389413/… semble couvrir ce sujet - Håkan Lindqvist


Réponses:


Si vous connaissez déjà tous les noms de domaine complets dont vous allez avoir besoin, achetez un certificat SAN.

Si vous avez besoin de flexibilité avec vos certificats, vous pouvez essayer de configurer un proxy nginx smtp. J'ai regardé la documentation et, d'après l'apparence, il devrait prendre en charge SNI, mais ce ne sera pas une configuration facile, je pense: http://nginx.org/en/docs/mail/ngx_mail_ssl_module.html

1ère mise à jour:
deux liens qui pourraient vous aider:
http://citrin.ru/nginx:ngx_mail_core_module
http://wiki.nginx.org/MailCoreModule 

2ème mise à jour:
À partir de 2016, vous pourrez facilement obtenir des certificats SAN auprès du Cryptons Projet pour libre.

Je vous suggère fortement de vous procurer un certificat SAN et d'inclure dans ce certificat tous les noms de domaine complets dont vous avez besoin pour votre service. Actuellement, vous pouvez inclure jusqu'à 100 noms alternatifs de sujet par certificat.


7
2017-11-28 13:10



Nginx est une bonne idée mais ce n'est pas gratuit, n'est-ce pas? - The Quantum Physicist
nginx est gratuit, voir: nginx.org/LICENSE - r_3
Quel est exactement le but de votre entreprise? Avez-vous besoin de plusieurs noms de domaine complets pour que vos clients puissent se connecter de manière sécurisée à différents noms d’hôtes ou pour que smtpd les diffuse? - r_3
Oui! J'ai plusieurs domaines et je veux que mes clients n'entendent pas les plaintes concernant les certificats lors de l'envoi d'e-mails. - The Quantum Physicist
Vos clients doivent-ils vraiment utiliser leur domaine pour remettre du courrier au MTA? À ma connaissance, il n’ya aucune raison de ne pas acheter un certificat bon marché pour un nom de domaine complet sans rapport avec vos clients. Pour la livraison, le RFC indique que tout Le certificat doit être accepté car même l'absence de STARTTLS ne devrait pas faire rebondir votre courrier. La seule raison qui reste est que vos clients souhaitent réellement utiliser leur domaine dans les paramètres de leur client. Quelque chose une fois mis en place, ne se présente plus jamais. - r_3