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

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

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

我的每个域都有一个指向mx.example.com的MX记录，解析为192.0.2.1。

如果我想让exim为传入的电子邮件连接提供TLS加密，我应该在SSL证书中输入哪个主机名？

• foo.example.com，因为这就是服务器在HELO中说的内容？
• mx.example.com，因为这是客户端将连接到的主机名？

http://www.checktls.com建议后者是正确的，但我找不到明确的答案。

实际上，这在任何地方都没有明确定义，是否应该“信任”服务器取决于连接到它的客户端（当然可以是另一个邮件服务器）。引用相关RFC（RFC 2487）：

如果SMTP客户端认为认证或
隐私级别不够高，无法继续，则它应该
在TLS协商完成后立即发出SMTP QUIT命令。
如果SMTP服务器确定身份验证或
隐私级别不够高，无法继续进行，则它应
使用
554应答代码（可能的文本字符串，例如：如“
由于缺乏安全性，命令被拒绝”）。

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

这基本上意味着，当服务器使用给定证书提供TLS加密时，接受还是拒绝该证书的决定完全取决于另一部分，这可能会使证书上的名称与连接的名称相同，但是可以即使不匹配也很好接受。

但是，等等，还有更多。再次引用相同的RFC：

TLS握手完成后，SMTP协议将重置为
初始状态（服务器发出220
服务就绪问候语后SMTP中的状态）。服务器必须丢弃
从客户端获得的任何知识，例如EHLO命令的参数，
而这不是从TLS协商本身获得的。客户端
必须丢弃从服务器获得的任何知识，例如
SMTP服务扩展列表，这些知识不是从TLS
协商本身获得的。客户端应该
在成功的TLS协商之后发送EHLO命令作为第一个命令。

因此，服务器在TLS握手之前对HELO / EHLO的响应似乎并不重要。

以我的经验，自签名证书可以在面向Internet的邮件服务器上很好地工作，这意味着其他邮件服务器甚至不费心去验证它们，它们会很乐意接受任何可以提供TLS加密的内容，而无论发出什么证书权限或主题名称。

将邮件发送到您的域的MTA将查找MX记录（这将产生一个主机名），然后查找该主机名的A记录。因此，它要连接的主机名是MX主机名，因此将根据SSL证书公用名进行验证。验证HELO主机名没有意义，因为服务器可以提供所需的任何HELO主机名-它不提供额外的安全性。

也就是说，在传递邮件时严格验证SSL证书目前并不特别有用，因为MTA（几乎总是）会退回到非SSL传递，因为这就是SMTP目前的工作方式。因此，明智的配置是，如果MX服务器提供SSL，则使用SSL，而不管SSL证书是否通过验证（因为不进行身份验证的加密要比不进行加密和不进行身份验证要好）。因此，您也可以为此使用自签名证书。

对于使用SSL / TLS的任何协议，验证服务器证书及其与服务器主机名匹配的任务纯粹是客户端的角色。

这样，证书中的主机名应与客户端尝试访问的名称匹配。

当SSL / TLS连接预先启动（SMTPS）时，服务器无法在建立连接之前查看HELO消息的内容，因此服务器必须使用与之进行请求的连接。

在之后使用SSL / TLS时STARTTLS，客户端仍然打算与配置它的服务器进行通信，因此这仍然是它应检查的内容。失败将使MITM攻击成为可能：

• C-> S：您好，我是爱丽丝，我想和鲍勃谈谈。
• S-> C：嗨，我是Chuck，这是我给Chuck的证书。
• C-> S：哦，是的，您的证书确实对Chuck有效。让我们继续。
• ...当然存在一个缺陷，因为爱丽丝想与鲍勃进行安全的沟通。

在两种情况下，都应使用MX地址。

主机名匹配规则是最近在RFC 6125中跨协议收集的，但很少有客户端完全实现它（这是RFC的最佳实践，而不是完整的更改，并且它仍然是最近的）。

在其附录中，它概述了以前关于SMTP的内容（摘自RFC 3207和RFC 4954）。特别是“ 客户端不得使用从不安全的远程源（例如，不安全的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

checktls的结果：SSL证书CN = MX域（* .yahoodns.net）

我对cisco进行了相同的操作，结果也相同。

进入SSL / TLS加密后，客户端始终检查远程计算机上“真实” /“声明的”主机名与包含在证书中的信息之间的对应关系。

因此，您可能应该设置foo.example.com或生成通配符证书;-)