在 mTLS 中，客户端 CN 名称真的很重要吗？答案

【问题标题】：In mTLS does the client CN name actually matter?在 mTLS 中，客户端 CN 名称真的很重要吗？
【发布时间】：2021-11-30 15:27:23
【问题描述】：

对于普通 TLS，客户端将检查我正在与之通信的服务器实际上是否在与 CN 匹配的 FQDN 上，因此如果证书用于不同的域，则默认情况下 TLS 不应工作，因为证书不适用于此站点.

对于 mTLS，当服务器检查客户端证书时，它可以以某种方式检查客户端地址是否与 CN 匹配，还是只是检查证书与密钥匹配并且证书在客户端是受信任的？即，如果我从互联网上的任何机器上使用正确的客户端密钥/证书，如果服务器配置为信任该证书，服务器是否应该连接，或者它是否需要客户端以某种方式位于特定地址？

【问题讨论】：

TLS 和 HTTPS 是不同的协议。 HTTPS 使用 TLS。 TLS不指定上层协议应该如何确认对等体的身份，它只是提供应该被更高层协议利用的经过验证的证书。 HTTPS 就是这样做的，要求客户端用于建立连接的主机名是证书中的主题 alt 名称之一（暂时不推荐使用 CN 用于此目的）。它没有指定当客户端使用证书进行身份验证时应该发生什么。这取决于服务器配置/代码。
感谢@PresidentJamesK.Polk，所以如果我理解正确，如果我被告知有一个 mTLS 服务器设置，它可能无论如何都不会检查客户端地址，它只是检查证书是否受信任并由客户私钥？

标签： ssl mtls

【解决方案1】：

这取决于具体的用例。

在某些情况下，mTLS 用于服务器到服务器的通信，例如 SIP (VoIP)。在这些情况下，通常期望客户端证书包含发送者的域，类似于服务器证书。以 SIP 为例：这里不同的系统也可以切换角色（即两个站点都可以发起呼叫），以前的客户端证书现在用作服务器证书。

在其他情况下，在 TLS 握手期间不会验证主题，但会从证书主题中提取用户身份并提供给应用程序。然后，应用程序可能会执行其他检查，例如仅允许来自特定组织的用户在主题中进行编码。因此，即使在 TLS 握手期间未在证书验证中使用该主题，它仍然是相关的。

【讨论】：

感谢 Steffen Ullrich，所以在 SIP 案例的第一个实例中，我猜它在 TLS 握手期间仍未检查，而是作为应用程序级别检查？无论哪种方式，正在检查请求的哪一部分以了解客户端域（据我所知，正常请求不会包含此信息）？
@othane：请参阅RFC 5922 - Domain Certificates in the Session Initiation Protocol (SIP), Section 7.4，了解使用客户端证书中信息的某些方面。
“尽管如此，服务器策略可以使用从第 7.1 节中的证书中收集的一组 SIP 域身份来做出授权决策。” ...所以如果我理解正确，这意味着它基本上只是将证书中的域列入白名单，但无论如何都没有实际的方法来检查客户端地址是否与证书匹配（这有点像我所期望的）
@othane：对，客户端证书的主题和客户端的源IP之间没有隐式关联。