Java 7 con TLSv1.2 se conecta al error de reconocimiento de LDAPS

Actualmente estoy usando Java 7 y no puedo conectarme a LDAPS. Intenté con el siguiente código, pero aún no puedo conectarme:

SSLContext ctx = SSLContext.getInstance("TLSv1.2"); ctx.init(null, null, null); SSLContext.setDefault(ctx); 

A continuación se muestra el error que recibo de mi progtwig:

2018-04-10 15: 21: 23,446 INFO [stdout] (EJB predeterminado – 1) EJB predeterminado – 1, ESCRIBIR: Apretón de manos TLSv1.2, longitud = 221

2018-04-10 15: 21: 23,446 INFO [stdout] (EJB por defecto – 1) EJB por defecto – 1, LEER: TLSv1.2 Alerta, longitud = 2

2018-04-10 15: 21: 23,446 INFO [stdout] (EJB predeterminado – 1) EJB predeterminado – 1, RECV TLSv1 ALERTA: fatal, handshake_failure

2018-04-10 15: 21: 23,446 INFO [stdout] (EJB predeterminado – 1) EJB predeterminado – 1, llamado closeSocket ()

2018-04-10 15: 21: 23,446 INFO [stdout] (EJB predeterminado – 1) EJB predeterminado – 1, excepción de manejo: javax.net.ssl.SSLHandshakeException: Alerta fatal recibida: handshake_failure


Después de eso, he intentado ejecutar Prueba de protocolo para verificar los protocolos compatibles:

 Supported Protocols: 5 SSLv2Hello SSLv3 TLSv1 TLSv1.1 TLSv1.2 Enabled Protocols: 1 TLSv1 

He agregado la línea a continuación para deshabilitar TLSv1 y habilitar TLSv1.2 en java.security :

 jdk.tls.disabledAlgorithms= SSLv3, SSLv2Hello, TLSv1, TLSv1.1 

Y ejecuta nuevamente la Prueba de Protocolo y el resultado es:

 Supported Protocols: 5 SSLv2Hello SSLv3 TLSv1 TLSv1.1 TLSv1.2 Enabled Protocols: 0 

He confirmado que mi servidor LDAPS es compatible y utiliza TLSv1.2. También habilité TLS1.2 en el Panel de control de Java porque siempre que intenté usar TLSv1 se produce un error de protocol_version


Mis preguntas son:

  1. ¿Qué es RECV TLSv1 ALERT: fatal, handshake_failure ?
  2. ¿Cómo habilitar TLSv1.2 en Protocolos soportados?
  3. Editar ¿Java 7 u 8 admiten el conjunto de cifrado: ECDHE-ECDSA-AES256-GCM-SHA384 ?

Estoy usando Java 1.7_80.

  1. ¿Qué es ALERTA RECV TLSv1: fatal, handshake_failure?

Significa que recibimos (en el código Java SSL / TLS, JSSE) una alerta del servidor con gravedad grave y el tipo handshake_failure. Dado que ocurre inmediatamente después de enviar un mensaje de reconocimiento, si no omitió otra información relevante del extracto de registro publicado, presumiblemente recibimos esta alerta en respuesta al mensaje de ClientHello, que es el primer mensaje enviado.

El ‘TLSv1’ aquí puede ser engañoso. Es una variable en el objeto SSLSocketImpl que se inicializa a TLSv1 y no se actualiza hasta que se completa el protocolo de enlace, por lo que en este momento no indica con precisión las versiones de protocolo que se están utilizando. La entrada de registro anterior , ‘LECTURA: Alerta TLSv1.2, longitud = 2’ muestra la versión real recibida y confirma que el servidor al menos está intentando hacer TLS1.2.

¿Qué causa handshake_failure? Muchas y muchas cosas. Es prácticamente imposible distinguir de esta alerta cuál es el problema.

  • Su mejor opción es mirar los registros del servidor y averiguar por qué dice que envió la alerta.

  • Su peor opción es mirar el ClientHello que enviamos, gran parte de lo cual debería haber sido registrado por JSSE antes de las líneas que publicó, y considerar todo lo que está allí, o no, el valor o la ausencia del servidor que no le gusta, Y trata de cambiar cada uno de ellos. Algunos son moderadamente fáciles de cambiar y otros son muy difíciles, por lo que esto puede llevar entre horas y semanas.

  • Si tiene algún otro cliente (s) que se conecte con éxito al mismo servidor, una opción intermedia es mirar las diferencias en el ClientHello entre el que funciona y el que no, y considerarlas. Como un caso de esto, si tiene u obtiene OpenSSL, la línea de comandos openssl s_client es rápida y bastante fácil de usar para probar algunas, aunque no todas, las variaciones en el protocolo de enlace SSL / TLS.

Probablemente puedas adivinar lo primero que recomiendo.

  1. ¿Cómo habilitar TLSv1.2 en Protocolos soportados?

No es necesario habilitarlo en soporte; Necesitas habilitarlo en protocolos habilitados y ya lo hiciste. El uso de SSLContext.getInstance("TLSv1.2") es una forma. En Java 8, pero no (editar) las actualizaciones gratuitas de Oracle de 7, usar sysprop jdk.tls.client.protocols es otra forma. (7u95 hasta implementar este sysprop, pero para las actualizaciones de Oracle 7 por encima de 7u80 es necesario realizar un pago. Si OpenJDK está disponible en su plataforma, a menudo es gratis).

  1. Editar ¿Java 7 u 8 admiten el conjunto de cifrado: ECDHE-ECDSA-AES256-GCM-SHA384? Estoy usando Java 1.7_80.

Oracle / Sun y OpenJDK 7 no son compatibles con los conjuntos de cifrado GCM. O para ser exactos, el proveedor estándar de JSSE en ellos no lo hace, y usted no dijo nada sobre cambiar a los proveedores. (IBM Java usa diferentes proveedores y no los conozco, pero en su mayoría usan un formato de denominación diferente).

Oracle y OpenJDK 8 son compatibles con las suites GCM. Sin embargo, las actualizaciones anteriores de Oracle no son compatibles con AES de 256 bits a menos que descargue e instale los archivos de la ‘Política de Jurisdicción Ilimitada’; Hay muchas otras preguntas sobre esto que puedes encontrar. Esto fue arreglado recientemente; 8u151 / 152 solo necesita una edición de texto que no descargue archivos, y 8u161 / 162 y superiores no necesitan ningún cambio en absoluto. Tampoco Oracle 9, o cualquier OpenJDK.