我有一些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
代码修改，通过完全忽略信任验证（例如，使用任何无用的信任管理器）忽略证书验证错误通常不是正确的方法。他们可能在某些开发人员中很受欢迎，因为他们不必经过任何处理证书的步骤，但是他们只是忽略了问题而不是解决问题，从而引入了MITM攻击的漏洞。（因为问题然后沉默，所以它往往永远不会在生产释放中固定。）
JSSE参考指南中描述了配置信任管理的各种方法。
简而言之，您可以将证书明确导入到JRE TrustStore（通常是JRE目录中的cacerts文件），也可以使用将其导入到您自己的信任商店中（可能基于默认信任商店的副本），并且使用javax.net.ssl.trustStore（和相关）系统属性指定其路径（请参阅JSSE Ref Guide）。
这些配置设置将影响使用默认设置本身的所有SSLSocket S和SSLEngine S（代码中没有任何特定的SSLContext）。
某些应用程序使用自己的SSLContext来为某些连接加载特定的密钥库或信任库。通常，这是独立于JSSE默认选项的参数，在这种情况下，您必须检查应用程序文档或代码。
http://code.google.com/p/misc-utils/wiki/javahttpsurl提供多种入侵解决方案。
sslsocketFactory可以用系统属性覆盖。
但是自定义主机名只能通过其他启动参数或即时用特殊的Java代理认可。
此外，可以使用Factions J编织剂来覆盖任何方法行为。
还考虑使用MITM HTTPS代理的替代方法（如果应用程序允许重新配置URL和证书）。
是的。
使用JVM Args：
-Dcom.sun.net.ssl.checkRevocation=false
或程序上：
您可以覆盖默认的TrustManager和HostNameVerifier。此链接给出可重复使用的代码示例。