[10月19日，我升级到OpenJDK Java 1.8.0_232，并且我的Java进程开始无法使用EC服务器证书连接到以stunnel开头的服务。我有一个EC客户端证书，如果初始握手成功，我将向服务器出示该证书，但是还没到那么远。
我无法获得正在运行的Java 上一个版本的版本号-我在客户端上运行了很长时间的过程能够成功连接到服务。 Java已升级，但是自升级以来尚未重新启动该客户端。我重新启动了客户端，它也开始失败。
我将开始阅读announcement，以查看其中是否有任何东西可以暗示某个东西的“修复”，但是我相信我在客户端和服务器上都配置正确。我目前的想法是，这是JVM中的错误。
使用ssltest，我能够确认提供正确的客户端证书时，只要使用Java 1.8.0_181或Java 11.0.3（这两个是两者，则可以使用多个密码套件与服务器进行握手）我碰巧躺在笔记本电脑上进行测试的版本）。使用Java 1.8.0_232时，使用相同的文件，命令行等失败。
有人见过这样的东西吗？
UPDATE
我已经从here下载了x86-64 OpenJDK版本8u222和8u232，并且我可以确认版本8u222将连接而8u232将不连接。
UPDATE降级到OpenJDK的先前版本暂时解决了我的问题。我正在使用Debian Stretch，可以通过以下命令降级：
$ sudo apt-get install openjdk-8-jdk-headless=8u222-b10-1~deb9u1 openjdk-8-jre-headless=8u222-b10-1~deb9u1
请注意，我只安装了“ headless”软件包，因此我只降级了“ headless”软件包。
UPDATE我可以在这里确认客户证书是红色鲱鱼。我放宽了对服务器的要求，使其不需要客户端证书，并且初始TLS握手仍然失败。我正在尝试将范围缩小到我可以得到的最简单的测试用例。
UPDATE仍在尝试诊断问题，请点击此处。我有一个测试服务器，可以在其中以各种配置启动它并查看会发生什么。我确定Java 8u222支持secp256k1曲线，而Java 8u232不支持，并且握手失败。
secp256k1曲线已被jdk 8u232禁用（请参见https://java.com/en/download/faq/release_changes.xml）。可以使用Java系统属性jdk.tls.namedGroups重新启用它。
常见问题上的示例列出了其他一些过时的NIST EC曲线也被禁用。列出的曲线为sect283k1，sect283r1，sect409k1，sect409r1，sect571k1，sect571r1和secp256k1。系统属性jdk.tls.namedGroups包含这些名称的逗号分隔列表。