9

There's this request that simply won't work on c# (either RestClient or HttpClient). when I try connecting to the endpoint on RestSharp I get StatusCode 0, and on HttpClient I get this exception:

Authentication failed because the remote party sent a TLS alert: 'HandshakeFailure'.

Funny thing about that is that it works pretty fine on Postman (Yes I tried generating the code from the postman and it still didn't work).

I looked on the postman and it used the TLS 1.2 certificate, then I tried this:

ServicePointManager.SecurityProtocol = SecurityProtocolType.Tls12;

still, nothing.

Checked the url, authentication, headers, http verb and everything is OK.

Obs: I can only access this endpoints tru a VPN, does that ring a bell?

Checking the TLS version used by the postman

Pedro Leal
  • 439
  • 1
  • 4
  • 9

2 Answers2

19

I have a similar problem. In my case, the windows version of my server is too old. The requests work totally fine on my (up-to-date) Windows 10 laptop but will fail with the "HandshakeFailure" on my Windows Server 2012 R2 machine.

If I understood it correctly, it all comes down to the supported ciphers shipped with your operating system. (You can find the list of all supported ciphers for most windows versions here: https://learn.microsoft.com/en-au/windows/win32/secauthn/cipher-suites-in-schannel).

If your HTTPS website uses ciphers that are not supported by your operating system, .NET will throw this error. You can find out the supported ciphers of the HTTPS endpoint using tools like sslscan (https://github.com/rbsec/sslscan).

Why does it work in Postman/Browsers? Browsers and other tools ship with their own set of ciphers. That's why those tools are not affected by this.

Sadly, I don't know about any fix for this, except updating your windows machine. But I hope it answers the question of why it's not working.

There is one more possible solution to this problem, but only if you own the domain you are requesting. You could "downgrade" the cipher used for the domain.

n-develop
  • 589
  • 7
  • 13
  • Do you know why .net core relies on the outdated ciphers provided by the operating system 9 years ago, when other tools provide their own. Seems like it could be added as a nuget package to prevent this sort of situation. – priehl Nov 22 '21 at 22:09
  • I don't know, why .NET relies on the operating system in these things. Yes, I think a NuGet package could be a solution. There is one more possible solution to this problem: If you own the domain you are requesting, you can "downgrade" the cipher used for the domain. – n-develop Jan 28 '22 at 12:20
  • https://stackoverflow.com/a/68287381/7960551 ;the answer provide a solution,use another curl to get data – 我零0七 May 25 '23 at 16:18
1

I know it's a bit late, but for those having the same issue, I would recommend using the IISCrypto tool from Nartac available here.

Quoting their site:

IIS Crypto is a free tool that gives administrators the ability to enable or disable protocols, ciphers, hashes and key exchange algorithms on Windows Server 2008, 2012, 2016 and 2019. It also lets you reorder SSL/TLS cipher suites offered by IIS, change advanced settings, implement Best Practices with a single click, create custom templates and test your website.

For most cases, pressing the Best Practices button and rebooting would be enough.

fred31330
  • 23
  • 4