java – 请求开始时的异常 – ClientAuth SSL

发布时间：2020-12-14 05:12:37 所属栏目：Java 来源：网络整理

导读：我有一个嵌入Jetty的应用程序.我想在SSL中使用客户端证书认证,当我启用它时;我在请求开始时收到以下异常.但是之后请求得到正确的提供.此异常仅在从IE或Chrome访问时才会出现.从Firefox访问时不会出现.我们有自己的SSLConnector扩展SslSocketConnector.我试图

我有一个嵌入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

解决方法

我已经看到像TLS / SSLv3协商这样的问题.
http://www.oracle.com/technetwork/java/javase/documentation/tlsreadme2-176330.html

In SSL/TLS,renegotiations can be initiated by either side. Like the Phase 1 fix,applications communicating with an un-upgraded peer in Interoperable mode and that attempt to initiate renegotiation (via SSLSocket.startHandshake() or SSLEngine.beginHandshake()) will receive a SSLHandshakeException (IOException) and the connection will be shutdown (handshake_failure). Applications that receive a renegotiation request from a non-upgraded peer will respond according to the type of connection in place:

TLSv1: A warning Alert message of type “no_renegotiation(100)” will be sent to the peer and the connection will remain open. Older versions of SunJSSE will shutdown the connection when a “no_renegotiation” Alert is received.

SSLv3: The application will receive a SSLHandshakeException,and the connection will be closed (handshake_failure). (“no_renegotiation” is not defined in the SSLv3 spec.)

To set these modes,two system properties are used:

sun.security.ssl.allowUnsafeRenegotiation – Introduced in Phase 1,this controls whether legacy (unsafe) renegotiations are permitted.

sun.security.ssl.allowLegacyHelloMessages – Introduced in Phase 2,this allows the peer to handshake without requiring the proper RFC 5746 messages.

如果仍然没有帮助,您可以尝试打开SSL dedug,并看看握手.-Djavax.net.debug =所有

（编辑：李大同）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!