Uploaded image for project: 'Jenkins'
  1. Jenkins
  2. JENKINS-57191

Certificate Problem only with jira-step.plugin

    Details

    • Type: Improvement
    • Status: Open (View Workflow)
    • Priority: Minor
    • Resolution: Unresolved
    • Component/s: jira-steps-plugin
    • Labels:
      None
    • Environment:
      RHEL-3.10.0-957.el7.x86_64, JRE 1.8.0_161-b12, jira-PlugIn 3.0.6, jira-steps-plugin 1.4.5, Jenkins 2.174, Jira 7.9.2
    • Similar Issues:

      Description

      Hi Naresh,

      i've tried several hours to get start with the jire-step plugin and the internal it infrastructure of my company. It has a self-signed root certificate and the Jira server has an normal one signed with it as shown as follows:

      .      |–LEVEL 2–Jenkins

      ROOT - |

      .      |–LEVEL 2--Jira

      First i've had the "unable to find valid certification path" - error for all Jira plugins. After importing the server certificate and their root certificates into the keystore and referenced them in /etc/sysconfig/jenkins this error disappeared.

      For now the jira-step plugin has another error: "hostname <domain> not validated". The other Jira Plugin can connect to Jira and i could write comments into several tickets.

      I've also imported the certificates into the /etc/ssl/ca-bundle.crt store and openssl can connect successfully with the server. I downloaded the certificate directly via openssl from the Jira server and include it again into the keystore.

      I see that the jira ssl-certificate has not a defined subject alternative name (SAN) field. Maybe this is the problem here.

      If so, it would be very helpful to introduce an option for disabling or lower ssl checks at least for testing purposal.

      I want really use Jira-Step to trigger time-based my jobs. A webhook would be an option, but is not allowed by it security at the moment. This is another story

      Thanks for any help.

      Greetings

      Lars

       

      with -Djavax.net.debug=ssl

      i see that the tls handshake has been done, but then the session is terminated:

      trigger seeding of SecureRandom
      done seeding SecureRandom
      Allow unsafe renegotiation: false
      Allow legacy hello messages: true
      Is initial handshake: true
      Is secure renegotiation: false
      %% No cached client session
      *** ClientHello, TLSv1.2
      [...]
      *** ECDH ServerKeyExchange
      Signature Algorithm SHA512withRSA
      Server key: Sun EC public key, 256 bits
        public x coord: 
        public y coord: 
        parameters: secp256r1 [NIST P-256, X9.62 prime256v1] (1.2.840.10045.3.1.7)
      *** ServerHelloDone
      *** ECDHClientKeyExchange
      ECDH Public value:  
      Handling POST /descriptorByName/org.thoughtslive.jenkins.plugins.jira.Site/validateBasic from 10.270.58.12 : qtp992136656-386, WRITE: TLSv1.2 Handshake, length = 70
      SESSION KEYGEN:
      PreMaster Secret:
      CONNECTION KEYGEN:
      Client Nonce:
      Server Nonce:
      Master Secret:
      Client MAC write Secret:
      Server MAC write Secret:
      Client write key:
      Server write key:
      ... no IV derived for this protocol
      Handling POST /descriptorByName/org.thoughtslive.jenkins.plugins.jira.Site/validateBasic from 10.270.58.12 : qtp992136656-386, WRITE: TLSv1.2 Change Cipher Spec, length = 1
      *** Finished
      verify_data:   16, 138, 146, 230, 210, 212, 227, 185, 142, 41, 116, 130 
      ***
      Handling POST /descriptorByName/org.thoughtslive.jenkins.plugins.jira.Site/validateBasic from 10.270.58.12 : qtp992136656-386, WRITE: TLSv1.2 Handshake, length = 64
      Handling POST /descriptorByName/org.thoughtslive.jenkins.plugins.jira.Site/validateBasic from 10.270.58.12 : qtp992136656-386, READ: TLSv1.2 Change Cipher Spec, length = 1
      Handling POST /descriptorByName/org.thoughtslive.jenkins.plugins.jira.Site/validateBasic from 10.270.58.12 : qtp992136656-386, READ: TLSv1.2 Handshake, length = 64
      *** Finished
      verify_data:   233, 215, 106, 1, 227, 137, 121, 230, 229, 100, 135, 127 
      ***
      %% Cached client session: [Session-391, TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA]
      Handling POST /descriptorByName/org.thoughtslive.jenkins.plugins.jira.Site/validateBasic from 10.270.58.12 : qtp992136656-386, called close()
      Handling POST /descriptorByName/org.thoughtslive.jenkins.plugins.jira.Site/validateBasic from 10.270.58.12 : qtp992136656-386, called closeInternal(true)
      Handling POST /descriptorByName/org.thoughtslive.jenkins.plugins.jira.Site/validateBasic from 10.270.58.12 : qtp992136656-386, SEND TLSv1.2 ALERT:  warning, description = close_notify
      Handling POST /descriptorByName/org.thoughtslive.jenkins.plugins.jira.Site/validateBasic from 10.270.58.12 : qtp992136656-386, WRITE: TLSv1.2 Alert, length = 48
      Handling POST /descriptorByName/org.thoughtslive.jenkins.plugins.jira.Site/validateBasic from 10.270.58.12 : qtp992136656-386, called closeSocket(true)
      

        Attachments

          Activity

          Hide
          nrayapati Naresh Rayapati added a comment -

          Hope you are using the basic authentication for this verification? and while setting up the site, were you able to test the connection? is this error during the same phase?

          Looks like host name validation is failing on the JIRA server address, did you try providing the actual domain name instead of an IP address? 

          Some how this ssl certificate is setup to not to allow the Jenkins server IP.

          Show
          nrayapati Naresh Rayapati added a comment - Hope you are using the basic authentication for this verification? and while setting up the site, were you able to test the connection? is this error during the same phase? Looks like host name validation is failing on the JIRA server address, did you try providing the actual domain name instead of an IP address?  Some how this ssl certificate is setup to not to allow the Jenkins server IP.
          Hide
          nrayapati Naresh Rayapati added a comment -

          An option to ignore SSL certs is bad in my opinion and we should only use it in non-prod environments.

          Show
          nrayapati Naresh Rayapati added a comment - An option to ignore SSL certs is bad in my opinion and we should only use it in non-prod environments.
          Hide
          nrayapati Naresh Rayapati added a comment -

          Verified JIRA plugin code a bit, that plugin is bypassing the ssl verification and using deprecated host verifiers.

          https://github.com/jenkinsci/jira-plugin/blob/master/src/main/java/com/atlassian/httpclient/apache/httpcomponents/ApacheAsyncHttpClient.java#L298
          https://github.com/jenkinsci/jira-plugin/blob/master/src/main/java/com/atlassian/httpclient/apache/httpcomponents/ApacheAsyncHttpClient.java#L311-L340

          I would suggest to give it another try to fix the certificate, but we can try enable an option to disable ssl verification, which is something I strongly don't recommend.

          Show
          nrayapati Naresh Rayapati added a comment - Verified JIRA plugin code a bit, that plugin is bypassing the ssl verification and using deprecated host verifiers. https://github.com/jenkinsci/jira-plugin/blob/master/src/main/java/com/atlassian/httpclient/apache/httpcomponents/ApacheAsyncHttpClient.java#L298 https://github.com/jenkinsci/jira-plugin/blob/master/src/main/java/com/atlassian/httpclient/apache/httpcomponents/ApacheAsyncHttpClient.java#L311-L340 I would suggest to give it another try to fix the certificate, but we can try enable an option to disable ssl verification, which is something I strongly don't recommend.
          Hide
          larsefs Lars Biermanski added a comment -

          Yes, i use the basic authentication method and verified the connection to the target via the test button. But i also tried to use it in a pipeline script. Both ways did not work.
          I tried IP address and the domain name with the same result.
          I ask the responsible section of the jira administration to update the certificate, but i believe that will take a while.
          I would really appreciate an option to override some checks. I know, that this is not the best way.
          This override would be a deliberately decision by each user. Maybe a warning can be pop up to remind that this is a between solution.

          Show
          larsefs Lars Biermanski added a comment - Yes, i use the basic authentication method and verified the connection to the target via the test button. But i also tried to use it in a pipeline script. Both ways did not work. I tried IP address and the domain name with the same result. I ask the responsible section of the jira administration to update the certificate, but i believe that will take a while. I would really appreciate an option to override some checks. I know, that this is not the best way. This override would be a deliberately decision by each user. Maybe a warning can be pop up to remind that this is a between solution.
          Hide
          nrayapati Naresh Rayapati added a comment -

          Sounds good Lars Biermanski I am trying to get to this but unfortunately I didn't much time these days. Probably within next couple of weeks but not promising, but if you have some time pull request is welcome. Thank you for understanding.

          Show
          nrayapati Naresh Rayapati added a comment - Sounds good Lars Biermanski I am trying to get to this but unfortunately I didn't much time these days. Probably within next couple of weeks but not promising, but if you have some time pull request is welcome. Thank you for understanding.
          Hide
          t3knoid Frank Refol added a comment -

          Just FYI, I used the sslpoke.java test (as described here https://plugins.jenkins.io/jira/) to test with a personal certificate. If I simply connect using the command:

          java SSLPoke my.jira.server 443

           

          I get the following error:

          [java.net.SocketException: Connection reset by peer: socket write error
          at java.net.SocketOutputStream.socketWrite0(Native Method)
          at java.net.SocketOutputStream.socketWrite(SocketOutputStream.java:109)
          at java.net.SocketOutputStream.write(SocketOutputStream.java:153)
          at sun.security.ssl.OutputRecord.writeBuffer(OutputRecord.java:431)
          at sun.security.ssl.OutputRecord.write(OutputRecord.java:417)
          at sun.security.ssl.SSLSocketImpl.writeRecordInternal(SSLSocketImpl.java:876)
          at sun.security.ssl.SSLSocketImpl.writeRecord(SSLSocketImpl.java:847)
          at sun.security.ssl.SSLSocketImpl.writeRecord(SSLSocketImpl.java:717)
          at sun.security.ssl.Handshaker.sendChangeCipherSpec(Handshaker.java:1077)
          at sun.security.ssl.ClientHandshaker.sendChangeCipherAndFinish(ClientHandshaker.java:1222)
          at sun.security.ssl.ClientHandshaker.serverHelloDone(ClientHandshaker.java:1134)
          at sun.security.ssl.ClientHandshaker.processMessage(ClientHandshaker.java:348)
          at sun.security.ssl.Handshaker.processLoop(Handshaker.java:979)
          at sun.security.ssl.Handshaker.process_record(Handshaker.java:914)
          at sun.security.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:1062)
          at sun.security.ssl.SSLSocketImpl.performInitialHandshake(SSLSocketImpl.java:1375)
          at sun.security.ssl.SSLSocketImpl.writeRecord(SSLSocketImpl.java:747)
          at sun.security.ssl.AppOutputStream.write(AppOutputStream.java:123)
          at sun.security.ssl.AppOutputStream.write(AppOutputStream.java:138)
          at SSLPoke.main(SSLPoke.java:23)|https://plugins.jenkins.io/jira/]

          However, if I use the following command, specifying the personal cert on the command-line. 

          java -Djavax.net.ssl.keyStorePassword=cert_password -Djavax.net.ssl.keyStoreType=pkcs12 -Djavax.net.ssl.keyStore=client-cert.p12 SSLPoke my.jira.server 443

          I get a successful connection.

          I added these options to my Jenkins start up options but it doesn't help with the Jira plugin. It did help with the "Jenkins Integration for Jira" plugin (https://docs.marvelution.org/jji/cloud).

          How can inject these options so that the other Jira plugins can use the parameters?

           

          Show
          t3knoid Frank Refol added a comment - Just FYI, I used the sslpoke.java test (as described here https://plugins.jenkins.io/jira/ ) to test with a personal certificate. If I simply connect using the command: java SSLPoke my.jira.server 443   I get the following error: [java.net.SocketException: Connection reset by peer: socket write error at java.net.SocketOutputStream.socketWrite0(Native Method) at java.net.SocketOutputStream.socketWrite(SocketOutputStream.java:109) at java.net.SocketOutputStream.write(SocketOutputStream.java:153) at sun.security.ssl.OutputRecord.writeBuffer(OutputRecord.java:431) at sun.security.ssl.OutputRecord.write(OutputRecord.java:417) at sun.security.ssl.SSLSocketImpl.writeRecordInternal(SSLSocketImpl.java:876) at sun.security.ssl.SSLSocketImpl.writeRecord(SSLSocketImpl.java:847) at sun.security.ssl.SSLSocketImpl.writeRecord(SSLSocketImpl.java:717) at sun.security.ssl.Handshaker.sendChangeCipherSpec(Handshaker.java:1077) at sun.security.ssl.ClientHandshaker.sendChangeCipherAndFinish(ClientHandshaker.java:1222) at sun.security.ssl.ClientHandshaker.serverHelloDone(ClientHandshaker.java:1134) at sun.security.ssl.ClientHandshaker.processMessage(ClientHandshaker.java:348) at sun.security.ssl.Handshaker.processLoop(Handshaker.java:979) at sun.security.ssl.Handshaker.process_record(Handshaker.java:914) at sun.security.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:1062) at sun.security.ssl.SSLSocketImpl.performInitialHandshake(SSLSocketImpl.java:1375) at sun.security.ssl.SSLSocketImpl.writeRecord(SSLSocketImpl.java:747) at sun.security.ssl.AppOutputStream.write(AppOutputStream.java:123) at sun.security.ssl.AppOutputStream.write(AppOutputStream.java:138) at SSLPoke.main(SSLPoke.java:23)|https://plugins.jenkins.io/jira/] However, if I use the following command, specifying the personal cert on the command-line.  java -Djavax.net.ssl.keyStorePassword=cert_password -Djavax.net.ssl.keyStoreType=pkcs12 -Djavax.net.ssl.keyStore=client-cert.p12 SSLPoke my.jira.server 443 I get a successful connection. I added these options to my Jenkins start up options but it doesn't help with the Jira plugin. It did help with the "Jenkins Integration for Jira" plugin ( https://docs.marvelution.org/jji/cloud). How can inject these options so that the other Jira plugins can use the parameters?  

            People

            • Assignee:
              nrayapati Naresh Rayapati
              Reporter:
              larsefs Lars Biermanski
            • Votes:
              0 Vote for this issue
              Watchers:
              3 Start watching this issue

              Dates

              • Created:
                Updated: