带有TLSv1.2的Java 7连接到LDAPS握手失败 [英] Java 7 with TLSv1.2 connect to LDAPS handshake failure

问题描述

当前，我正在使用Java 7，但无法连接到LDAPS.我尝试使用下面的代码，但仍然无法连接:

Currently I am using Java 7 and I am unable to connect to LDAPS. I tried with the code below, but I am still unable to connect:

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

以下是我从程序中得到的错误:

Below is the error I get from my program:

2018-04-10 15:21:23,446信息[stdout](EJB默认-1)EJB默认-1，WRITE:TLSv1.2握手，长度= 221

2018-04-10 15:21:23,446 INFO [stdout] (EJB default - 1) EJB default - 1, WRITE: TLSv1.2 Handshake, length = 221

2018-04-10 15:21:23,446 INFO [stdout](EJB默认-1)EJB默认-1，读取:TLSv1.2警报，长度= 2

2018-04-10 15:21:23,446 INFO [stdout] (EJB default - 1) EJB default - 1, READ: TLSv1.2 Alert, length = 2

2018-04-10 15:21:23,446信息[stdout](EJB默认-1)EJB默认-1，RECV TLSv1警报:致命，handshake_failure

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

2018-04-10 15:21:23,446 INFO [stdout](EJB默认-1)EJB默认-1，称为closeSocket()

2018-04-10 15:21:23,446 INFO [stdout] (EJB default - 1) EJB default - 1, called closeSocket()

2018-04-10 15:21:23,446信息[stdout](EJB默认-1)EJB默认-1，处理异常:javax.net.ssl.SSLHandshakeException:收到致命警报:handshake_failure

2018-04-10 15:21:23,446 INFO [stdout] (EJB default - 1) EJB default - 1, handling exception: javax.net.ssl.SSLHandshakeException: Received fatal alert: handshake_failure

---

之后，我尝试运行协议测试以检查受支持的协议:

---

After that I have tried to run Protocol Test to check supported protocols:

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

我在下面添加了以下行以禁用TLSv1并在java.security中启用TLSv1.2:

I have added the line below to disable TLSv1 and enable TLSv1.2 in java.security:

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

并再次运行协议测试，结果是:

And run again the Protocol Test and it the result is:

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

---

我已确认我的LDAPS服务器受支持并使用TLSv1.2.我还启用了Java控制面板中的TLS1.2，因为每当我尝试使用TLSv1时，都会导致protocol_version错误

我的问题是:

1. 什么是RECV TLSv1 ALERT: fatal, handshake_failure?
2. 如何在支持的协议中启用TLSv1.2?
3. 编辑 Java 7或8是否支持密码套件:ECDHE-ECDSA-AES256-GCM-SHA384?

1. What is RECV TLSv1 ALERT: fatal, handshake_failure ?
2. How to enable TLSv1.2 in supported Protocols?
3. Edit Does Java 7 or 8 support cipher suite: ECDHE-ECDSA-AES256-GCM-SHA384?

我正在使用Java 1.7_80.

I'm using Java 1.7_80.

推荐答案

1. 什么是RECV TLSv1警报:致命，握手失败?

这意味着我们收到了来自服务器的警报(使用Java SSL/TLS代码JSSE)，严重性为致命，并键入handshake_failure.由于它是在发送一条握手消息后立即发生的，因此，如果您没有忽略发布的日志摘录中的其他相关信息，那么我们大概会收到此警报，以响应ClientHello消息，这是发送的第一条握手消息.

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.

此处的"TLSv1"可能会产生误导.它是SSLSocketImpl对象中的一个变量，该变量已初始化为TLSv1，并且直到握手完成后才更新，因此在该时间点它不能准确指示所使用的协议版本. 上一个日志条目"READ:TLSv1.2 Alert，length = 2" 确实显示收到的实际版本，并确认服务器至少正在尝试执行TLS1.2 .

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.

• 您最好的选择是查看服务器日志，并找出为什么它说它发送了警报.

最糟糕的选择是查看我们发送的ClientHello-其中许多应该已由JSSE在您发布的行之前记录下来-考虑其中的所有内容，或者而不是在那里，服务器可能会不喜欢它们的价值或缺失，然后尝试更改它们中的每一个.有些比较容易更改，有些则非常困难，因此这可能需要数小时到数周的时间.

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.

如果您有其他可以成功连接到同一服务器的客户端，则一个中间选项是查看ClientHello与正常工作的客户端之间的差异，并考虑那些.作为这种情况的一种情况，如果您拥有或获得OpenSSL，则命令行openssl s_client可以快速，非常简单地用于测试SSL/TLS握手中的某些(虽然不是全部)变体.

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. 如何在支持的协议中启用TLSv1.2?

您无需在受支持的环境中启用它；您需要在 enabled 协议中启用它，而您已经做到了.使用SSLContext.getInstance("TLSv1.2")是一种方法.在Java 8中，但不是(编辑)免费的Oracle 7更新，使用sysprop jdk.tls.client.protocols是另一种方法. (7u95 up实现此系统支持，但是对于7u80以上的Oracle 7更新，则需要付款.如果OpenJDK在您的平台上可用，则通常是免费的.)一旦拥有SSLSocket，则调用.setEnabledProtocols是另一种方法.

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. 编辑Java 7或8是否支持密码套件:ECDHE-ECDSA-AES256-GCM-SHA384? 我正在使用Java 1.7_80.

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

Oracle/Sun和OpenJDK 7不支持GCM密码套件.确切地说，它们中的标准JSSE提供程序没有提供，并且您也没有说过更改提供程序的任何内容. (IBM Java使用不同的提供程序，我不知道它们，但是它们大多数使用不同的命名格式.)

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和OpenJDK 8确实支持GCM套件.但是，较早的 Oracle 更新不支持256位AES，除非您下载并安装了无限管辖权政策"文件.您还可以找到许多其他的问题.这是最近修复的； 8u151/152仅需要进行文本编辑，而无需下载文件，而8u161/162及更高版本完全不需要任何更改. Oracle 9或任何OpenJDK都没有.

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.

这篇关于带有TLSv1.2的Java 7连接到LDAPS握手失败的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！