7

我有一些 Java 应用程序抱怨不同的 SSL 问题，例如自签名证书或不受信任的证书。

由于我没有这些应用程序的代码并且获得良好的证书太难了，我正在寻找一种可以让我强制连接的解决方案。

到目前为止，我尝试了这些，但似乎还不够：

-Dcom.sun.net.ssl.checkRevocation=false 
-Djava.security.debug=certpath

我仍然看到：

  • sun.security.validator.ValidatorException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target
  • 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
4

3 回答 3

7

通过完全忽略信任验证（例如，使用什么都不做的信任管理器）来忽略证书验证错误的代码修改通常不是正确的方法。它们可能会受到一些开发人员的欢迎，因为他们不必经过任何处理证书的步骤，但他们只是忽略了问题而不是修复它，从而也给 MITM 攻击带来了漏洞。（因为问题随后被消除了，所以它往往永远不会在生产版本中得到修复。）

JSSE 参考指南中描述了配置信任管理的各种方法。

简而言之，您可以将证书显式导入 JRE 信任库（通常cacerts是 JRE 目录中的文件），也可以将其导入您自己的信任库（可能基于默认信任库的副本），并使用指定其路径（和相关的javax.net.ssl.trustStore）系统属性（参见 JSSE 参考指南）。

这些配置设置会影响所有自己使用默认设置的SSLSockets和SSLEngines（代码中没有具体说明SSLContext）。

一些应用程序使用自己的SSLContext为某些连接加载特定的密钥库或信任库。这通常使用独立于 JSSE 默认选项的参数进行配置，在这种情况下，您必须检查应用程序文档或代码。

于 2012-10-23T12:45:26.803 回答
6

http://code.google.com/p/misc-utils/wiki/JavaHttpsUrl提供了几种侵入式解决方案。

SSLSocketFactory 可以被系统属性覆盖。

但是自定义 HostnameVerifier只能通过特殊的 java 代理通过附加的启动参数或在运行中得到认可。

此外，AspectJ 编织代理可用于覆盖任何方法行为。

还可以考虑使用MiTM HTTPS 代理的替代方法（如果应用程序允许重新配置 url 和证书）。

于 2012-10-23T14:48:36.490 回答
-2

对的，这是可能的。

使用 JVM 参数：

-Dcom.sun.net.ssl.checkRevocation=false

或以编程方式：

您可以覆盖默认的 TrustManager 和 HostnameVerifier 。这个链接给出了可重用的代码示例。

于 2019-03-01T16:53:12.320 回答