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”）（具有常规提供程序）可以读取 JKS或PKCS12，但是“ PKCS12”仅在发生时读取PKCS12 这里。在9和10（我还没有尝试过11）中，它可以双向工作，但是OP的stacktrace不会将模块显示为9 up。的Tomcat 8.5 （和9.0）主要重写了SSL / TLS配置区域以处理多个证书（SNI）并对齐以前不同的JSSE与 APR = OpenSSL配置，但据我所知仍应默认为JKS 除非您（错误）设置了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便携式tomcat没有该文件。

java.security.NoSuchAlgorithmException ：（算法：默认，提供程序：SunJSSE，类：sun.security.ssl.SSLContextImpl $ DefaultSSLContext）

1 个答案: