2

I am making a webrequest to an 3rd party api and it was working fine. In between the certificate was changed for the API and now when i make the request from our dev environment, I am getting response as The request was aborted could not create SSL/TLS secure channel. I tried setting different protocol in code and there is no change in the response. I was getting a different error in explorer also. But that was fixed after enabling SSL 3. I am using httpwebrequest in the code. The initial dll was in .net 3.5 and it has been updated to .net 4.6 now. When checking the certificate details in firefox, i can see the certificate is TLS 1.3. As far as i understand it is not supported in .net 4.6.1 as i get protocol not supported error when i set it TLS value. The dev environment is a Windows server 2016. The same API is working in production in Microsoft cloud. Not sure about the exact server version.

Is there any way i can fix this issue.

Update The certificate algorithm was not there in the cipher suites. Followed the below document to add the cipher suite and the issue is now resolved.

https://learn.microsoft.com/en-us/windows-server/security/tls/manage-tls

Suhail Ismail
  • 55
  • 1
  • 1
  • 7

3 Answers3

5

Unfortunately, you cannot fix this issue yet.

The .NET Framework simply delegates to the underlying Windows platform WinINet/SChannel APIs to make outgoing HTTPS calls, and WinINet/SChannel on Windows Server 2016 has not yet been rolled out with the necessary changes to allow TLS 1.3 outgoing connections.

Applications targeting Framework 4.7.1 and later will automatically use the highest TLS version available on the OS it's running on, and fall back to lower ones if the server you're connecting to doesn't support it, so you won't need the following code (unless your current code [or a dependency] already calls it with a lower version).

If you're stuck on Framework < 4.7.1, you can prepare your code for the eventual Windows updates:

// From .NET Framework 4.8.0, simply use SecurityProtocolType.Tls13
// (or rather don't use this code at all from 4.7.1, configure the TLS versions in the OS)
const SecurityProtocolType tls13 = (SecurityProtocolType)12288;

ServicePointManager.SecurityProtocol = tls13 | SecurityProtocolType.Tls12;

(Some sites may require you to also append | SecurityProtocolType.Tls11, but those sites really should update their servers).

This SecurityProtocolType value of 12288, meaning TLS 1.3, will now be future-proof and passed on to the underlying Windows API layer, but will now throw an exception if the site you're calling only speaks TLS 1.3:

Win32Exception: The client and server cannot communicate, because they do not possess a common algorithm

This fix therefore only works after TLS 1.3 support is rolled out to Windows Server.

Windows 10 and Windows Server 1903 have experimental support for this, but if you can't upgrade your .NET Framework from 4.6, I doubt you can install a Windows Server release that uses experimental features.

For more information, see the following references:

CodeCaster
  • 147,647
  • 23
  • 218
  • 272
  • @CodeCaster when i call the domain from the explorer, i get this error "Turn on TLS 1.0, TLS 1.1, and TLS 1.2 in Advanced settings and try connecting to again. If this error persists, it is possible that this site uses an unsupported protocol or cipher suite such as RC4 (link for the details), which is not considered secure. Please contact your site administrator.". When i enable ssl3 in explorer settings the error is gone and the link will start work in explorer. So how is it working in explorer and other browsers in the same system but not working in the code. – Suhail Ismail Nov 17 '20 at 07:23
  • @Suhail SSL3 is not TLS 1.3. SSL3 is old, insecure and should be left disabled. IE uses SChannel. If enabling SSL3 fixes it for Internet Explorer, it should also work for C# (as both use SChannel), try `System.Net.ServicePointManager.SecurityProtocol = System.Net.SecurityProtocolType.Ssl3 | System.Net.SecurityProtocolType.Tls12 | SecurityProtocolType.Tls11 | SecurityProtocolType.Tls;` – CodeCaster Nov 17 '20 at 08:41
  • We know both agree that it is a windows issue. I believe as part of the Microsoft updates that a push was done in the last couple of years to add TLS 1.3 to windows. I don't see how Microsoft would not implement TLS 1.3 on all servers. The TLS enumeration in c# is the same as in windows and all the c# code is doing is passing the TLS mode(s) to windows. – jdweng Nov 17 '20 at 10:27
  • 1
    SChannel, the core component in Windows that delivers _one way of issuing HTTPS requests_, has **not yet been updated to support TLS 1.3**, except for Windows 10 and Windows Server 1903 and newer, in which it has been included **for testing purposes, not production use**. This does not include Server 2016. The DLLs that form SChannel do not contain the required algorithms ("cipher suites") to talk TLS 1.3 on Windows Server 2016. It has **not** been updated in "the last couple of years to add TLS 1.3". – CodeCaster Nov 17 '20 at 10:47
  • @CodeCaster i actually tried the same as you suggested before posting the question here. Any way, I will try all these again and update. – Suhail Ismail Nov 17 '20 at 19:24
  • @jdweng i read an article from microsoft which says windows server 2016 doesn't support tls 1.3. – Suhail Ismail Nov 17 '20 at 19:26
  • @Suhail I'm telling you, it won't work yet, because as you also found, the necessary changes to Windows Server 2016 to support TLS 1.3 have not yet been rolled out. – CodeCaster Nov 17 '20 at 20:33
  • 1
    Sure, that's fine. I know what you mean about not wanting to jump through hoops for a one-off. I won't necessarily, for example, factor code out into a function if it's only being used one place. But I think these types of symbolic constants are different. Any time you find yourself writing a comment out to the left of a declaration, you probably should have introduced a symbolic constant instead. This is a great answer, and I was really just nitpicking, both with my comment and my grammar edits. – Cody Gray - on strike Nov 18 '20 at 21:20
0

The certificate algorithm was not there in the cipher suites. Followed the below document to add the cipher suite and the issue is now resolved.

https://learn.microsoft.com/en-us/windows-server/security/tls/manage-tls

Suhail Ismail
  • 55
  • 1
  • 1
  • 7
0

The same error can be seen when web applications don’t have permissions to access certificates.

Our web application uses client certificates to authenticate against remote web services. When the certificate was reissued and installed we started to see this error.

The solution was to grant permissions to the account that the web application runs as.

On Windows:

  • Manage computer certificates > Certificates – Local Computer > Personal > Certificates
  • Right-click the certificate > All Tasks > Manage Private Keys
  • Then Add the relevant account for the app pool – in our case it was Network Services

Hope this helps someone

B.Mo
  • 191
  • 6