Debian SSL证书错误：无法验证xxx证书/ javax.net.ssl.SSLHandshakeException [英] Debian SSL certificates ERROR: cannot verify xxx certificate / javax.net.ssl.SSLHandshakeException

问题描述

我有一个奇怪的问题（这是100％服务器配置问题，）例如我想从Dropbox下载一些东西：

I have a strange problem (it's 100% server configuration problem,) for example I want to download something from Dropbox:

解决dl.dropboxusercontent.com ... 23.23.160.146,50.17.227.107，
54.221.248.69，...连接到dl.dropboxusercontent.com | 23.23.160.146 |：443 ...已连接。错误：
无法验证dl.dropboxusercontent.com的证书，由
发出/ C = US / ST = CA / O = SonicWALL Inc./CN=SonicWALL防火墙DPI-SSL：

遇到自签名证书。要不安全地连接到
dl.dropboxusercontent.com，请使用'--no-check-certificate'。

Resolving dl.dropboxusercontent.com... 23.23.160.146, 50.17.227.107, 54.221.248.69, ... Connecting to dl.dropboxusercontent.com|23.23.160.146|:443... connected. ERROR: cannot verify dl.dropboxusercontent.com’s certificate, issued by "/C=US/ST=CA/O=SonicWALL Inc./CN=SonicWALL Firewall DPI-SSL":
Self-signed certificate encountered. To connect to dl.dropboxusercontent.com insecurely, use ‘--no-check-certificate’.

是的，我知道我可以使用--non-check-certificate但是当我想在Java应用程序中使用SSL连接时，我有类似的东西：

Yes, I know that I can use --non-check-certificate but when I want to use SSL connection in Java app I have something like this:

javax.net.ssl.SSLHandshakeException：
sun.security.validator.ValidatorException：PKIX路径构建失败：
sun.security.provider.certpath.SunCertPathBuilderException：无法
找到有效的认证请求目标的路径

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

此应用程序在其他服务器或本地计算机上运行良好，任何想法在这里有什么问题？

This app works great in other servers or in local machines, any ideas what is wrong here?

推荐答案

/ C = US / ST = CA / O = SonicWALL Inc./CN=SonicWALL防火墙DPI-SSL

/C=US/ST=CA/O=SonicWALL Inc./CN=SonicWALL Firewall DPI-SSL

您的流量被深度数据包检测防火墙明显截获，该防火墙充当MITM代理来监控您的流量。

Your traffic is visibly intercepted by a deep packet inspection firewall that acts as a MITM proxy to monitor your traffic.

这通常可以被认为是合法的MITM攻击者。 （无论合法，这可能取决于许多法律和道德方面。）您的本地网络管理员应该能够告诉您一些相关信息。如果这是公司网络的一部分，该公司正在监控您的流量，包括您的HTTPS连接的内容（因此它不再是端到端的安全）。防火墙正常工作，它仍然应该保护从防火墙到服务器的连接（可能很难知道它是否正确检查证书。）

This can generally be thought of as "legitimate" MITM attacker. (However legitimate this may be depends on a number of legal and ethical aspects.) Your local network administrator should be able to tell you a little bit about this. If this is part of a company network, this company is monitoring your traffic, including the contents of your HTTPS connection (so it's no longer secure from end-to-end). It the firewall does its job properly, it should still secure the connection from the firewall to the server (It's probably hard to know whether it check certificates properly.)

一般情况下，这样的防火墙或代理充当自己的证书颁发机构，有效地根据请求伪造每个证书。

In general, such a firewall or proxy acts as its own Certification Authority, effectively forging each certificate as requested.

企业网络上的大多数客户端都会信任它发出的证书（如因为系统管理员还将CA证书作为可信证书安装到该网络中的每台机器上。您可能拥有操作系统受信任的根证书。

Most clients on the corporate network would trust certificates it issues (like the one you're facing) because system administrators would also install the CA certificate as a trusted certificate into each machine within that network. You probably have it the OS trusted root certificates.

但是，网络管理员可能没有将此CA证书安装到您的JRE安装中（它使用自己的一套默认情况下信任锚。）

However, it is likely that network administrators did not install this CA certificate into your JRE installation (which uses its own set of trust anchors by default).

尝试从参考机器导出该CA证书（请参阅上面的名称）并将其导入您正在使用的信任库（或者JRE的默认信任库： cacerts 或您构建的新信任库，并通过 javax.net.trustStore 属性传递给您的应用程序）。

Try to export that CA certificate (see the name above) from a reference machine and import it into the truststore you're using (either your JRE's default truststore: cacerts or a new truststore you build and pass to your application via the javax.net.trustStore properties).

通常，你可以使用这样的东西（假设你已经将防火墙的CA导出为 firewallca.pem ）：

Typically, you can use something like this (assuming you've exported the Firewall's CA as "firewallca.pem"):

keytool -import -file firewallca.pem -alias firewallca -keystore truststore.jks

如果 truststore.jks 文件不存在，它将会被创造。否则，您可以在JRE的 lib / security 目录中获取 cacerts 文件的副本。您也可以直接在 cacerts 文件上执行此操作（使用 -keystore /path/to/truststore.jks ，提供你有写入权限。）

If the truststore.jks file doesn't exist, it will be created. Otherwise, you can take a copy of the cacerts file in the lib/security directory of your JRE. You can also do this directly on the cacerts file (using -keystore /path/to/truststore.jks, provided you have write access to it).

如果你选择不在默认信任库上做这件事（ cacerts 文件）但使用本地信任库，如 truststore.jks ，您可以在运行应用程序时使用此系统属性来使用它： -Djavax。 net.trustStore = / path / to / truststore.jks

If you choose not to do it on the default truststore (that cacerts file) but use a local truststore like truststore.jks, you'll can use it by using this system property when running your application: -Djavax.net.trustStore=/path/to/truststore.jks

有关配置信任库的其他方法，请检查这个答案。

For other ways of configuring your truststore, check this answer.

另一种解决方法这是告诉Java使用您的操作系统的信任库。我假设你在这里使用Windows。使用这些系统属性应该有效：

Another way to fix this is to tell Java to use your OS's truststore. I'll assume you're using Windows here. Using these system properties should work:

-Djavax.net.trustStore=NONE -Djavax.net.trustStoreType=WINDOWS-ROOT

（尝试使用 WINDOWS-MY 代替 WINDOWS-ROOT 如果这不起作用。）

(Try with WINDOWS-MY instead of WINDOWS-ROOT if this doesn't work.)

WINDOWS-MY / WINDOWS-ROOT 有点儿错误，因为它会遗漏Windows商店中的一些证书：它使用证书友好名称（非unique）作为密钥库别名（唯一），因此具有给定友好名称的证书将隐藏具有相同名称的其他证书。 （这有效地减少了不幸信任的CA证书的数量。）

The WINDOWS-MY/WINDOWS-ROOT is a bit buggy in that it will miss some of the certificates in the Windows store: it uses the certificate "friendly name" (non unique) as the keystore alias (unique), so a certificate with a given friendly name will hide the others with the same name. (This effectively reduces the number of CA certificates that are trusted unfortunately.)

由于您所处的环境可能是所有流量都通过DPI防火墙， ll可能只需要最多使用一个CA证书。只要它不与Windows列表中的任何其他证书共享其友好名称，您应该没问题。

Since you're in an environment where presumably all the traffic goes through your DPI firewall, you'll probably only ever have to use one CA certificate at most. As long is it doesn't share its "friendly name" in the Windows list with any other cert, you should be fine.

这篇关于Debian SSL证书错误：无法验证xxx证书/ javax.net.ssl.SSLHandshakeException的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！