[JIRA] (JENKINS-57191) Certificate Problem only with jira-step.plugin

10 views
Skip to first unread message

lars.biermanski@efs-auto.com (JIRA)

unread,
Apr 26, 2019, 2:06:02 AM4/26/19
to jenkinsc...@googlegroups.com
Lars Biermanski created an issue
 
Jenkins / Improvement JENKINS-57191
Certificate Problem only with jira-step.plugin
Issue Type: Improvement Improvement
Assignee: Naresh Rayapati
Components: jira-steps-plugin
Created: 2019-04-26 06:05
Environment: RHEL-7, JRE 1.8.161
Labels: jira-steps-plugin-1.5.0
Priority: Minor Minor
Reporter: Lars Biermanski

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--JenkinsROOT - |

       |–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. The difference between jira-step and openssl is, that jira-step identifies a sha256-fingerprint and openssl a sha512-fingerprint of the Jira server-certificate. I don't know actually, if this is important or not.

I've tried to override the ssl-check in Jenkins for testing purposal without success.

  • Is there any option to override these ssl check in the Jira Step Plugin?
  • Does the alias-name in the keystore has any impact to the check?
  • Do you know the difference between Jira PlugIn and Jira Step PlugIn for this handshake?
  • Any other ideas ?

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
Add Comment Add Comment
 
This message was sent by Atlassian Jira (v7.11.2#711002-sha1:fdc329d)

lars.biermanski@efs-auto.com (JIRA)

unread,
Apr 26, 2019, 2:07:02 AM4/26/19
to jenkinsc...@googlegroups.com
Lars Biermanski updated an issue
Change By: Lars Biermanski
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. The difference between jira-step and openssl is, that jira-step identifies a sha256-fingerprint and openssl a sha512-fingerprint of the Jira server-certificate. I don't know actually, if this is important or not.

I've tried to override the ssl-check in Jenkins for testing purposal without success.
* Is there any option to override these ssl check in the Jira Step Plugin?
* Does the alias-name in the keystore has any impact to the check?
* Do you know the difference between Jira PlugIn and Jira Step PlugIn for this handshake?
* Any other ideas :) ?

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

lars.biermanski@efs-auto.com (JIRA)

unread,
Apr 26, 2019, 3:19:02 AM4/26/19
to jenkinsc...@googlegroups.com
Lars Biermanski updated an issue
Change By: Lars Biermanski
Environment: RHEL- 7 3.10.0-957.el7.x86_64 , JRE 1.8. 161 0_161-b12, jira 3.0.6, Jenkins 2.174, Jira 7.9.2

lars.biermanski@efs-auto.com (JIRA)

unread,
Apr 26, 2019, 3:20:02 AM4/26/19
to jenkinsc...@googlegroups.com
Lars Biermanski updated an issue
Change By: Lars Biermanski
Environment: RHEL-3.10.0-957.el7.x86_64, JRE 1.8.0_161-b12, jira -PlugIn 3.0.6, Jenkins 2.174, Jira 7.9.2

lars.biermanski@efs-auto.com (JIRA)

unread,
Apr 26, 2019, 3:23:04 AM4/26/19
to jenkinsc...@googlegroups.com
Lars Biermanski updated an issue
Change By: Lars Biermanski
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

lars.biermanski@efs-auto.com (JIRA)

unread,
Apr 26, 2019, 3:23:04 AM4/26/19
to jenkinsc...@googlegroups.com
Lars Biermanski updated an issue
Change By: Lars Biermanski
Labels: jira-steps-plugin-1.5.0

lars.biermanski@efs-auto.com (JIRA)

unread,
Apr 26, 2019, 4:12:02 AM4/26/19
to jenkinsc...@googlegroups.com
Lars Biermanski updated an issue
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. The difference between jira-step and openssl is, that jira-step identifies a sha256-fingerprint and openssl a sha512-fingerprint of the Jira server-certificate. I don't know actually, if this is important or not.

I've tried to override the ssl-check in Jenkins for testing purposal without success.
* Is there any option to override these ssl check in the Jira Step Plugin?
* Does the alias-name in the keystore has any impact to the check?
* Do you know the difference between Jira PlugIn and Jira Step PlugIn for this handshake?
* Any other ideas :) ?

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:

{{*** ECDH ServerKeyExchange}}
{{Signature Algorithm SHA512withRSA}}
{{Server key: Sun EC public key, 256 bits}}
{{ public x coord: 70740116869517588213975664618149948659341834048202049830062079093998150980286}}
{{ public y coord: 1325778832149671231123951384103491129335134556388339515957861660603788281836}}
{{ parameters: secp256r1 [NIST P-256, X9.62 prime256v1] (1.2.840.10045.3.1.7)}}
{{*** ServerHelloDone}}
{{*** ECDHClientKeyExchange}}
{{ECDH Public value: \{ 4, 211, 235, 142, 108, 61, 67, 183, 226, 137, 134, 3, 3, 110, 82, 33, 18, 72, 134, 191, 199, 62, 67, 97, 18, 104, 253, 254, 187, 139, 103, 253, 159, 15, 163, 43, 241, 94, 211, 14, 218, 137, 90, 19, 226, 67, 19, 30, 115, 124, 138, 159, 72, 223, 192, 139, 116, 26, 38, 74, 134, 64, 136, 92, 151 }}}
{{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)}}

