SMTP服务器的SSL证书应包含哪些主机名?

我有一个服务器foo.example.com在192.0.2.1

它运行exim接收我的几个域的电子邮件。

我的域名每个都有一条指向mx.example.com的MXlogging,该loggingparsing为192.0.2.1

如果我想为传入的电子邮件连接提供TLSencryption,我应该在SSL证书中放入什么主机名?

  • foo.example.com,因为这是服务器将在HELO中说什么?
  • mx.example.com,因为这是客户端将连接到的主机名?

http://www.checktls.com暗示后者是正确的,但我找不到明确的答案。

这实际上没有在任何地方明确定义,服务器是否应该被“信任”取决于连接到它的客户端(当然可能是另一个邮件服务器) 从相关RFC( RFC 2487 )引用:

如果SMTP客户端决定authentication级别或
隐私不够高,它会继续,它应该发出一个
TLS协商完成后立即执行SMTP QUIT命令。
如果SMTP服务器决定authentication级别
隐私不够高,它应该继续,它应该回复
来自客户端的每个SMTP命令(QUIT命令除外)
554回复代码(带有可能的文本string,例如“Command”
由于缺乏安全而被拒绝“)。

是否相信真实性的决定
另一方在TLS谈判中是当地的事情。 但是,一些
一般的决定规则是:

- 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. 

这基本上意味着什么,当服务器使用给定的证书提供TLSencryption时,接受或拒绝它的决定完全取决于另一部分,这可能希望证书上的名称与其连接的名称相同,但可以即使不匹配也很好接受。

但是等等,还有更多。 从同一个RFC再次引用:

完成TLS握手后,SMTP协议将重置为
初始状态(服务器发出220后SMTP中的状态
服务准备问候)。 服务器必须丢弃任何知识
从客户端获得,例如EHLO命令的参数,
这不是从TLS谈判本身获得的。 客户端
必须丢弃从服务器获得的任何知识,例如列表
的SMTP服务扩展,它不是从TLS获得的
谈判本身。 客户端应该发送EHLO命令
在TLS谈判成功后的第一个命令。

那么,在TLS握手之前 ,服务器对HELO / EHLO的回应看起来实际上并不重要。

以我的经验来看,自签名证书在面向Internet的邮件服务器上工作得非常好,这意味着其他邮件服务器甚至不打算validation它们,他们只会高兴地接受任何可以提供TLSencryption的东西,而不pipe发行权威或主题名称。

将邮件发送到您的域的MTA将查找MXlogging(这将产生一个主机名),然后查找该主机名的Alogging。 因此,它所连接的主机名是MX主机名,所以这将根据SSL证书通用名进行validation。 validationHELO主机名是没有意义的,因为服务器可以提供任何HELO主机名 – 它不提供额外的安全性。

也就是说,在发送邮件时严格validationSSL证书目前并不是特别有用,因为MTA将(几乎总是)回退到非SSL发送,因为SMTP现在是如何工作的。 因此,如果MX服务器提供SSLconfiguration,则无论SSL证书是否validation(因为没有validation的encryption比没有encryption和validation好,因此使用SSL)。 因此,您可能为此使用自签名证书。

对于使用SSL / TLS的任何协议,validation服务器证书以及与服务器的主机名相匹配的任务纯粹是客户端angular色。

因此,证书中的主机名应与客户端试图访问的名称相匹配。

当SSL / TLS连接先发起(SMTPS)时,服务器在build立连接之前无法看到HELO消息所说的内容,所以它必须使用提出请求的那个。

STARTTLS之后使用SSL / TLS时,客户端仍然打算与configuration它的服务器通信,所以这仍然是它应该检查的内容。 否则会使MITM攻击成为可能:

  • C-> S:你好,我是爱丽丝,我想和鲍勃谈谈。
  • S-> C:嗨,我是Chuck,这是Chuck的证书。
  • C-> S:哦,是的,你的证书确实对查克有效。 我们继续。
  • 当然,那里有一个缺点,因为Alice想要和Bob保密通信。

在这两种情况下,都是应该使用的MX地址。

主机名匹配规则最近已经被RFC 6125中的协议收集,但很less有客户端完全实现它(这是一个最好的实践RFC而不是一个完整的改变,它仍然是相当新的)。

在其附录中 ,总结了之前有关SMTP的一些情况(取自RFC 3207和RFC 4954 )。 特别是“ 客户端不得使用从不安全的远程源派生的任何forms的服务器主机名(例如,不安全的DNS查找) ”(当然这适用于服务器的标识)。 除此之外,SMTP传统规则比HTTPS有关主题替代名称(而不是必须使用) 宽松一些。

现代的方式肯定是把主机名称放在一个主题替代名称的DNS条目。 通配符的使用也是不鼓励的 。

我认为最好的做法是复制实践中所做的事情。 我已经使用http://checktls.com检查了yahoo.com的电子邮件地址。希望在yahoo上,他们使用不同的域名作为他们的主机名和他们的mx域名。 所以,他们的主机名是yahoo.com,他们的mx域以yahoodns.net结尾

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

检查结果:SSL证书CN = MX域(* .yahoodns.net)

我对cisco做了同样的结果。

在SSL / TLSencryption中,客户端总是检查远程机器上“真实”/“声明”主机名与信息包含在证书中的对应关系。

所以,你可能应该设置foo.example.com或生成通配符证书;-)