java - 什么会导致 SSL 协商在 .NET 下成功但在 Java 下失败？

Question

我们必须使用 Java 中的 Apache CXF 创建一个 Web 服务客户端。问题是我似乎无法让 SSL session 正常参与。要么完全失败，一旦应用程序数据传输后服务器无法破译发送给它的内容，要么我无法读取服务器的响应。

然而，当使用内置于 .NET 中的简单 soap 测试客户端尝试相同的事务时，一切运行顺利。

服务器正在使用双重身份验证。

一切都是基于证书 (x509) 存储在 windows 证书存储区(windows-MY 和 windows-ROOT)

---

编辑是的，双重身份验证确实是客户端和服务器身份验证。

到目前为止，使用 bountyCaSTLe 提供程序而不是 SunMSCAPI 似乎更进一步，但仍然无法使客户端身份验证工作。

客户端平台CXF 2.2.9，Sun JDK 1.6_21服务器 IIS 6 ASP.NET 不幸的是我只能收集到，我无法控制服务器并且必须按原样使用它。

更新我现在正在使用 JKS keystore ，但仍然遇到问题。作为身份验证过程的一部分，客户端似乎没有将他的证书发送到服务器。结果我从服务器收到 403.7 错误。

有趣的是，我收到的这个错误消息是一个 HTML 页面，必须先解密才能读取!

Answer 1

据推测，通过双重身份验证，您的意思是除了服务器证书身份验证(更常见)之外，您还使用客户端证书身份验证。

了解双方使用的平台版本以及应用了哪些补丁会很有用。

部分问题可能来自对 CVE-2009-3555 的重新协商修复(或缺乏修复)。

问题是 TLS 中重新协商的初始设计中的一个缺陷，它用于重新协商客户端证书。有两种获取客户端证书的方法:服务器在初始 TLS 握手期间请求它，或者在随后的握手期间请求它(例如，一旦它弄清楚请求的目的和/或当试图访问某个限制区域时)。第二种方法是重新协商。不幸的是，在这方面 TLS 协议(protocol)的设计存在安全缺陷，由于 RFC 5746 中描述的 TLS 扩展，该缺陷已被修复。 .

当该缺陷最初被披露时(大约在 2009 年 11 月)，一些平台和库(例如 Sun Java 或 OpenSSL)推出了一个快速修复，它只是不允许任何重新协商(因此只有客户端证书的初始协商有效) .后来，一旦编写了 RFC 5746，这些库就开始推出支持此扩展的实现。

据我所知，Microsoft 在 IIS 及其 Web 框架中的默认设置是使用重新协商而不是初始协商。此外，它没有推出禁用重新协商的初始修复(有效保留已知漏洞)。它最近才推出了一个补丁(默认情况下仍然容忍​​旧的实现):Microsoft Security Bulletin MS10-049 - Critical .

这个微软安全博客上也有对问题的解释: http://blogs.technet.com/b/srd/archive/2010/08/10/ms10-049-an-inside-look-at-cve-2009-3555-the-tls-renegotiation-vulnerability.aspx

从本质上讲，如果您尝试与仅支持旧协商样式的服务器从仅具有新的重新协商样式或根本没有重新协商的堆栈进行通信，那是行不通的。

如果您的服务器正在使用 IIS 或类似环境运行，您可以使用 netsh 及其 clientcertnegotiation=enable 选项打开初始客户端证书协商。