Java 7 with TLSv1.2 connect to LDAPS handshake failure

早过忘川 提交于 2019-12-02 07:55:38
  1. What is RECV TLSv1 ALERT: fatal, handshake_failure ?

It means we received (in the Java SSL/TLS code, JSSE) an alert from the server with severity fatal and type handshake_failure. Since it occurs immediately after sending one handshake message, if you didn't omit other relevant information from the log extract you posted, we presumably received this alert in response to the ClientHello message, which is the first handshake message sent.

The 'TLSv1' here may be misleading. It is a variable in the SSLSocketImpl object which is initialized to TLSv1 and not updated until the handshake completes, so at this point in time it doesn't accurately indicate the protocol version(s) being used. The preceding log entry, 'READ: TLSv1.2 Alert, length = 2' does show the actual version received and confirms the server is at least trying to do TLS1.2.

What causes handshake_failure? Lots and lots of things. It is practically impossible to tell from this alert what the problem is.

  • Your best option is to look at the server log(s) and find out why it says it sent the alert.

  • Your worst option is to look at the ClientHello we sent -- much of which should have been logged by JSSE prior to the lines you posted -- and consider everything in there, or not in there, whose value or absence the server might dislike, and try changing each of them. Some are moderately easy to change and some are very difficult, so this could take anywhere between hours and weeks.

  • If you have any other client(s) that connect successfully to the same server, an intermediate option is to look at the differences in the ClientHello between the one that works and the one the doesn't, and consider those. As one case of this, if you have or get OpenSSL, commandline openssl s_client is quick and fairly simple to use to test some though not all variations on SSL/TLS handshake.

You can probably guess I recommend the first.

  1. How to enable TLSv1.2 in supported Protocols?

You don't need to enable it in supported; you need to enable it in enabled protocols and you already did. Using SSLContext.getInstance("TLSv1.2") is one way. In Java 8 but not (edit) free Oracle updates of 7, using the sysprop jdk.tls.client.protocols is another way. (7u95 up implement this sysprop, but for Oracle 7 updates above 7u80 require payment. If OpenJDK is available on your platform it is often free.) Calling .setEnabledProtocols on the SSLSocket, once you have it, is another way.

  1. Edit Does Java 7 or 8 support cipher suite: ECDHE-ECDSA-AES256-GCM-SHA384? I'm using Java 1.7_80.

Oracle/Sun and OpenJDK 7 do not support GCM ciphersuites. Or to be exact the standard JSSE provider in them does not, and you didn't say anything about changing the providers. (IBM Java uses different providers and I don't know about them, but they mostly use a different naming format.)

Oracle and OpenJDK 8 do support GCM suites. However, older Oracle updates do not support 256-bit AES unless you download and install the 'Unlimited Jurisdiction Policy' files; there are lots of other Qs on this you can find. This was recently fixed; 8u151/152 only needs a text edit not downloading files, and 8u161/162 and up doesn't need any change at all. Neither does Oracle 9, or any OpenJDK.

易学教程内所有资源均来自网络或用户发布的内容,如有违反法律规定的内容欢迎反馈
该文章没有解决你所遇到的问题?点击提问,说说你的问题,让更多的人一起探讨吧!