SMTP 服务器的 SSL 证书应包含什么主机名？

Question

我在 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表明后者是正确的，但我找不到明确的答案。

Answer 1

这实际上并没有在任何地方明确定义，服务器是否应该被“信任”取决于连接到它的客户端（当然可以是另一个邮件服务器）；引用相关 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 加密的东西，而不管发行者如何权威或主题名称。

Answer 2

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

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

Answer 3

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

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

当预先启动 SSL/TLS 连接 (SMTPS) 时，服务器无法在建立连接之前查看 HELO 消息所说的内容，因此它必须使用它发出请求的那个。

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

• C->S：你好，我是 Alice，我想和 Bob 谈谈。
• S->C：嗨，我是 Chuck，这是我给 Chuck 的证书。
• C->S：哦，是的，您的证书确实对 Chuck 有效。让我们继续。
• ... 当然，这里有一个缺陷，因为 Alice 想要与 Bob 进行安全通信。

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

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

在它的附录中，它总结了之前关于 SMTP 的内容（取自RFC 3207和RFC 4954）。特别是“客户端不得使用源自不安全远程源（例如，不安全的 DNS 查找）的任何形式的服务器主机名。 ”（这当然适用于服务器的横幅）。除此之外，关于主题备用名称（应该而不是必须使用），SMTP 旧规则比 HTTPS 更宽松一些。

现代方法绝对是将主机名放在主题备用名称 DNS 条目中。也不鼓励使用通配符。