Question

我有一个嵌入Jetty的应用程序。我想在SSL中使用客户端证书身份验证，当我启用它时;我在请求开始时收到以下异常。但之后请求正在得到妥善处理。只有从IE或Chrome访问时才会出现此异常。从Firefox访问时不会出现这种情况。我们有自定义SSLConnector扩展SslSocketConnector。我正在尝试调试它;但是想知道我是否有任何特定的地方/代码可以开始检查。

javax.net.ssl.SSLHandshakeException: Remote host closed connection during handshake 
        at com.sun.net.ssl.internal.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:808) 
        at com.sun.net.ssl.internal.ssl.SSLSocketImpl.performInitialHandshake(SSLSocketImpl.java:1112) 
        at com.sun.net.ssl.internal.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1139) 
        at com.sun.net.ssl.internal.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1123) 
        at org.mortbay.jetty.security.SslSocketConnector$SslConnection.run(SslSocketConnector.java:631) 
        at org.mortbay.thread.BoundedThreadPool$PoolThread.run(BoundedThreadPool.java:451) 
Caused by: java.io.EOFException: SSL peer shut down incorrectly 
        at com.sun.net.ssl.internal.ssl.InputRecord.read(InputRecord.java:333) 
        at com.sun.net.ssl.internal.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:789)

更新

我启用了SSL调试选项，并在ServerHelloDone消息之后立即读取此异常。这是服务器发送其证书以及我相信的客户端证书请求的消息。我不确定在第一次阅读时会发生什么。非常感谢任何帮助。

*** ClientHello, TLSv1
****
%% Created:  [Session-1, TLS_RSA_WITH_AES_128_CBC_SHA]
*** ServerHello, TLSv1
*** Certificate chain
***
*** CertificateRequest
Cert Types: RSA, DSS
Cert Authorities:
*** ServerHelloDone
WRITE: TLSv1 Handshake, length = 703
received EOFException: error
handling exception: javax.net.ssl.SSLHandshakeException: Remote host closed connection during handshake

更新将JDK更新为最新版本23，并尝试启用/禁用两个属性。仍然采取相同的行为。

更多信息： 所有浏览器都启用了TLSv1和SSLv3。无需启用客户端身份验证即可正常进行通信。使用客户端身份验证时，我们总是在第一次握手时获得异常，然后下一次正确完成并继续进行无异常。在服务器端使用jetty版本6.1.14

Answer 1

我在TLS / SSLv3协商中遇到过类似的问题。 http://www.oracle.com/technetwork/java/javase/documentation/tlsreadme2-176330.html

在SSL / TLS中，任何一方都可以启动重新协商。与阶段1修复一样，在互操作模式下与未升级的对等体通信并尝试启动重新协商（通过SSLSocket.startHandshake()或SSLEngine.beginHandshake()）的应用程序将收到SSLHandshakeException（{{1} }）并且连接将被关闭（IOException）。从未升级的对等方接收重新协商请求的应用程序将根据所处的连接类型进行响应：


TLSv1：类型为“handshake_failure（100）”的警告Alert消息将发送给对等方，连接将保持打开状态。当收到“no_renegotiation”警报时，较早版本的SunJSSE将关闭连接。

SSLv3：应用程序将收到no_renegotiation，连接将关闭（SSLHandshakeException）。（“handshake_failure”未在SSLv3规范中定义。）


要设置这些模式，请使用两个系统属性：


no_renegotiation - 在第1阶段引入，它控制是否允许遗留（不安全）重新谈判。

sun.security.ssl.allowUnsafeRenegotiation - 在第2阶段引入，这允许对等方握手，而不需要正确的RFC 5746消息。

如果仍然没有帮助，您可以尝试启用SSL重复数据删除，并查看握手。
sun.security.ssl.allowLegacyHelloMessages

Answer 2

当我意外地将非ssl端口放入URL但使用https启动URL时，我得到了这个。卫生署。

有时最简单的解决方案是我们忘记的解决方案！

Answer 3

尝试最新的jdk。他们修复了一个ssl握手错误。 http://www.java.net/blogs/kumarjayanti/

Answer 4

我仍然认为这是TLS / SSL协商问题。

在您提出调试信息后，它显示您正在进行TLSv1握手。

您确定在浏览器中启用了TLSv1吗？

铬：要在chrome中启用TLS 1.0，请执行以下操作：

点击扳手图标：
选择选项
选择“Under the Hood”标签
点击更改代理设置
选择“高级”标签
Scoll down并检查TLS 1.0
关闭并重新启动所有打开的浏览器。

IE：

单击“工具”菜单
单击“Internet选项”
高级标签
滚动到安全部分
启用TLS 1.0

火狐：

点击工具
点击选项
高级标签
加密标签
启用TLS 1.0

然后你还提到：

这是服务器所在的消息发送其证书以及请求我相信客户证书。

您是否已将客户端证书安装到您正在测试的每个Web浏览器中？

确保您可以在没有相互/客户端身份验证的情况下使所有内容正常工作，然后在其工作后再重新添加。

请求开始时的异常 - ClientAuth SSL

4 个答案: