Hi,
after digging a lot through the source code of Crowd, Jenkins and Winstone, the servlet container used by Jenkins, it seems to me that it isn't actually possible:
As far as I can tell, Winstone uses its own mechanism to read and extract the certificates contained in your keystore; see src/java/winstone/ssl/HttpsListener#getSSLContext() in the Winstone source code. The keystore file to use and its password must be specified on the command line with the additional Winstone-specific parameters --httpsKeyStore and --httpsKeyStorePassword.
The Crowd REST API on the other hand uses Apache Jakarta HttpClient for the communication with your Crowd server. So far I haven't found whether it's possible at all to extract / receive the startup parameters given to Jenkins.
Apart from that it's not possible to (re-)configure the HttpClient components used internally in the REST client and inform them there's a certain keystore and password to use - the corresponding variables / objects are private and not accessible from outside of the REST client. Therefore you'd have to specify the necessary system properties by setting them in the JVM command line as you already found out.
But...:
According to the JSSE Reference Guide ([1], [2]) you can perhaps make life a bit easier by putting your keystore into the file <java-home>/lib/security/jssecacerts that is used when the system property javax.net.ssl.trustStore isn't specified; see in the guide under "Key Classes -> Support Classes and Interfaces -> X509TrustManager Interface".
The section "Customization -> How to Specify a java.security.Security Property" also mentions that you can add (additional) security properties to the file <java-home>/lib/security/java.security. I haven't tried it and therefore can't tell whether that works, but if yes, add the property with your keystore password to that file (javax.net.ssl.trustStorePassword=<mypassword>), and in combination with the jssecacerts file you eventually can get rid of the additional command line parameters.
[1] http://docs.oracle.com/javase/6/docs/technotes/guides/security/jsse/JSSERefGuide.html
[2] http://docs.oracle.com/javase/7/docs/technotes/guides/security/jsse/JSSERefGuide.html
Bug
Minor
Hi,
after digging a lot through the source code of Crowd, Jenkins and Winstone, the servlet container used by Jenkins, it seems to me that it isn't actually possible:
As far as I can tell, Winstone uses its own mechanism to read and extract the certificates contained in your keystore; see src/java/winstone/ssl/HttpsListener#getSSLContext() in the Winstone source code. The keystore file to use and its password must be specified on the command line with the additional Winstone-specific parameters --httpsKeyStore and --httpsKeyStorePassword.
The Crowd REST API on the other hand uses Apache Jakarta HttpClient for the communication with your Crowd server. So far I haven't found whether it's possible at all to extract / receive the startup parameters given to Jenkins.
Apart from that it's not possible to (re-)configure the HttpClient components used internally in the REST client and inform them there's a certain keystore and password to use - the corresponding variables / objects are private and not accessible from outside of the REST client. Therefore you'd have to specify the necessary system properties by setting them in the JVM command line as you already found out.
But...:
According to the JSSE Reference Guide ([1], [2]) you can perhaps make life a bit easier by putting your keystore into the file <java-home>/lib/security/jssecacerts that is used when the system property javax.net.ssl.trustStore isn't specified; see in the guide under "Key Classes -> Support Classes and Interfaces -> X509TrustManager Interface".
The section "Customization -> How to Specify a java.security.Security Property" also mentions that you can add (additional) security properties to the file <java-home>/lib/security/java.security. I haven't tried it and therefore can't tell whether that works, but if yes, add the property with your keystore password to that file (javax.net.ssl.trustStorePassword=<mypassword>), and in combination with the jssecacerts file you eventually can get rid of the additional command line parameters.
[1] http://docs.oracle.com/javase/6/docs/technotes/guides/security/jsse/JSSERefGuide.html
[2] http://docs.oracle.com/javase/7/docs/technotes/guides/security/jsse/JSSERefGuide.html