sun.security.validator.ValidatorException: SunCertPathBuilderException - 导入证书时

2022-01-25 00:00:00 https ssl-certificate java

我遇到了异常

sun.security.validator.ValidatorException:PKIX 路径构建失败:sun.security.provider.certpath.SunCertPathBuilderException:无法找到到所请求目标的有效证书路径

sun.security.validator.ValidatorException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target

我已在该位置设置 SSL 证书

I have set the SSL certificate in the location

C:Program FilesAdoptOpenJDKjdk-11.0.9.11-hotspotlibsecurity

C:Program FilesAdoptOpenJDKjdk-11.0.9.11-hotspotlibsecurity

keytool -import -keystore cacerts -file C:Users estDesktopCertificateoCertificate.cer

但是我在访问服务器时遇到了上述异常.

But i am getting the above exception while i am hitting the server.

我看到的结果我已将证书添加到 Jdk cacerts 文件中，但它工作了两天，然后我又遇到了同样的错误.我无法让它工作我能够成功地 ping 服务器而不是再次显示异常.

Results i saw I have added the certificate to the Jdk cacerts file but then it worked for two days than again i was getting the same error. I am unable to get it was working i am able to succesfully ping the server than again it is showing the exception.

推荐答案

你描述的问题是运行keytool导入证书给你这个错误吗?请提供选项 -trustcacerts 并查看相关文档:

Is the problem you describe that running keytool to import the certificat gives you this error? Please provide the option -trustcacerts and see the documentation about this:

导入新的可信证书

在将证书添加到密钥库之前，keytool 命令通过尝试从中构建信任链来验证它证书到自签名证书(属于根 CA)，使用密钥库中已有的可信证书.

Before you add the certificate to the keystore, the keytool command verifies it by attempting to construct a chain of trust from that certificate to a self-signed certificate (belonging to a root CA), using trusted certificates that are already available in the keystore.

如果指定了 -trustcacerts 选项，则附加证书被考虑用于信任链，即cacerts 文件中的证书.

If the -trustcacerts option was specified, then additional certificates are considered for the chain of trust, namely the certificates in a file named cacerts.

如果 keytool 命令无法从要导入的证书最多为自签名证书(从密钥库或 cacerts 文件)，然后是证书打印信息，并提示用户通过以下方式进行验证将显示的证书指纹与指纹进行比较从其他(可信的)信息来源获得，这些信息可能成为证书所有者.非常小心，以确保证书是在将其作为可信证书导入之前有效.然后用户有停止导入操作的选项.如果 -noprompt 选项指定，则不与用户交互.

If the keytool command fails to establish a trust path from the certificate to be imported up to a self-signed certificate (either from the keystore or the cacerts file), then the certificate information is printed, and the user is prompted to verify it by comparing the displayed certificate fingerprints with the fingerprints obtained from some other (trusted) source of information, which might be the certificate owner. Be very careful to ensure the certificate is valid before importing it as a trusted certificate. The user then has the option of stopping the import operation. If the -noprompt option is specified, then there is no interaction with the user.

来源:https://docs.oracle.com/en/java/javase/11/tools/keytool.html

另外，您可能会发现 keytool 不是非常用户友好，您可能会喜欢其他软件，例如:https://keystore-explorer.org/downloads.html 更多.

Alternatively you may find that keytool is not very user-friendly and you may enjoy other software like: https://keystore-explorer.org/downloads.html more.

或者，如果问题是您的(TLS 客户端，甚至 TLS 服务器)软件存在一些证书问题，则可能是因为 jccampanero 已经建议服务器可能已切换到不同的证书，或者据我所知服务器实际上可能是负载均衡器后面的几个不同的服务器，它们可能并不都具有相同的证书.(或者您可能安装了一些 Java 更新来替换默认的 cacerts 文件?)

Or if the problem is that your (TLS-client, or even TLS-server) software has some certificate issue it might be as jccampanero already suggested that the server might have switched to a different certificate, or for all I know the server may actually be several different servers behind a load-balancer which may not all have the same certificates. (Or maybe you installed some Java update that replaced the default cacerts file?)

如果出现问题，我强烈建议阅读 JSSE 文档并使用 java 选项 -Djavax.net.debug=all 或可能比 all 喜欢 handshake 参见 Java 11 文档:

In case of problems I highly recommend reading the JSSE-documentation and enabling debug logging with java option -Djavax.net.debug=all or maybe a little less than all like handshake see the Java 11 docs at:

https://docs.oracle.com/en/java/javase/11/security/java-secure-socket-extension-jsse-reference-guide.html#GUID-31B7E142-B874-46E9-8DD0-4E18EC0EB2CF

这显示了您的应用程序使用的确切 TrustStore、服务器在握手期间提供的证书以及许多其他作为 TLS 握手一部分的协商内容.

This shows the exact TrustStore your application uses, the certificate(s) that the server offers during the handshake and a lot of other negotiation stuff that is part of the TLS handshake.

如果您希望完全控制您信任的颁发证书的人，您可以配置自己的信任库，而不是可以在 Java 安装之外使用的默认信任库，选项如下:

If you prefer full control of who you trust to issue certificates you can configure your own truststore instead of the default that can live outside your Java installation with options like:

java -Djavax.net.ssl.trustStore=samplecacerts -Djavax.net.ssl.trustStorePassword=changeit Application

我相信研究此调试日志记录应该可以直接解决问题，如果不能解决问题，请向我们提供一些相关的日志记录.

I trust that studying this debug logging should make it straightforward to resolve the issue, if it doesn't please provide us with some of the relevant logging.

相关文章