双向 SSL 验证
我正在尝试查找有关双向 SSL 身份验证详细信息的更多信息。我想知道的是当一个客户端收到另一个客户端的证书时会进行哪些验证。 （请参阅下图中的验证圆圈）
有人有所有步骤的列表吗？有标准文件可以给我参考吗？每个服务器的实现方式是否不同？
我主要要问的是......服务器是否对其他服务器的主机名与证书通用名（CN）进行验证？
I'm trying to find out more information on the details of two-way SSL authentication. What I want to know is what verifications are done when one client receives another's certificate. (See the Verify Circle in the image below)
Does someone has a list of all of the steps? Is there a standards document I can be pointed to? Does each server implement it differently?
Mainly what I'm asking is... Does the server do a verification against the other server's hostname vs the certificates Common name (CN)?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
正如@user384706所说，它是完全可配置的。
您所讨论的场景是一台机器既是服务器又是客户端（就 SSL/TLS 连接而言是客户端）。
通过验证连接是否源自所提供证书的 CN（或可能是主题备用名称），您不一定会获得更多的安全性。
有几个问题：
如果 SSL/TLS 服务器旨在由既是最终用户又是服务器本身的客户端使用，则根据您的客户端类型，您将有两个不同的规则。正在等待特定的证书。您可以根据客户端证书是否具有“服务器”扩展密钥使用扩展或仅具有客户端扩展制定规则，但这可能会变得有点复杂（为什么不呢）。
客户端（也是服务器）可能通过代理访问，具体取决于其所在的网络，在这种情况下，源 IP 地址将与您期望的不匹配。
通常，客户端证书身份验证依赖于私钥被假定受到保护的事实。如果服务器上的攻击者泄露了私钥，则攻击者还可能在建立连接（或直接从受损服务器建立连接）时欺骗原始 IP 地址。话虽这么说，服务器往往拥有不受密码保护的私钥，因此如果它被离散复制，它可能会有所帮助。
我认为有些工具非常严格，它们不仅验证 CN 是传入连接的 FQDN：它们还检查它是否是源 IP 地址的反向 DNS 条目。这在实践中可能会导致许多问题，因为某些服务器可能在 DNS 中具有多个 CNAME 条目，在这种情况下，CN 是合法的，但不一定是该 IP 地址的主 FQDN。
这一切实际上都取决于系统的整体协议和总体架构。
RFC 6125（互联网公共领域内基于域的应用程序服务身份的表示和验证）最近发布的《在传输层安全 (TLS) 上下文中使用 X.509 (PKIX) 证书的关键基础设施》 认为这种情况超出了范围。
我能想到的最接近的参考是SIP。
As @user384706 says, it's entirely configurable.
The scenario you're talking about is one where a machine is both a server and a client (and is the client as far as the SSL/TLS connection is concerned).
You don't necessarily gain much more security by verifying that the connection originates from the CN (or perhaps Subject Alternative Name) of the certificate that is presented.
There are a couple of issues:
If the SSL/TLS server is meant to be used by clients that are both end-users and servers themselves, you're going to have two different rules depending on which type of client you're expecting for a particular certificate. You could have a rule base on whether the client certificate has the "server" extended key usage extension or only the client one, but this can get a bit complex (why not).
The client (which is also a server) may be coming through a proxy, depending on the network where it is, in which case the source IP address will not match what you'd expect.
Usually, client-certificate authentication relies on the fact that private keys are assumed to be kept protected. If a private key is compromised by an attacker on the server, the attacker may also have the ability to spoof the origin IP address when making the connection (or making the connection from the compromised server directly). This being said, servers tend to have private keys that are not password-protected, so it may help a little bit in case it was copied discretely.
I think some tools are so strict that they don't only verify the CN to be the FQDN of the incoming connection: they also check that it's the reverse DNS entry for the source IP address. This can cause a number of problems in practice, since some servers may have multiple CNAME entries in the DNS, in which case the CN would be legitimate, but not necessarily the primary FQDN for that IP address.
It all really depends on the overall protocol and general architecture of the system.
RFC 6125 (Representation and Verification of Domain-Based Application Service Identity within Internet Public Key Infrastructure Using X.509 (PKIX) Certificates in the Context of Transport Layer Security (TLS)), recently published, considers this scenario out of scope.
The closest reference I can think of is SIP.
这是可配置的。
可以配置严格检查，并且不接受来自发送 CN 与 FQDN 不匹配的证书的实体的连接，尽管该证书被视为受信任（例如，由受信任的 CA 签名）。
可以放宽这一点，不进行此检查并接受证书或将决定委托给用户。例如，IE 会显示弹出警告，指出证书名称与 FQDN 不匹配。您仍想继续吗？
从安全角度来说最安全的是做严格的验证
This is configurable.
It is possible to configure strict checking and not accept connections from entities sending a certificate that the CN does not match the FQDN despite the fact that the certificate is considered as trusted (e.g. signed by a trusted CA).
It is possible to relax this and do not do this check and accept the certificate or delegate the decision to the user. E.g. IE shows a pop up warning saying that certificate's name does not match FQDN. Do you want to proceed anyway?
From security perspective the safest is to do strict verification