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

Question 1

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

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

在 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 命令作为第一个命令发送
。

那么，服务器对 HELO/EHLO 的响应是什么前TLS 握手似乎实际上根本不重要。

根据我的经验，自签名证书在面向互联网的邮件服务器上运行良好，这意味着其他邮件服务器甚至懒得验证它们，它们只是很乐意接受任何可以提供 TLS 加密的东西，无论发证机构或主题名称如何。

Answer

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

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

在 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 命令作为第一个命令发送
。

那么，服务器对 HELO/EHLO 的响应是什么前TLS 握手似乎实际上根本不重要。

根据我的经验，自签名证书在面向互联网的邮件服务器上运行良好，这意味着其他邮件服务器甚至懒得验证它们，它们只是很乐意接受任何可以提供 TLS 加密的东西，无论发证机构或主题名称如何。

Question 2

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

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

Answer

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

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

Question 3

对于任何使用 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 条目中。不鼓励使用通配符。

Answer