com.sun.jersey.api.client.ClientHandlerException : handshake_failure

[Sourav Hazra]

I was using : 

sun.jersey.api.client

To Create/Edit/Fetch issue in JIRA to manage all the tickets from my organization's server. It was utilizing POST/GET/PUT calls through Rest API in order to manage the data.

Everything was working flawlessly until 10th July 2019. Then suddenly and error was displayed every time any API calls were made including POST/GET/PUT. No changes to the code was made at this point of time. 

I tried to generate a new API token for the user, but the error remained the same. I even changed the user with a new API token, the problem remained the same.

Is this due to the new update rolled out by JIRA software? Is there any other kind of work around to this issue?

The error description are as follows:

com.sun.jersey.api.client.ClientHandlerException: javax.net.ssl.SSLHandshakeException: Received fatal alert: handshake_failure

[Andy Heinzer · Accepted solution]

Hi Sourav,

Sorry to hear about this problem.  I have to admit, I am not very familiar with the sun.jersey.api.client.  However I take it that you are using Jira Cloud, you have created an API token, and have been using that token to authenticate in order to make REST calls to Jira.

I am curious to learn more about how exactly your REST client is handling the authentication here.  Last month Atlassian completely deprecated the use of passwords/cookies in basic auth for REST.  More details in Deprecation notice - Basic authentication with passwords and cookie-based authentication.

I realize you were using an API Token here, but I have seen some users in the past use this token in the exact same manner as a password (sent in plaintext).  In the past this could actually work for authentication.  But with the deprecation, your API token has to first be made into a string consisting of

user@example.com:API_TOKEN

and then base64 encode that string as per Basic auth for REST APIs From that document:

Supplying basic auth headers

If you need to, you may construct and send basic auth headers yourself. To do this you need to perform the following steps:

1. Generate an API token for Jira using your Atlassian Account: https://id.atlassian.com/manage/api-tokens.
2. Build a string of the form useremail:api_token.
3. BASE64 encode the string.
4. Supply an Authorization header with content Basic followed by the encoded string. For example, the string fred:fred encodes to ZnJlZDpmcmVk in base64, so you would make the request as follows:

curl -D- \

-X GET \

-H "Authorization: Basic ZnJlZDpmcmVk" \

-H "Content-Type: application/json" \

"https://your-domain.atlassian.net/rest/api/2/issue/QA-31"

In this example, the auth is include in an 'Authorization: Basic {encodedstring}' header, instead of sending the username:passwordORtoken string.

Please let me know the results, I hope this helps.

Andy

[Sourav Hazra]

Thank you for your response.

We have intercepted the issue. It was due to the deprecation of TLSv1.1. We have switched our existing framework to TLSv1.2. Now, the API calls are running fine.

The issue was indeed 'Authorization' related. 

[Andy Heinzer]

Thanks for posting back with your solution @Sourav Hazra !   I forgot that too was deprecated as well recently.  There is another post that relates to this in https://community.atlassian.com/t5/Jira-questions/Re-Was-TLS-1-0-still-being-supported-by-JIRA-Cloud-after/qaq-p/1130289/comment-id/359868#M359868

The plan was to deprecate TLS 1.0/1.1 per Deprecating TLSv1 and TLSv1.1 for Atlassian Cloud Products

While the planned effective date in that page was December 1, 2018, you can see in the recent Jira Cloud blog updates in https://confluence.atlassian.com/cloud/blog/2019/07/atlassian-cloud-changes-jul-1-to-jul-8-2019

... after consultation internally and with customers, we have allowed a silent/soft grace period of 6 months to allow customers additional time to update the necessary tools and systems. This grace period has now expired. 

I hope this helps to clarify the confusion.

Andy