是什么导致SSL协商在.NET下成功而在Java下失败?

大概是吧 双重认证 ,您的意思是除了使用服务器证书身份验证(更常见)之外,还使用客户端证书身份验证。

了解两边使用了哪些版本的平台以及应用了哪些修补程序将是非常有用的。

有可能有些问题来自于重新协商修复 CVE-2009-3555 (或缺乏固定)。

RFC 5746 .

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

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 选项。

这将导入您的自签名证书。

cd JAVA_HOME/jre/lib/security
keytool -import -file server_cert.cer -keystore cacerts

我将此作为一个答案发布,尽管我现在意识到这个问题的表述不正确,因为我被抛出了一个循环,因为我的.NET示例实际上是在执行一个黑客来绕过这个问题。

如何让Java在不要求证书的服务器上执行客户端身份验证?

答案其实就在我们的眼皮底下,然而要得到答案就需要正确的问题!!

Java HTTPS client certificate authentication

Client SSL authentication causing 403.7 error from IIS

尽管客户端“不应该”在未被请求时发送证书,但我发现通过调整密钥库中的客户端证书以包含以下内容:

• 客户端私钥

将所有这些内容推送到同一个证书存储中,并将其用作密钥库。然后再次加载证书链作为信任存储。从那以后就可以了。尽管如此,仍然有失败的可能。解决这个特定问题的最安全的方法是让服务器通过提供一个接受的CA列表主动向客户机请求身份验证证书。