我正在尝试查找有关双向 SSL 身份验证详细信息的更多信息。我想知道的是当一个客户收到另一个客户的证书时会进行哪些验证。（见下图中的验证圈）
有人有所有步骤的清单吗？有没有我可以指出的标准文件？每个服务器是否以不同的方式实现它？
我主要要问的是......服务器是否对其他服务器的主机名与证书公用名（CN）进行验证？
问问题
4942 次
2 回答
0
我主要要问的是......服务器是否对其他服务器的主机名与证书公用名（CN）进行验证？
这是可配置的。
可以配置严格检查并且不接受来自实体的连接，该实体发送 CN 与 FQDN 不匹配的证书，尽管该证书被认为是可信的（例如，由可信 CA 签名）。
可以放宽这一点，不进行此检查并接受证书或将决定委托给用户。例如，IE 显示一个弹出警告，指出证书的名称与 FQDN 不匹配。你还是要继续吗？
从安全的角度来看，最安全的是做严格的验证
于 2011-06-16T21:24:35.913 回答
0
正如@user384706 所说，它是完全可配置的。
您正在谈论的场景是一台机器既是服务器又是客户端（并且就 SSL/TLS 连接而言是客户端）的场景。
通过验证连接是否源自所提供证书的 CN（或者可能是主题备用名称），您不一定会获得更多的安全性。
有几个问题：
如果 SSL/TLS 服务器打算由既是最终用户又是服务器本身的客户端使用，则根据您期望获得特定证书的客户端类型，您将有两种不同的规则。您可以根据客户端证书是否具有“服务器”扩展密钥使用扩展或仅具有客户端证书来制定规则，但这可能会有点复杂（为什么不）。
客户端（也是服务器）可能会通过代理，具体取决于它所在的网络，在这种情况下，源 IP 地址将与您期望的不匹配。
通常，客户端证书身份验证依赖于假定私钥受到保护的事实。如果私钥在服务器上被攻击者破坏，则攻击者在建立连接（或直接从被破坏的服务器建立连接）时也可能具有欺骗源 IP 地址的能力。话虽如此，服务器往往具有不受密码保护的私钥，因此如果它被离散复制可能会有所帮助。
我认为有些工具非常严格，以至于它们不仅将 CN 验证为传入连接的 FQDN：它们还检查它是否是源 IP 地址的反向 DNS 条目。这在实践中可能会导致许多问题，因为某些服务器可能在 DNS 中有多个 CNAME 条目，在这种情况下 CN 是合法的，但不一定是该 IP 地址的主要 FQDN。
这完全取决于系统的整体协议和一般架构。
最近发布的 RFC 6125（在传输层安全 (TLS) 的上下文中使用 X.509 (PKIX) 证书在 Internet 公钥基础设施中表示和验证基于域的应用程序服务身份）认为这种情况超出了范围。
我能想到的最接近的参考是SIP。
于 2011-06-16T22:30:09.317 回答