处理configuration相互TLS（客户端证书）时遇到问题的客户。 根据我的经验，TLS客户端身份validation是由服务器拥有证书，并告诉客户端发送由第一个证书签名的证书。 客户端发送一个（与它签署的东西），服务器validation。
客户正试图在服务器的信任存储中使用CA证书。 在他们的情况下，任何人都可以从该CA申请证书。 所以，这不会与上述 – 因为任何人都可以从CA获得身份certificate并连接。
此行为似乎是Java默认值。 在过去，这是我所采取的方法 – 使用中间证书或可以控制的CA。
我知道一个自定义的Java TrustManager可以在客户端上实现发送任何证书，而不pipe它的来源。 我也知道curl会这样做（忽略CertificateRequest中的证书颁发机构）。 使用这种方法，您可以使用身份证书，而不是CA，所以客户端和服务器可以使用相同的证书，而不pipe其来源。
这里最好的做法是什么？ 客户是否提出了合理的要求？ 我们也有一个Windows服务器来configuration下一个，我不知道它将如何处理这种行为。
编辑： RFC似乎使此行为可选。
certificate_authorities：可接受的certificate_authorities的可分辨名称[X501]的列表，以DER编码格式表示。 这些专有名称可以为根CA或从属CA指定所需的可分辨名称; 因此，这个消息可以用来描述已知的根以及所需的授权空间。 如果certificate_authorities列表为空，则客户端可以发送任何适当ClientCertificateType的证书，除非有相反的外部安排。 https://tools.ietf.org/html/rfc5246#section-7.4.4
没有技术上的原因，用于服务器证书的CA需要与客户端证书使用的CA相同。
为什么您希望通过configuration来满足特定的环境，可能有一些原因，但这在技术上是不需要的。
客户端定义客户端信任的CA（或者他们使用来自操作系统/浏览器的certifcate存储）。 服务器通常可以做同样的事情。 使用操作系统信任的所有CA，或者信任特定的CA.
如果您需要要求所有客户端证书由特定的CA签名，您当然可以这样做。
您如何设置您的服务器所信任的CA的具体细节完全取决于您的服务器软件，而您其实并没有真正提到“Windows”。
在他们的情况下，任何人都可以从该CA申请证书。 所以，这不适用于上述 – 因为任何人都可以从CA获得身份certificate并连接。
这将取决于您使用的服务器软件，以及您是否信任CA. 但是对于某些服务器，您可以根据客户端证书中包含的详细信息设置约束条件。 例如，您可能要求用户从某个CA获得证书，并且还要求该证书在与@example.org相匹配的主题中包含一封电子邮件。 如果authentication机构正在做好自己的工作，他们将确authentication书中包含的细节实际上是真实的，作为签名的一部分。