OpenShift迅速解决了SSL＆＃39; Poodle＆＃39; 2014年10月16日左右的漏洞。从那时起，我使用的电子商务提供商再也无法与我的OpenShift PHP应用程序建立安全的HTTPS连接。我怀疑这至少部分是因为SSL3不再是可用的协议。
电子商务提供商端记录的错误是：
javax.net.ssl.SSLException
java.lang.RuntimeException: Could not generate DH keypair
这是我迄今为止尝试和发现的内容：
https://www.ssllabs.com/ssltest/处的在线SSL测试工具表明我的SSL证书已正确安装（通过OpenShift WebConsole安装），并且它收到了一个＆＃39; A＆＃39;年级。在普通Web浏览器中连接到我的OpenShift PHP应用程序时，HTTPS工作正常。一般来说，SSL证书＆amp;安装本身似乎很好。
作为测试，我尝试使用OpenShift的共享SSL证书而不是我自己的证书，结果完全相同。
尝试通过HTTPS连接到我的OpenShift PHP应用程序的远程电子商务平台使用Java 7.技术支持认为问题是他们的Java 7系统不支持密码密钥长度＆gt; 1024位。不幸的是，他们目前无法将系统升级到Java 8，所以他们的手有点紧张。
我的SSL Certficate的ssllabs分析包括一个与各种客户进行的有用的握手模拟测试。这实际上显示了使用TLS1.0连接OK的Java 7模拟，但是Java 6模拟失败并且客户端不支持DH参数＆gt; 1024位＆＃39;错误 - 大致回应了基于Java 7的系统报告的电子商务技术支持。
我怎么解决这个问题？将问题缩小一点：
我的电子商务提供商是否可以通过简单的调整来启用与OpenShift应用程序的HTTPS连接，而无需升级Java或进行可能影响其他人的重大更改？例如接受DH参数的选项＆gt; 1024位。
我可以在我的最后调整（可能是OpenShift或PHP设置）以使基于Java 7的系统能够成功地与我的OpenShift应用程序建立HTTPS连接吗？例如一个选项，指示OpenShift提供DH参数＆lt; = 1024位。
答案 0 :(得分：1)
重新启动应用程序应解决此问题，因为它将获取应包含此问题的最新修补程序的最新JDK。
https://bugzilla.redhat.com/show_bug.cgi?id=1035818
https://bugzilla.redhat.com/show_bug.cgi?id=1080125