java.security.NoSuchAlgorithmException : (algorithm: Default, 提供者 : SunJSSE, 类 : sun. security.ssl.SSLContextImpl$DefaultSSLContext)

Question

我尝试了网上的许多解决方案。但似乎没有解决方案适合我。

我们最近将 tomcat 服务器 8.0.x 升级到了 8.5.x。使用 8.0.x 一切正常。但是升级后，当我们尝试使用 https 从 java 的 Spring restTemplate 连接到服务器时，我们遇到了这个错误。

通过 http 连接时我没有看到任何错误。

":java.security.NoSuchAlgorithmException: Error constructing implementation (algorithm: Default, provider: SunJSSE, class: sun.security.ssl.SSLContextImpl$DefaultSSLContext);  
    nested exception is java.net.SocketException: java.security.NoSuchAlgorithmException: Error constructing implementation (algorithm: Default, provider: SunJSSE, class: sun.security.ssl.SSLContextImpl$DefaultSSLContext)

Answer 1

关于 tomcat 8.5.x 最近变化的一些背景:(正如 @dave-thompson-085 在另一篇文章中所解释的)

Java 8u60 up getInstance("JKS") (with the normal providers) can read either JKS or PKCS12, but "PKCS12" only reads PKCS12 as is happening here. In 9 and 10 (I haven't yet tried 11) it works both directions, but OP's stacktrace doesn't show modules as 9 up should. Tomcat 8.5 (and 9.0) majorly rewrote the SSL/TLS config area to handle multiple certs (SNI) and also align the previously different JSSE vs APR=OpenSSL configs, but to my reading it should still default to JKS unless you (mis)set javax.net.ssl.keyStoreType

我们如何解决这个问题:
在 tomcat 8.0 中，javax.net.ssl.keyStoreType 的默认值为 JKS。在我们升级到 tomcat 8.5.x 后，它们更改为 PKCS12，因为这几天已被用作行业标准。

经过一段时间的思考后，我注意到，在 tomcat.conf 文件中，VM 参数配置为使用 PKCS12。我改为 JKS。之后一切正常。

将 -Djavax.net.ssl.keyStoreType=PKCS12 更改为 -Djavax.net.ssl.keyStoreType=JKS

提示: 如果找不到 tomcat.conf 文件，请在侧 tomcat 目录中搜索包含“-Djavax.net.ssl.keyStoreType”字符串的文件。我看到了，windows portable tomcat没有那个文件。