我正在尝试了解有关双向SSL身份验证详细信息的更多信息。我想知道的是当一个客户收到另一个证书时进行的验证。 （参见下图中的验证圆圈）
是否有人列出了所有步骤？有没有我可以指出的标准文件？每个服务器是否以不同方式实现它？
主要是我要问的是......服务器是否对其他服务器的主机名与证书公用名（CN）进行了验证？
答案 0 :(得分：0)
主要是我要问的是......是吗？ 服务器对此进行验证 其他服务器的主机名与 证书通用名称（CN）？
这是可配置的
可以配置严格检查，并且不接受来自发送CN与FQDN不匹配的证书的实体的连接，尽管证书被认为是可信的（例如，由可信CA签名）。
可以放松这一点，不要进行此检查并接受证书或将决定委托给用户。例如。 IE显示弹出警告，说明证书的名称与FQDN不匹配。你还想继续吗？
从安全角度来看，最安全的是进行严格的验证
答案 1 :(得分：0)
正如@ user384706所说，它完全可以配置。
您所谈论的场景是机器既是服务器又是客户端（就SSL / TLS连接而言是客户端）。
通过验证连接是否来自所提供证书的CN（或可能是主题备用名称），您不一定能获得更多安全性。
有几个问题：
如果SSL / TLS服务器本应由最终用户和服务器本身的客户端使用，那么根据您期望的客户端类型，您将拥有两个不同的规则。特别证书。您可以根据客户端证书是否具有“服务器”扩展密钥用法扩展或仅具有客户端证书来制定规则，但这可能会有点复杂（为什么不）。
客户端（也是服务器）可能来自代理，具体取决于网络的位置，在这种情况下，源IP地址将与您期望的不一致。
通常，客户端证书身份验证依赖于假定私钥受到保护的事实。如果私钥被服务器上的攻击者攻击，则攻击者还可以在建立连接时欺骗原始IP地址（或直接从受感染服务器建立连接）。话虽如此，服务器往往拥有不受密码保护的私钥，因此如果它被单独复制，它可能会有所帮助。
我认为有些工具非常严格，它们不仅要验证CN是传入连接的FQDN：它们还会检查它是源IP地址的反向DNS条目。这可能会在实践中引起许多问题，因为某些服务器在DNS中可能有多个CNAME条目，在这种情况下，CN将是合法的，但不一定是该IP地址的主要FQDN。
这一切都取决于整个协议和系统的总体架构。
最近发布的我能想到的最接近的参考是SIP。
