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