lars.biermanski@efs-auto.com (JIRA)

unread,
Apr 26, 2019, 4:13:02 AM4/26/19
to jenkinsc...@googlegroups.com

lars.biermanski@efs-auto.com (JIRA)

unread,
Apr 26, 2019, 4:17:02 AM4/26/19
to jenkinsc...@googlegroups.com
Lars Biermanski updated an issue
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. The difference between jira-step and openssl is, that jira-step identifies a sha256-fingerprint and openssl a sha512-fingerprint of the Jira server-certificate. I don't know actually, if this is important or not.

I've tried to override the ssl-check in Jenkins for testing purposal without success.
* Is there any option to override these ssl check in the Jira Step Plugin?
* Does the alias-name in the keystore has any impact to the check?
* Do you know the difference between Jira PlugIn and Jira Step PlugIn for this handshake?
* Any other ideas :) ?

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}}
 {{ *** ECDH ServerKeyExchange done seeding SecureRandom }}
{{Allow unsafe renegotiation: false }}
{{ Allow legacy hello messages: true}}
 {{ Signature Algorithm SHA512withRSA 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, * 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)}} }}

lars.biermanski@efs-auto.com (JIRA)

unread,
Apr 26, 2019, 4:18:04 AM4/26/19
to jenkinsc...@googlegroups.com
{ { code:java}
 trigger seeding of SecureRandom }}
{{ done seeding SecureRandom }}
{{ Allow unsafe renegotiation: false }}
{{ Allow legacy hello messages: true }}
{{ Is initial handshake: true }}
*** 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)

{code } }

lars.biermanski@efs-auto.com (JIRA)

unread,
Apr 26, 2019, 6:35:02 PM4/26/19
to jenkinsc...@googlegroups.com
Lars Biermanski updated an issue
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. The difference between jira-step and openssl is,


I see that the jira ssl - step identifies a sha256-fingerprint and openssl a sha512-fingerprint of the Jira server- certificate has not a defined subject alternative name (SAN) field . I don't know actually, if Maybe this is important or not the problem here .

 I've tried If so, it would be very helpful to override the introduce an option for disabling or lower ssl -check in Jenkins checks at least for testing purposal without success .
%% 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)
{code}

naresh.rayapati@gmail.com (JIRA)

unread,
Apr 28, 2019, 4:50:02 AM4/28/19
to jenkinsc...@googlegroups.com
Naresh Rayapati commented on Improvement JENKINS-57191
 
Re: Certificate Problem only with jira-step.plugin

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.

naresh.rayapati@gmail.com (JIRA)

unread,
Apr 28, 2019, 5:03:03 AM4/28/19
to jenkinsc...@googlegroups.com

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

naresh.rayapati@gmail.com (JIRA)

unread,
Apr 28, 2019, 5:32:02 AM4/28/19
to jenkinsc...@googlegroups.com

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.

lars.biermanski@efs-auto.com (JIRA)

unread,
May 1, 2019, 6:10:02 PM5/1/19
to jenkinsc...@googlegroups.com

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.

naresh.rayapati@gmail.com (JIRA)

unread,
May 30, 2019, 8:05:02 PM5/30/19
to jenkinsc...@googlegroups.com

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.

naresh.rayapati@gmail.com (JIRA)

unread,
Jan 28, 2020, 10:46:02 PM1/28/20
to jenkinsc...@googlegroups.com
Naresh Rayapati closed an issue as Duplicate
 

Thank you for logging this, is a duplicate of JENKINS-57191
Change By: Naresh Rayapati
Status: Open Closed
Resolution: Duplicate
This message was sent by Atlassian Jira (v7.13.6#713006-sha1:cc4451f)
Atlassian logo

naresh.rayapati@gmail.com (JIRA)

unread,
Jan 28, 2020, 10:47:02 PM1/28/20
to jenkinsc...@googlegroups.com
Naresh Rayapati reopened an issue
Change By: Naresh Rayapati
Resolution: Duplicate
Status: Closed Reopened

naresh.rayapati@gmail.com (JIRA)

unread,
Jan 28, 2020, 10:47:03 PM1/28/20
to jenkinsc...@googlegroups.com
Change By: Naresh Rayapati
Status: Reopened Open

naresh.rayapati@gmail.com (JIRA)

unread,
Jan 28, 2020, 10:47:03 PM1/28/20
to jenkinsc...@googlegroups.com
Naresh Rayapati updated an issue
Change By: Naresh Rayapati
Comment:
Thank you for logging this, is a duplicate of JENKINS-57191
Reply all
Reply to author
Forward
0 new messages