我们必须使用HTTPS将我们的应用程序（用Java 8编写）连接到一些非常旧的服务器。 作为Java 8，我们的客户端支持TLSv1.2，TLSv1.1，TLSv1和SSLv3。 当然，它更喜欢使用TLSv1.2，因为它是最新的协议。
服务器（Oracle-HTTP-Server 11.1.1.7）只支持TLSv1和SSLx。 此外，它支持的密码套件的select非常有限，但是仍然有一个共同的套件可用于TLSv1：SSL_RSA_WITH_3DES_EDE_CBC_SHA（又名TLS_RSA_WITH_3DES_EDE_CBC_SHA）。
但是，直接连接失败与服务器终止握手。 我们得到的debugging输出（在客户端）如下所示：
main, WRITE: TLSv1.2 Handshake, length = 265 main, READ: TLSv1 Alert, length = 2 main, RECV TLSv1.2 ALERT: fatal, close_notify main, called closeSocket() main, handling exception: javax.net.ssl.SSLException: Received fatal alert: close_notify 对我来说，看起来服务器甚至不会尝试回退到TLSv1：只要客户声明TLSv1.2为首选，服务器就会退出。
相比之下，当我们在客户端中明确地禁用TLSv1.2和TLSv1.1，从而使TLSv1成为首选的选项时，握手就成功了。
我们还试图连接到另一个不知道TLSv1.2和TLSv1.1的旧版服务器，但是这里的连接按预期工作：即使客户端说它喜欢TLSv1.2，但他们同意服务器使用TLSv1，作为最佳通用协议：
main, WRITE: TLSv1.2 Handshake, length = 269 main, READ: TLSv1 Handshake, length = 85 ...
问题：服务器是否有责任从客户端支持的TLS / SSL协议列表中select？ 我可以对服务器维护人员说服务器是不正常的，而不是我们的客户吗？
服务器是否有责任从客户端支持的TLS / SSL协议列表中select？
客户端不提供受支持版本的列表。 客户端提供了它可以提供的最好的版本，并且服务器应该回复服务器支持的与客户端版本相同或更低的最佳版本。 如果客户端不愿意接受太低的版本，则客户端将抛出错误并closures连接。
我可以对服务器维护人员说服务器是不正常的，而不是我们的客户吗？
我想你可以这么说。 任何正确实现TLS 1.0的服务器都应该能够处理来自客户端的TLS 1.2连接，因为协议是专门devise的。 不幸的是，在那里还是有足够的破碎的TLS实现。