title: How to make Apache Commons HttpClient 3.1 ignore HTTPS certificate invalidity?
body: <p>I am trying to get the Apache Commons HttpClient library (version 3.1) to ignore the fact that the server certificate cannot be established as trusted (as evidenced by the thrown exception <code>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</code>).</p>
  
  <p>I did find <a href="https://stackoverflow.com/questions/2703161/how-to-ignore-ssl-certificate-errors-in-apache-httpclient-4-0/2703233#2703233">Make a connection to a HTTPS server from Java and ignore the validity of the security certificate</a> as well as <a href="http://www.nakov.com/blog/2009/07/16/disable-certificate-validation-in-java-ssl-connections/" rel="nofollow noreferrer">Disable Certificate Validation in Java SSL Connections</a>, but the accepted answer to the first is for HttpClient 4.0 (unfortunately I cannot upgrade, <em>unless</em> someone can point me in the direction of how to use two different versions of that same library within the same project), although it does have <a href="https://stackoverflow.com/questions/2703161/how-to-ignore-ssl-certificate-errors-in-apache-httpclient-4-0/2703188#2703188">another answer with little more than a dead link that supposedly went to a 3.x solution</a>. The code at the second page seems to have no effect at all when I use a slightly adjusted version of it (basically, declaring the classes in the old fashion rather than using anonymous ones inline, as well as applying to <code>TLS</code> in addition to <code>SSL</code>, using <code>SSL</code> for the default HTTPS socket factory as done in the example code).</p>
  
  <p>Preferably, I'd like something that is thread-/instance-wide, so that any <code>HttpClient</code> instance (and/or related classes) being created <em>from within my servlet code</em> (<em>not</em> another servlet running in the same container) will use the lax certificate validation logic, but at this point I am starting to feel like anything will do as long as it accepts the self-signed certificate as valid.</p>
  
  <p>Yes, I am aware that there are security implications, but the only reason why I need this at all is for testing purposes. The idea is to implement a configuration option that controls whether normally untrusted certificates are trusted or not, and leave it in "don't trust non-trustworthy server certificates" as default. That way it can easily be turned on or off in development, but doing it in production will require going out of one's way.</p>