nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Getting error - The request was aborted: Could not create SSL/TLS secure channel

Gajendra Paliwal

Hello,

We are getting error "The request was aborted: Could not create SSL/TLS secure channel" when we call "CreateRestClient" method to connect and fetch data from atlassian jira.

Below are the log snapshot which we are getting-:

"Message : The request was aborted: Could not create SSL/TLS secure channel.
Source : Atlassian.Jira
Stack Trace : at Atlassian.Jira.Remote.JiraRestClient.GetCustomFields(String token)"

Please do the needful.

Regards,

Gajendra

Accepted answers

Huan Ting Chen

Official response:

As part of our continuous efforts to better secure Atlassian Cloud products and your data, we are following the advice of Security leaders and researchers as well as joining many other SaaS vendors (including Apple, Amazon, Microsoft, Github, Google, Mozilla, and more) to deprecate support for TLS 1.0 and TLS 1.1. This is a necessary step to keep your data safe.

For more information on compliance, regulatory and industry requirements around TLS 1.0 and 1.1 deprecation see these blogs:
https://www.thesslstore.com/blog/apple-microsoft-google-disable-tls-1-0-tls-1-1/
https://www.thesslstore.com/blog/ssl3-poodle-vulnerability/
https://www.thesslstore.com/blog/june-30-to-disable-tls-1-0/

We announced the change last year in July 2018, in a campaign that included direct emails to all administrators, blog posts and social media posts on Twitter, Linkedin and Facebook. At that time other Atlassian products like Bitbucket and Statuspage already supported only TLS 1.2 and 1.3.

That announcement stated the deprecation of TLS 1.0 and 1.1 for Jira and Confluence would take place in December 2018 but, 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. Today we observe less than 0.3% of requests using TLS 1.0 and 1.1.

Atlassian has now deprecated TLS 1.0 and 1.1 and will support only TLS 1.2 and 1.3 going forward.

The good news here is that not only do we close some known security vulnerabilities, but TLS 1.3 will bring improved connection times!

You can refer to the following blog post for more information regarding the change: Deprecating TLSv1 and TLSv1.1 for Atlassian Cloud Products

Please note: It is not possible for us to roll back this change on a per-customer basis due to the integral way in which TLS works with the Atlassian Cloud infrastructure.

Thank you for your patience and I look forward to hearing from you.

All comments

Harry Austin_turbiv

this has just started happening to us as well not sure why

unknown

The cause might be that their Server now enforces TLS1.2

Chris Dunford

We had the same issue but were able to resolve it by adding this:

// Server requires TLS 1.2
System.Net.ServicePointManager.SecurityProtocol = SecurityProtocolType.Tls12;

Be sure this runs before attempting any connections/requests.

Garrett Carver_we27w8

Hi Gajendra,

I was able to fix this by changing the security protocol to TLS 1.2. If you are working in .NET 4.0, you can add the following line before the method call:

 //using System.Net;

 ServicePointManager.SecurityProtocol = (SecurityProtocolType)3072; //use TLS 1.2

Huan Ting Chen

Having the same issue. Any official response from Atlassian? It's very annoying to come across this without prior notice.

support-issues

Thanks for response, I have tried above code and it works in local-host (without HTTPS) but it is not working on our server (as we are using https on server). So please suggest if you have any idea about this.

Regards,

Gajendra

Huan Ting Chen

Official response:

Atlassian has now deprecated TLS 1.0 and 1.1 and will support only TLS 1.2 and 1.3 going forward.

The good news here is that not only do we close some known security vulnerabilities, but TLS 1.3 will bring improved connection times!

You can refer to the following blog post for more information regarding the change: Deprecating TLSv1 and TLSv1.1 for Atlassian Cloud Products

Please note: It is not possible for us to roll back this change on a per-customer basis due to the integral way in which TLS works with the Atlassian Cloud infrastructure.

Thank you for your patience and I look forward to hearing from you.

Steven Wu

We also have the same issue. With the same code and same request, it always works on our development machine but fails on the production machine.

Like other problems we had with the Jira APIs along the way, we went through all the googling results and tried to fix the problem on our own but have no luck.

We logged the support ticket, however Atlassian's support suggested that the notice had been given but we never get any notifications as such. They also suggested that they won't rollback the change which we didn't asked for.

What we asked for is do they have any idea what could be the cause of the problem and how to rectify the issue. We also want to know if the change has been fully or carefully tested before rolling out.

We also want them have a mature method of notifying their customers before they apply changes in the future that may upset or screw up their customer's integration with Jira as they usually do.

Wolfgang Essl

Hi, same here.

.Net Core 3.1 is working just fine, .Net Framework 4.7.2 is unable to establish SSL/TLS connection.

adding above line is not fully solving the problem. Jira responses "Unauthorized".

Any suggestions?

Wolfgang Essl

I was able to solve this by stepping back to .Net Framework 4.6.1 and setting SecurityProtocol to Tls1.2

Default protocol for 4.7.2 is Ssl3, which uses Tls1.0 thus resulting in the "Unauthorized" reply.

creig malta

The error is generic and there are many reasons why the SSL/TLS negotiation may fail. ServicePointManager.SecurityProtocol property selects the version of the Secure Sockets Layer (SSL) or Transport Layer Security (TLS) protocol to use for new connections; existing c# connections aren't changed. Make sure the ServicePointManager settings are made before the HttpWebRequest is created, else it will not work. Also, you have to enable other security protocol versions to resolve this issue:

ServicePointManager.Expect100Continue = true;
ServicePointManager.SecurityProtocol = SecurityProtocolType.Tls12
SecurityProtocolType.Tls
SecurityProtocolType.Tls11
SecurityProtocolType.Ssl3;

//createing HttpWebRequest after ServicePointManager settings
HttpWebRequest request = (HttpWebRequest)WebRequest.Create("https://google.com/api/")

If you create HttpWebRequest before the ServicePointManager settings it will fail and shows the error message.