Medium Description
When requiring client SSL certificates on bamboo, the bamboo agents do not set the correct SSL context and are unable to find the required client certificate. Variables are set in the wrapper.conf. These work for the when activemq authenticates with client certificate, but not for the initial https:-connection of the agent.
This issue is a major blocker for securely authenticating build agents.
The wrapper.conf parameters are set like this:
wrapper.java.additional.2=-
Djavax.net.ssl.keyStore="C:\Users\oberg\client.ks"
wrapper.java.additional.3=-Djavax.net.ssl.keyStorePassword=secret
wrapper.java.additional.4=-Djavax.net.debug=ssl
wrapper.java.additional.5=-Djavax.net.ssl.trustStore="C:\Users\oberg\trust.ks"
wrapper.java.additional.6=-Djavax.net.ssl.trustStorePassword=secret
This works fine for the truststore:
INFO | jvm 1 | 2015/01/15 23:19:35 | trustStore is: C:\Users\oberg\trust.ks
INFO | jvm 1 | 2015/01/15 23:19:35 | trustStore type is : jks
But it fails to read/use the proper client certificates from the keystore, ending in a empty client certificate chain, and thus SSL connection failure:
INFO | jvm 2 | 2015/01/15 23:19:40 | *** CertificateRequest
INFO | jvm 2 | 2015/01/15 23:19:40 | Cert Types: RSA, DSS, ECDSA
INFO | jvm 2 | 2015/01/15 23:19:40 | Cert Authorities:
INFO | jvm 2 | 2015/01/15 23:19:40 | <EMAILADDRESS=olaf.trygve.berglihn@sintef.no, CN=code.sintef.no CA, O=SINTEF>
INFO | jvm 2 | 2015/01/15 23:19:40 | <CN=Sintef Group PKI, DC=sintef, DC=no>
INFO | jvm 2 | 2015/01/15 23:19:40 | <EMAILADDRESS=olaf.trygve.berglihn@sintef.no, CN=Olaf Trygve Berglihn, O=SINTEF, C=no>
INFO | jvm 2 | 2015/01/15 23:19:40 | *** ServerHelloDone
INFO | jvm 2 | 2015/01/15 23:19:40 | *** Certificate chain
INFO | jvm 2 | 2015/01/15 23:19:40 | ***
INFO | jvm 2 | 2015/01/15 23:19:40 | *** ECDHClientKeyExchange
...
INFO | jvm 2 | 2015/01/15 23:19:40 | verify_data:
{ 181, 187, 117, 80, 242, 91, 237, 83, 223, 19, 148, 95 }INFO | jvm 2 | 2015/01/15 23:19:40 | ***
INFO | jvm 2 | 2015/01/15 23:19:40 | WrapperSimpleAppMain, WRITE: TLSv1 Handshake, length = 48
INFO | jvm 2 | 2015/01/15 23:19:40 | WrapperSimpleAppMain, waiting for close_notify or alert: state 1
INFO | jvm 2 | 2015/01/15 23:19:40 | WrapperSimpleAppMain, Exception while waiting for close java.net.SocketException: Software caused connection abort: recv failed
INFO | jvm 2 | 2015/01/15 23:19:40 | WrapperSimpleAppMain, handling exception: java.net.SocketException: Software caused connection abort: recv failed
INFO | jvm 2 | 2015/01/15 23:19:40 | %% Invalidated: [Session-1, TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA]
INFO | jvm 2 | 2015/01/15 23:19:40 | WrapperSimpleAppMain, IOException in getSession(): java.net.SocketException: Software caused connection abort: recv failed
When testing with a simple java https-client using the same keystore and truststore, by setting the exact javax-parameters on commmand line, the https-connection succeeds.
This indicates that there is a bug related to the way the build agent selects the keystore, or ignores some of the default javax.-parameters.
