Uploaded image for project: 'Bamboo'
  1. Bamboo
  2. BAM-15451

bamboo agent fails to build client certificate chain for https-connection

    XMLWordPrintable

    Details

    • Type: Bug
    • Status: Closed (View Workflow)
    • Priority: Medium
    • Resolution: Fixed
    • Affects Version/s: 5.7.1
    • Fix Version/s: 5.10.0
    • Component/s: Agents
    • Labels:
      None

      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.

        Attachments

          Issue Links

            Activity

              People

              Assignee:
              pbruski Przemek Bruski
              Reporter:
              olaf.trygve.berglihn Olaf Trygve Berglihn
              Votes:
              2 Vote for this issue
              Watchers:
              2 Start watching this issue

                Dates

                Created:
                Updated:
                Resolved: