问双向TLS认证中服务器和客户端的区分

EN

不，这通常是不可能的，只要所有的证书都是用适当的Extended Key Usage (EKU) X.509字段值生成的，并且您的所有TLS服务器都尊重RFC。

对于客户端证书，EKU应该包含TLS WebClientAuthentication值，对于服务器证书则应该包含TLS Web Server Authentication值。(请注意，我提供的是人类可读的字段和值的描述，而不是实际OID值。)

证书颁发机构通常也会在服务器证书中包含TLS Web Client Authentication值，这本身并不坏(至少我个人在这里没有看到攻击场景)，反之亦然。

以StackExchange证书为例：

Signature Algorithm: sha256WithRSAEncryption
    Issuer: C=US, O=DigiCert Inc, OU=www.digicert.com, CN=DigiCert SHA2 High Assurance Server CA
    Validity
        Not Before: May 21 00:00:00 2016 GMT
        Not After : Aug 14 12:00:00 2019 GMT
    Subject: C=US, ST=NY, L=New York, O=Stack Exchange, Inc., CN=*.stackexchange.com
    X509v3 extensions:
        X509v3 Extended Key Usage:
            TLS Web Server Authentication, TLS Web Client Authentication

此外，服务器证书在Subject或Subject Alternative Name X.509字段中都包含服务器的域名。对于StackExchange，如下所示：

Signature Algorithm: sha256WithRSAEncryption
    Issuer: C=US, O=DigiCert Inc, OU=www.digicert.com, CN=DigiCert SHA2 High Assurance Server CA
    Validity
        Not Before: May 21 00:00:00 2016 GMT
        Not After : Aug 14 12:00:00 2019 GMT
    Subject: C=US, ST=NY, L=New York, O=Stack Exchange, Inc., CN=*.stackexchange.com
    X509v3 extensions:
        <...>
        X509v3 Subject Alternative Name:
            DNS:*.stackexchange.com, DNS:stackoverflow.com, <...>

在这里，证书中的Common Name等于*.stackexchange.com，Subject包含Common Name。

现在，要开始颁发客户端证书，您通常需要想出一个命名方案，即您在Subject字段和嵌套的Common Name字段中放置了什么。如何做到这一点完全取决于您自己，但最好确保客户端证书中的Common Name在任何情况下都不能与您的某个域的Common Name相一致，以防您的CA或基础结构中的一些TLS增强应用程序不严格遵守RFC。

确保这一点的一个简单方法是将用户的全名放入Common Name中，然后确保每个颁发的客户端证书都包含一个空格，或者不包含一个点。据我所知，这两项要求中至少有一项可以满足世界上几乎所有的全名。

我认为你将两个不同的概念混合在一起，它们使用了相似的词“验证”或“验证”。

排序证书

在这个过程中，

• 如果是服务器，服务器管理员将创建CSR (证书签名请求)并将其发送到CA，或者以其他方式订购证书。
• 运行CA的人员(可能是实际的人，可能是自动化的)将验证CSR中的细节，即如果您请求www.mysite.com的证书，您实际上拥有www.mysite.com吗？如果您请求nickii@mysite.com的客户证书，您实际上是该用户吗？等。

这是绝对有可能的欺骗一个CA给你一个你不应该拥有的证书，但通常你不使用“中间人”这个词，你可以说“签发一个欺诈性的证书”。

您还没有告诉我们您的服务器和客户端是如何从您自签名的CA中订购证书的，但是我希望有人查看并手动批准每个请求，或者其他一些防止颁发欺诈性证书的过程。如果客户可以订购其他客户，那肯定是不好的，但在您的问题中没有足够的信息来判断这是否可能。

拦截网络流量

这就是你会谈论“中间人”攻击的地方(你认为你在和真正的www.mysite.com交谈，但你实际上是在和一个拥有该网站欺诈证书的攻击者交谈。

你似乎担心有人会得到一个包含服务器名的客户端证书？

• 首先，如前所述，人工单击“颁发证书”会注意到这种伎俩，而不会给出证书。
• 其次，客户端证书不应该充当服务器。CA将放入一个名为Extended Key Usage (EKU)或Enhanced Key Usage的字段，该字段将指示该证书是客户端还是服务器，还是两者兼而有之。您应该确保您的CA包括在它发出的证书中，并且您的客户端在接受连接之前正在检查Server。

只要所有证书都是唯一的(两个或多个实体之间不共享单个证书)，并且根CA是可信的，MITM就没有办法。

也就是说，服务器和每个客户端必须拥有自己的唯一证书，并且只有证书所有者拥有私钥。此外，将服务器配置为验证由您自己的CA颁发的证书，并且只有您的CA有权颁发客户端身份验证证书。这些是基于证书的身份验证基础。当然，您必须执行适当的CA操作，以避免证书错误发布，制定吊销程序等。

此外，您可能需要一个具有客户端的数据库，并将证书映射到客户端帐户，以便进行审核和权限。服务器可以使用此信息对客户端应用限制。