java.security.NoSuchAlgorithmException:(算法:默认，提供者:SunJSSE，类:sun.security.ssl.SSLContextImpl$DefaultSSLContext) [英] java.security.NoSuchAlgorithmException: (algorithm: Default, provider: SunJSSE, class: sun.security.ssl.SSLContextImpl$DefaultSSLContext)

问题描述

我从网上尝试了许多解决方案.但似乎没有任何解决方案适合我.

I tried many solutions from the web. But no solution seem to be fit to me.

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

We recently upgraded tomcat server 8.0.x to 8.5.x. With 8.0.x Everything worked fine. But after upgrade, We are facing this error when we are trying to connect to a server from java's Spring restTemplate with https.

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

I did not see any errors while connecting through 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)

推荐答案

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

Some background about recent changes in tomcat 8.5.x: (as Explained by @dave-thompson-085 in another post)

Java 8u60 up getInstance("JKS")(用普通提供者)可以读取JKS 或 PKCS12，但PKCS12"仅在发生时读取 PKCS12这里.在 9 和 10(我还没有尝试过 11)中，它可以双向工作，但是 OP 的堆栈跟踪没有像 9 up 那样显示模块.雄猫 8.5(和 9.0)主要重写了 SSL/TLS 配置区域以处理多个certs (SNI) 并对齐以前不同的 JSSE 与APR=OpenSSL 配置，但在我看来，它仍应默认为 JKS除非你(错误)设置了 javax.net.ssl.keyStoreType

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，因为这已被用作这些天的行业标准.

How we fixed this:
In tomcat 8.0 default value for javax.net.ssl.keyStoreType is JKS. After we upgraded to tomcat 8.5.x, they changed to PKCS12 as this is being used as industry standard these days.

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

After breaking my head for some time, noticed that, In tomcat.conf file, VM arguments configured to use PKCS12. I changed to JKS. Everything worked fine after.

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

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

Tip: If you cannot find tomcat.conf file, search for the file that contains string of "-Djavax.net.ssl.keyStoreType" in side tomcat directory. I saw that, Windows portable tomcat does not have that file.

这篇关于java.security.NoSuchAlgorithmException:(算法:默认，提供者:SunJSSE，类:sun.security.ssl.SSLContextImpl$DefaultSSLContext)的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！