我们必须使用 Java 中的 Apache CXF 创建一个 Web 服务客户端。问题是我似乎无法让 SSL 会话正确参与。要么完全失败，一旦应用程序数据传输，服务器无法解密发送给它的内容，或者我无法读取服务器的响应。
然而，当使用 .NET 内置的简单肥皂测试客户端尝试相同的事务时，一切都运行顺利。
服务器正在使用双重身份验证。
一切都是基于证书（x509）存储在Windows证书存储（Windows-MY和Windows-ROOT）
编辑
是的，双重身份验证确实是客户端和服务器身份验证。
到目前为止，使用 bountyCastle 提供程序而不是 SunMSCAPI 似乎更进一步，但仍然无法使客户端身份验证正常工作。
客户端平台 CXF 2.2.9、Sun JDK 1.6_21
不幸的是，我只能收集服务器 IIS 6 ASP.NET，我无法控制服务器，必须按原样使用它。
更新
我现在使用 JKS 密钥库，但仍然遇到问题。作为身份验证过程的一部分，客户端似乎没有将其证书发送到服务器。结果我从服务器收到 403.7 错误。
有趣的是，我收到此错误消息为 HTML 页面，必须先解密才能读取！
We have to create a web service client using Apache CXF in Java. The thing is I cannot seem to get the SSL session to properly engage. Either it fails altogether, the server fails to decipher what is sent to it once the application data is transmitted or I fail to read the responses from the server.
However when trying the same transaction using a simple soap test client built in .NET everything runs smoothly.
Server is using double authentication.
Everything is certificate based (x509) stored in the windows certificate store (windows-MY and windows-ROOT)
edit
yes, double authentication is indeed client AND server authentication.
Thus far using the bountyCastle provider instead of SunMSCAPI seems to get further but still cannot get the client authentication to work.
PLatform of client CXF 2.2.9, Sun JDK 1.6_21
server IIS 6 ASP.NET unfortunately is all I could gather, I have no control over the server and must use it as-is.
update
I am using a JKS keystore now but still am getting the problem. It seems the client is not sending his certificate to the server as part of the authentication process. As a result I get a 403.7 error from the server.
Funny thing is that I receive this error message as an HTML page that must first be decrypted before it is readable !
发布评论
评论（3）
据推测，双重身份验证意味着除了服务器证书身份验证（更为常见）之外，您还使用客户端证书身份验证。
了解双方使用哪些平台版本以及应用了哪些补丁将很有用。
部分问题可能来自于对 CVE-2009-3555（或缺乏修复）。
问题是 TLS 重新协商的初始设计存在缺陷，TLS 是用于重新协商客户端证书的。有两种获取客户端证书的方法：服务器在初始 TLS 握手期间请求它，或者在后续握手期间请求它（例如，一旦它弄清楚请求的目的和/或当尝试访问某个限制区域时）。第二种方法是重新协商。不幸的是，在这方面 TLS 协议的设计存在安全缺陷，由于 RFC 5746。
当该缺陷最初被披露时（2009 年 11 月左右），一些平台和库（例如 Sun Java 或 OpenSSL）推出了一个快速修复程序，该修复程序只是禁止任何重新协商（因此只有客户端证书的初始协商才有效）。后来，一旦 RFC 5746 编写完毕，这些库就开始推出支持此扩展的实现。
据我所知，微软在 IIS 及其 Web 框架中的默认设置是使用重新协商而不是初始协商。此外，它没有推出禁用重新协商的初始修复（有效保留已知漏洞）。它最近才推出了一个补丁（默认情况下仍然可以容忍旧的实现）： Microsoft 安全公告 MS10-049 - 严重。
微软安全博客上也有对该问题的解释：
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选项打开初始客户端证书协商。Presumably, by double authentication, you mean you're using client-certificate authentication in addition to server-certificate authentication (which is more common).
It would be useful to know which versions of the platforms are used on either side, and which patches have been applied.
It's possible that some of the problem come from the re-negotiation fix to CVE-2009-3555 (or lack of fix).
The problem is a flaw in the initial design of the re-negotiation in TLS, which is what was used to re-negotiate a client-certificate. There are two ways of getting a client-certificate: either the server asks for it during the initial TLS handshake, or it asks for it during a subsequent handshake (for example, once it has figured out what the request was aimed for and/or when trying to access a certain restricted area). The second method is the re-negotiation. Unfortunately, there was a security flaw in the design of the TLS protocol in that respect, which has since been fixed thanks to a TLS extension described in RFC 5746.
When the flaw was initially disclosed (around November 2009), some platforms and libraries such as Sun Java or OpenSSL rolled out a quick fix which simply disallowed any re-negotiation (so only initial negotiation of the client-certificate would work). Later on, once RFC 5746 was written, these libraries started to roll out implementations supporting this extension.
As far as I'm aware, Microsoft's default in IIS and its web framework was to use re-negotiation and not initial negotiation. In addition, it didn't roll out the initial fix to disable re-negotiation (effectively keeping the known vulnerability). It only rolled out a patch (still tolerant to old implementations by default) quite recently: Microsoft Security Bulletin MS10-049 - Critical.
There is also an explanation of the problem on this Microsoft security blog:
http://blogs.technet.com/b/srd/archive/2010/08/10/ms10-049-an-inside-look-at-cve-2009-3555-the-tls-renegotiation-vulnerability.aspx
Essentially, if you're trying to talk to a server that only supports the old negotiation style from a stack that only has the new re-negotiation style or no renegotiation at all, it's not going to work.
If your server is running using IIS or similar environment, you might be able to turn on initial client-certificate negotiation using
netshand itsclientcertnegotiation=enableoption.Java 不依赖操作系统证书存储，需要使用自己的证书存储。
这将导入您的自签名证书。
Java doesn't rely on the OS certificate store and needs to use its own.
This will import your self-signed certificates.
我将其作为答案发布，尽管我现在意识到这个问题没有正确表述，因为我陷入了循环，因为我的 .NET 示例实际上是在执行 hack 来解决该问题。
正确的问题应该是
如何让Java在不要求证书的服务器上执行客户端身份验证？
答案实际上就在我们眼皮底下，但是要找到答案需要正确的问题！！
非常感谢布鲁诺提供了一些非常有用的信息。
解决方案几乎可以概括为这两个问题：
Java HTTPS 客户端证书身份验证
客户端 SSL 身份验证导致 IIS 出现 403.7 错误
如果没有要求，客户端“不应该”发送证书我发现通过调整密钥库中的客户端证书以包含以下内容：
将所有这些推送到同一个证书存储中并将其用作密钥库。然后再次加载认证链作为信任存储。从那里它应该可以工作。话虽如此，失败的可能性仍然存在。解决此特定问题的最安全方法是让服务器通过提供可接受的 CA 列表主动向客户端请求身份验证证书。
希望这可以帮助任何遇到同样问题的人，在我到达邪恶根源之前，肯定让我旋转了一段时间。
I post this as an answer though I realize now the question was not formulated properly as I got thrown in a loop because the .NET example I had was actually performing a hack to get around the problem.
The proper question should have been
How to get Java to perform Client side Authentication on a server that does not ask for Ask for certificates ?
the answer is actually under our very noses, however to get to the answer one needs the correct question !!
Great thanks to Bruno who provided some very helpful information.
the solution can pretty much be summed up in these two questions :
Java HTTPS client certificate authentication
Client SSL authentication causing 403.7 error from IIS
Although the client is "not supposed" to send a certificate if not asked I found that by tweaking the client certificate in the keystore to contain the following :
push all this in the same certificate store and use it as keystore. Then load again the certification chain as a trust store. From there it should just work. This being said there is still a possibility for failure. the safest way to solve this particular issue is to have the server actively ask for a authentication certificate from the client by providing a list of accepted CA.
Hope this helps anyone else that can be stuck in the same problem, sure tooke me for a spin for a while before I reach the root of evil.