Quel nom d'hôte le certificat SSL d'un serveur SMTP doit-il contenir?

J'ai un serveur foo.example.com au 192.0.2.1

Il s'exécute pour recevoir des e-mails pour plusieurs de mes domaines.

Mes domaines ont chacun un enregistrement MX pointant vers mx.example.com, qui se résout en 192.0.2.1

Si je veux proposer à exim le cryptage TLS pour les connexions e-mail entrantes, quel nom d'hôte dois-je mettre dans le certificat SSL?

• foo.example.com parce que c'est ce que le serveur dira dans le HELO?
• mx.example.com parce que c'est le nom d'hôte auquel les clients se seront connectés?

http://www.checktls.com suggère que ce dernier est correct, mais je ne trouve pas de réponse définitive.

Ceci n'est en fait défini explicitement nulle part, et le fait que le serveur soit ou non "de confiance" dépend du client (qui pourrait bien sûr être un autre serveur de messagerie) s'y connectant; citant de la RFC pertinente ( RFC 2487 ):

Si le client SMTP décide que le niveau d'authentification ou de
confidentialité n'est pas suffisamment élevé pour qu'il puisse continuer, il DEVRAIT émettre une
commande SMTP QUIT immédiatement après la fin de la négociation TLS.
Si le serveur SMTP décide que le niveau d'authentification ou de
confidentialité n'est pas suffisamment élevé pour qu'il puisse continuer, il DEVRAIT répondre à
chaque commande SMTP du client (autre qu'une commande QUIT) avec
le code de réponse 554 (avec une chaîne de texte possible telle "Commande
refusée par manque de sécurité").

La décision de croire ou non l'authenticité de l'
autre partie dans une négociation TLS est une affaire locale. Cependant, quelques
règles générales pour les décisions sont:

- A SMTP client would probably only want to authenticate an SMTP
  server whose server certificate has a domain name that is the
  domain name that the client thought it was connecting to.

Cela signifie essentiellement que, lorsque le serveur propose le cryptage TLS à l'aide d'un certificat donné, la décision d'accepter ou de refuser dépend entièrement de l'autre partie, qui voudra probablement que le nom sur le certificat soit le même auquel il est connecté, mais pourrait très bien l'accepter même s'il ne correspond pas.

Mais attendez, il y a plus. Citant à nouveau à partir du même RFC:

Une fois la prise de contact TLS terminée, le protocole SMTP est réinitialisé à
l'état initial (l'état dans SMTP après qu'un serveur ait émis un message d'
accueil 220 prêt pour le service). Le serveur DOIT éliminer toute connaissance
obtenue du client, telle que l'argument de la commande EHLO,
qui n'a pas été obtenue à partir de la négociation TLS elle-même. Le client
DOIT éliminer toute connaissance obtenue du serveur, telle que la liste
des extensions de service SMTP, qui n'a pas été obtenue à partir de la
négociation TLS elle-même. Le client DEVRAIT envoyer une commande EHLO comme
première commande après une négociation TLS réussie.

Donc, ce que le serveur dit en réponse à HELO / EHLO avant la prise de contact TLS ne semble pas vraiment avoir d'importance.

D'après mon expérience, les certificats auto-signés fonctionnent assez bien sur les serveurs de messagerie accessibles sur Internet, ce qui signifie que les autres serveurs de messagerie ne prennent même pas la peine de les valider, ils accepteront tout simplement tout ce qui peut fournir le cryptage TLS, quelle que soit la délivrance. autorité ou nom du sujet.

Un MTA remettant du courrier à votre domaine va rechercher l'enregistrement MX (qui donnera un nom d'hôte), puis rechercher un enregistrement A pour ce nom d'hôte. Le nom d'hôte auquel il se connecte est donc le nom d'hôte MX, et c'est donc ce qui sera vérifié par rapport au nom commun du certificat SSL. La vérification du nom d'hôte HELO n'a pas de sens car le serveur peut fournir n'importe quel nom d'hôte HELO qu'il souhaite - il n'offre pas de sécurité supplémentaire.

Cela dit, la vérification stricte des certificats SSL lors de la livraison du courrier n'est pas particulièrement utile pour le moment, car les MTA recourront (presque toujours) à la livraison non SSL, car c'est ainsi que SMTP fonctionne pour le moment. La configuration raisonnable consiste donc à utiliser SSL si le serveur MX le propose, que le certificat SSL vérifie ou non (car le cryptage sans authentification est préférable à aucun cryptage et à aucune authentification). Vous pouvez donc aussi utiliser un certificat auto-signé à cet effet.

La tâche de vérification du certificat de serveur et de sa correspondance avec le nom d'hôte du serveur est purement le rôle du client, pour tout protocole utilisant SSL / TLS.

En tant que tel, le nom d'hôte dans le certificat doit correspondre au nom auquel le client tente d'accéder.

Lorsque la connexion SSL / TLS est initiée à l'avance (SMTPS), le serveur n'a aucun moyen de voir ce que dit le message HELO avant que la connexion ne soit établie, il doit donc utiliser celui avec lequel il a fait la demande.

Lors de l'utilisation de SSL / TLS après STARTTLS, le client a toujours l'intention de parler au serveur avec lequel il a été configuré, c'est donc toujours ce qu'il doit vérifier. À défaut, les attaques MITM seraient possibles:

• C-> S: Bonjour, je suis Alice, je veux parler à Bob.
• S-> C: Salut, je suis Chuck, voici mon certificat pour Chuck.
• C-> S: Oh oui, votre certificat est en effet valable pour Chuck. Continuons.
• ... Il y a bien sûr un défaut, car Alice voulait une communication sécurisée avec Bob.

Dans les deux cas, c'est l'adresse MX qui doit être utilisée.

Les règles de correspondance des noms d'hôte ont récemment été rassemblées à travers les protocoles de la RFC 6125 , mais peu de clients l'implémentent complètement (il s'agit davantage d'une RFC de meilleure pratique que d'un changement complet, et c'est encore assez récent).

Dans son annexe , il résume ce qui existait auparavant sur SMTP (extrait de RFC 3207 et RFC 4954 ). En particulier " Le client NE DOIT PAS utiliser une forme quelconque du nom d'hôte du serveur dérivé d'une source distante non sécurisée (par exemple, une recherche DNS non sécurisée). " (Qui s'applique bien sûr à la bannière du serveur). En dehors de cela, les règles héritées SMTP étaient un peu plus détendu que HTTPS concernant Subject Alternative Names ( devrait au lieu de doit être utilisé).

La manière moderne est certainement de mettre le nom d'hôte dans une entrée DNS de nom alternatif de sujet. L'utilisation de caractères génériques est également déconseillée .

Je pense que le mieux serait de copier ce qui se fait dans la pratique. J'ai vérifié une adresse e-mail yahoo.com en utilisant http://checktls.com J'espère que chez yahoo, ils ont utilisé un domaine différent pour leur nom d'hôte et pour leur domaine mx. Ainsi, leur nom d'hôte est un yahoo.com et leur domaine mx se termine par yahoodns.net

dig mx yahoo.com gives mta6.am0.yahoodns.net. among others

Résultat de checktls: le certificat SSL CN = domaine MX (* .yahoodns.net)

J'ai fait de même avec Cisco et j'ai eu le même résultat.

Dans le cryptage SSL / TLS, le client vérifie toujours la correspondance entre le nom d'hôte "réel" / "déclaré" sur la machine distante et les informations contenues dans le certificat.

Donc, vous devriez probablement définir foo.example.com ou générer un certificat générique ;-)