是否可以说服 Java 应用程序在不修改其代码的情况下忽略 SSL 问题？
声明：本页面是StackOverFlow热门问题的中英对照翻译，遵循CC BY-SA 4.0协议，如果您需要使用它，必须同样遵循CC BY-SA许可，注明原文地址和作者信息，同时你必须将它归于原作者（不是我）：StackOverFlow
原文地址: http://stackoverflow.com/questions/13030174/
Warning: these are provided under cc-by-sa 4.0 license. You are free to use/share it, But you must attribute it to the original authors (not me):
StackOverFlow
Is it possible to convince a Java application to ignore SSL issues without modifying its code?
提问by sorin
I have some java apps that are complaining about different SSL problems like self signed certificate or not trusted ones.
我有一些 Java 应用程序抱怨不同的 SSL 问题，例如自签名证书或不受信任的证书。
As I do not have the code of these apps and getting good certificates is too hard, I am looking for a solution that would allow me to force it to connect.
由于我没有这些应用程序的代码并且获得好的证书太难了，我正在寻找一种解决方案，可以让我强制它进行连接。
So far I tried these but it seems not to be enough:
到目前为止，我尝试了这些，但似乎还不够：
-Dcom.sun.net.ssl.checkRevocation=false
-Djava.security.debug=certpath
I still see:
我仍然看到：
sun.security.validator.ValidatorException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested targetjavax.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
sun.security.validator.ValidatorException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested targetjavax.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
回答by Bruno
Code modifications to ignore certificate validation errors by ignoring trust verification altogether (e.g. using a trust manager that does nothing) are normally not the right way to go. They may be popular with some developers, because they don't have to go through any steps about dealing with certificates, but they're just ignoring the problem instead of fixing it, thereby also introducing vulnerabilities to MITM attacks. (Because the problem is then silenced, it tends never to be fixed in production releases.)
通过完全忽略信任验证（例如使用不执行任何操作的信任管理器）来忽略证书验证错误的代码修改通常不是正确的方法。它们可能会受到一些开发人员的欢迎，因为它们不需要经过任何处理证书的步骤，但它们只是忽略了问题而不是修复它，从而也引入了 MITM 攻击的漏洞。（因为问题随后被消除了，所以它往往永远不会在生产版本中得到修复。）
The various ways to configure trust management are described in the JSSE Reference Guide.
JSSE 参考指南中描述了配置信任管理的各种方法。
In short, you can either import the certificates explicitly into the JRE truststore (usually cacertsfile in the JRE directory) or by using importing it into your own trust store (possibly based on a copy of the default trust store), and specifying its path using the javax.net.ssl.trustStore(and related) system properties (see JSSE Ref Guide).
简而言之，您可以将证书显式导入 JRE 信任库（通常cacerts是 JRE 目录中的文件），也可以使用将其导入您自己的信任库（可能基于默认信任库的副本），并使用指定其路径的javax.net.ssl.trustStore（以及相关的）系统属性（见参考文献JSSE指南）。
These configuration settings will affect all the SSLSockets and SSLEngines that use the default settings themselves (without any specific SSLContextin the code).
这些配置设置会影响所有使用默认设置的SSLSockets和SSLEngines本身（SSLContext代码中没有任何具体说明）。
Some applications use their own SSLContextto load a specific keystore or truststore for certain connections. This is usually configured with parameters that are independent of the JSSE default options, in which case you'll have to check the application documentation or code.
某些应用程序使用它们自己的SSLContext来加载特定连接的特定密钥库或信任库。这通常使用独立于 JSSE 默认选项的参数进行配置，在这种情况下，您必须检查应用程序文档或代码。
回答by Vadzim
http://code.google.com/p/misc-utils/wiki/JavaHttpsUrlprovides several invasive solutions.
http://code.google.com/p/misc-utils/wiki/JavaHttpsUrl提供了多种侵入性解决方案。
SSLSocketFactory can be overridden with system property.
SSLSocketFactory 可以被系统属性覆盖。
But custom HostnameVerifiercan be endorsed only with special java agent via additional startup parameter or on the fly.
但是，自定义的HostnameVerifier只能通过附加的启动参数特殊的Java代理或背书上飞。
Furthermore, AspectJ weaving agentcan be used to override any method behavior.
此外，AspectJ 编织代理可用于覆盖任何方法行为。
Also consider alternative approach with MiTM HTTPS proxy(if application allows reconfiguring urls and certificates).
还可以考虑使用MiTM HTTPS 代理的替代方法（如果应用程序允许重新配置 url 和证书）。
回答by Mehdi
Yes it is possible.
对的，这是可能的。
Using JVM args :
使用 JVM 参数：
-Dcom.sun.net.ssl.checkRevocation=false
Or programarically:
或以编程方式：
You can override the default TrustManager and HostnameVerifier . This link give reusable code example.
您可以覆盖默认的 TrustManager 和 HostnameVerifier 。这个链接给出了可重用的代码示例。
