Excepción al inicio de la solicitud: ClientAuth SSL

Question

Tengo una aplicación que integra Jetty. Me gustaría utilizar la autenticación de certificado de cliente en SSL y cuando lo habilite; Recibo la siguiente excepción al inicio de la solicitud. Pero la solicitud se está atendiendo correctamente después de eso. Esta excepción solo se obtiene cuando se accede desde IE o Chrome. No viene cuando se accede desde Firefox. Tenemos nuestro SSLConnector personalizado que extiende SslSocketConnector. Estoy intentando depurarlo; pero quería saber si hay algún lugar/código específico donde pueda comenzar a verificar.

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) 

Actualización:

He activado la opción de depuración de SSL y estaba recibiendo esta excepción en una lectura inmediatamente después del mensaje ServerHelloDone. Este es el mensaje donde el servidor envía su certificado junto con la solicitud del certificado del cliente, creo. No estoy seguro de lo que está sucediendo en la primera lectura. Cualquier ayuda es muy apreciada.

*** 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 

Actualización: Actualizado JDK a más tardar, el 23 y el tratado con las dos propiedades activado/desactivado. Todavía obteniendo el mismo comportamiento.

Más información: TLSv1 y SSLv3 están habilitados en todos los navegadores. La comunicación está sucediendo correctamente sin la autenticación de cliente habilitada. Con la autenticación del cliente, siempre obtenemos una excepción en el primer apretón de manos y la siguiente se realiza correctamente y continúa sin excepciones. Uso de la versión de embarcadero 6.1.14 en el lado del servidor

Answer 1

He visto problemas como este con la negociación de TLS/SSLv3. http://www.oracle.com/technetwork/java/javase/documentation/tlsreadme2-176330.html

En SSL/TLS, renegociaciones puede ser iniciado por cualquier lado. Al igual que la Fase 1, las aplicaciones que se comunican con un par no actualizado en modo Interoperable y que intentan iniciar la renegociación (a través de SSLSocket.startHandshake() o SSLEngine.beginHandshake()) recibirán un SSLHandshakeException (IOException) y la conexión se cerrará (handshake_failure). Las aplicaciones que reciban la solicitud de renegociación de un compañero no actualizado responderán de acuerdo con el tipo de conexión en su lugar:

• TLSv1: Una advertencia Alert mensaje del tipo "no_renegotiation (100)" serán enviados a los pares y la conexión permanecerá abierta. Las versiones anteriores de SunJSSE cerrarán la conexión cuando se reciba una alerta "no_renegotiation".
• SSLv3: La aplicación recibirá un SSLHandshakeException, y la conexión se cerrará (handshake_failure). ("no_renegotiation" no está definido en la especificación SSLv3)

Para configurar estos modos, dos propiedades del sistema se utilizan:

• sun.security.ssl.allowUnsafeRenegotiation - introducidos en la fase 1, esto controla si legado (inseguro) renegociaciones son permitidas
• sun.security.ssl.allowLegacyHelloMessages - Introducido en la Fase 2, esto permite que el compañero apruebe sus manos sin requerir los mensajes adecuados de RFC 5746.

Si aún así no funciona, puede intentar encender dedug SSL, y echar un vistazo a la toma de contacto.
-Djavax.net.debug=all

Answer 2

Pruebe la nueva jdk. Ellos arreglaron un error de handshake SSL. http://www.java.net/blogs/kumarjayanti/

Answer 3

Sigo pensando que esto es un problema de negociación de TLS/SSL.

Después de que haya presentado la información de depuración, muestra que está haciendo un apretón de manos TLSv1.

¿Estás seguro de que tienes TLSv1 habilitado en tus navegadores?

Chrome: Con el fin de habilitar TLS 1.0 en cromo haga lo siguiente:

1. Haga clic en el icono de llave inglesa:
2. Seleccione Opciones
3. Seleccionar "bajo el capó" Tab
4. Haga clic en Cambiar configuración de proxy
5. Seleccione la pestaña "Avanzado"
6. Desplácese y compruebe TLS 1.0
7. Cierre y reinicie todos los navegadores abiertos.

IE:

1. Haga clic en el menú Herramientas
2. Haga clic en Opciones de Internet
3. pestaña Avanzado
4. de desplazamiento hasta la sección Seguridad
5. habilitar TLS 1.0

Firefox :

1. Haga clic en Herramientas
2. Haga clic en Opciones
3. pestaña Avanzado
4. ficha Cifrado
5. habilitar TLS 1,0

A continuación, también se menciona que:

Este es el mensaje donde el servidor envía su certificado junto con la solicitud de certificado de cliente creo.

¿Ha instalado el certificado del cliente en cada uno de los navegadores web desde los que está realizando la prueba?

Asegúrese de que puede hacer que todo funcione sin autenticación mutual/cliente primero, y luego una vez que esté funcionando, agréguelo de nuevo.

Answer 4

Obtuve esto cuando accidentalmente puse el puerto no ssl en la URL pero comencé la URL con https. Doh.

¡A veces las soluciones más simples son las que olvidamos!