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没有那个文件。