主页 / server / 问题 / 389413
Accepted
David North
Asked: 2012-05-16 13:23:26 +0800 CST

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

  • 772

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

smtp ssl certificate exim

5 个回答

  1. Best Answer

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

    • 21

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

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

    • 12

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

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

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

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

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

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

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

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

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

    • 8

  4. 我认为最好的办法是复制实践中所做的事情。我已经使用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 做了同样的事情，我得到了同样的结果。

    • 2

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

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

    • -1

相关问题