Document how to specify a truststore

[ind1go]

The current doc has an all-or-nothing approach to dealing with self-signed or internally-signed certificates - trust everything or add the certificate to your JVM's cacerts.

However, a nice flexible, and secure alternative is to use system properties to specify a specific truststore, without altering the JVM's supplied cacerts.

[ind1go]

See HttpClientBuilder for the system properties that are used.

[vera-chan]

Hi @ind1go , sorry just saw this. Shall we pick it up now? BTW, the link you shared (https://hc.apache.org/httpcomponents-client-ga/httpclient/apidocs/org/apache/http/impl/client/HttpClientBuilder.html).

I did find this: https://hc.apache.org/httpcomponents-client-4.5.x/current/httpclient/apidocs/org/apache/http/impl/client/HttpClientBuilder.html
would that do?

[ind1go]

Just need to verify that it works, first!

[ind1go]

My findings are these:

The use of the system properties is effective (for example, at a minimum you can use javax.net.ssl.trustStore to specifying the location of a trust store and as long as it matches the default type for that Java version (8 and below: JKS; 9 and above: PKCS) it'll read the certificate(s) out of the trust store and use them for the deployment.

However, it's not all good news. Because this is all part of the Gradle build, the system properties affect all of that process. So say you create a trust store using just the single self-signed certificate you need to get deployment working, you will find that things like the downloading of Gradle plugins (like this plugin itself) and project dependencies will not work. So instead you need to create a trust store that trusts all of those sources as well as your self-signed certificate. The easiest way to do that is probably to copy the JRE's built-in cacerts file and add your self-signed certificate to it.

I think that instead of documenting this method, we may be better creating a mechanism to supply trust store and key store configuration to the plugin directly - and possibly, waiting for a user requirement to do so first.