SSL certificate verification error while authenticating into JIRA server

[ShankarAnush]

Hi Community,

While trying to authenticate into JIRA server using python library for interacting with JIRA via REST APIs, I get the following error:

WARNING:root:Got recoverable error from GET https://corporate.domain.com/rest/api/2/serverInfo, will retry [1/3] in 8.16608003441684s. Err: HTTPSConnectionPool(host='jerry.wincor-nixdorf.com', port=443): Max retries exceeded with url: /rest/api/2/serverInfo (Caused by SSLError(SSLCertVerificationError(1, '[SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed: unable to get local issuer certificate (_ssl.c:1108)')))
WARNING:root:HTTPSConnectionPool(host='corporate.domain.com', port=443): Max retries exceeded with url: /rest/api/2/serverInfo (Caused by SSLError(SSLCertVerificationError(1, '[SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed: unable to get local issuer certificate (_ssl.c:1108)'))) while doing GET https://corporate.domain.com/rest/api/2/serverInfo [{'params': None, 'headers': {'User-Agent': 'python-requests/2.24.0', 'Accept-Encoding': 'gzip, deflate', 'Accept': 'application/json,.;q=0.9', 'Connection': 'keep-alive', 'Cache-Control': 'no-cache', 'Content-Type': 'application/json', 'X-Atlassian-Token': 'no-check'}}]

OS: Windows 10;
python: 3.8.0
JIRA (Jira-python library package): 3.0.a2

Please also suggest whether the rest api endpoint used is correct!

PS: I sit behind a corporate network

Thanks in advance,
Anush

[dstarizny]

Have you tried doing options={"verify" : False} ?

e.g.

j = jira.JIRA("<server_url>" , options={"verify" : False } )

[ShankarAnush]

@dstarizny, yes, I did try that option but it didn't work for me as it seems that the certificate verification cannot be ignored in my case.

[iodbh]

running into this as well, options={"verify" : False} does not have the desired effect (although it is correctly propagated to JIRA._options and ResilientSession.verify )

[shanewa]

Looks like JIRA made some changes related the authentication:
Deprecation notice - Basic authentication with passwords and cookie-based authentication

[srinubalsu]

Thank you Shane. This is not available option on our Jira instance. I don't know what to do, our company is not using Cloud based JIRA. Please advise. Thanks and Regards, Srinu Balsu

…

On Tue, Nov 17, 2020 at 12:45 AM Shane Wang ***@***.***> wrote: Looks like JIRA made some changes related the authentication: Deprecation notice - Basic authentication with passwords and cookie-based authentication <https://developer.atlassian.com/cloud/jira/platform/deprecation-notice-basic-auth-and-cookie-based-auth/> — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#966 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AFKKI5A5G74FLEYSGFSKYATSQISY7ANCNFSM4QTEJSOQ> .

[jserafim]

Also running into this. As @iodbh has said above, options={"verify" : False} does not have the desired effect.

I had to manually change the code in site-packages/jira/resilientsession.py, inside def __verb(self, verb, url, retry_data=None, **kwargs):.

I replaced response = method(url, timeout=self.timeout, **kwargs) with response = method(url, timeout=self.timeout, verify=self.verify, **kwargs). Now verify has the expected behavior.

[corrantho]

options={"verify" : False} allows to disable the certificate checks but how to trust a certificate authority?

As per suggested in this issue #339, I was expecting to be able to pass the certificate bundle as a value of verify but it does not work.

I also tried to pass the certificate path via REQUESTS_CA_BUNDLE (this is what I usually do when using other python libraries) but with the jira library it does not work, we still get SSL: CERTIFICATE_VERIFY_FAILED.

[studioj]

@jserafim if you have a fix for it, please merge in last master changes (CI got fixed) and open a PR so this issue can be solved

[ffyuanda]

Still got this error AttributeError: 'SSLError' object has no attribute 'headers'

[adehad]

Don't suppose you can give this a try again with the latest RC or main?

[adehad]

@jserafim @corrantho , don't suppose you can try the branch for #1202, I think it may address the issue