连接到https站点时发生SSLHandshakeException

连接到https站点时发生SSLHandshakeException

SSLlabs显然正在测试“开箱即用”的支持。Java加密技术可以追溯到1990年代，当时美国政府严格限制了加密软件的出口，因此 ，当时的Sun发行
了JRE（或JDK） ，Sun现在开始了。Oracle 不允许使用 256位
对称加密，这是您的服务器要求的。您必须为您的Java（主要）版本下载并安装“ JCE无限强度
管辖权策略文件”；图8在http://www.oracle.com/technetwork/java/javase/downloads/jce8-download-2133166.html上。文件中的README提供了冗长的细节，但是基本上您可以在JRE
/ lib / security中替换两个小jar文件。

TLSv1.2工作 是不是一个真正的问题 现在 。TLS协议自动协商两端支持（和启用）的最高版本。Java 8 实现了
SSLv3，TLSv1.0，TLSv1.1和TLSv1.2，但是由于POODLE的缘故， 默认情况下 ，最近的更新（8u31或7u75及更高版本）
默认 禁用 SSLv3 。您可以根据需要重新启用它，但是您不愿意这样做。（Java 7实现了相同的协议版本，但是默认情况下，由于禁用兼容性，
客户端 默认禁用1.1和1.2。）

但是，由于POODLE和BEAST，一些安全性机构不再接受SSLv3和TLSv1.0的足够安全性。一个重要的示例是xyk和借记卡，如https://security.stackexchange.com/a/87077/39571中所述。TLSv1.2包含了超过1.1的一些技术改进，使其成为当今的
首选 ，并且可能会有未来的发现使这些改进变得至关重要。如果您的服务器 当时 不支持1.2（甚至更高） ，
您将会遇到麻烦。类似地，服务器唯一支持的套件使用纯RSA密钥交换（即非前向保密性）的事实现在被认为不是最佳的，随着时间的流逝，它可能会变得不可接受。

keytool （至少与通常使用的密钥库和信任库文件有关）与对称密码无关。如果服务器使用您的JRE和/或应用程序不信任的 CA根目录
（或更确切地说，更一般地说是信任锚），并且/或者服务器希望使用 SSL / TLS级别的 客户端身份验证
，则可能是相关的这是相当罕见的。（至少在Web应用程序级别大多数网站身份验证，或HTTP水平，如果在所有。）SSLLabs服务器证书链（和一些其他的东西也可以）的检查一般是严格比Java的，他们并没有抱怨
那 区域，因此不太可能在那里出现问题。