SSPI authentication failure ALSO with api.getfiddler.com

2 Answers 26 Views
Windows
Glenn
Top achievements
Rank 1
Iron
Glenn asked on 11 Apr 2024, 05:41 AM

Hi everyone,

I have an .net framework 4.7.2 C# WPF app running which also has a little .net 3.5 app inside it.

This is running 1500 computers in australia and has been for 18 months.

Today we started getting reports of computers having 'crashes'

Debugging has provided this info:

section: created rest options System.Net.Http.HttpRequestException: An error occurred while sending the request. ---> System.Net.WebException: The request was aborted: Could not create SSL/TLS secure channel.

What we have now found out is that it is Windows 7 clients all being affected.

Importantly:

Postman and google chrome can access the api

JUST the .net seems ot be having issues.

After seeing this I have downlaoded fiddler (for first time) and we are seeing a handshake issue:

fiddler.network.https> HTTPS handshake to www.mydomain.com.au (for #710) failed. System.Security.Authentication.AuthenticationException A call to SSPI failed, see inner exception. < The message received was unexpected or badly formatted

Win32 (SChannel) Native Error Code: 0x80090326


But then when i booted fiddler im also seeing the same issue:

[Fiddler] The connection to 'api.getfiddler.com' failed.  <br />System.Security.SecurityException Failed to negotiate HTTPS connection with server.fiddler.network.https&gt; HTTPS handshake to api.getfiddler.com (for #1) failed. System.Security.Authentication.AuthenticationException A call to SSPI failed, see inner exception. &lt; The message received was unexpected or badly formatted

Win32 (SChannel) Native Error Code: 0x80090326                                       

 

 

So maybe the fiddler API is in fact having the same connection issue as I do, but maybe thats not really going to be noticed because its an update checker for their API but mine is my whole app??

 

Any ideas would be appreciated.

 

Zhivko
Telerik team
commented on 11 Apr 2024, 09:44 AM

Hi Glenn,

I believe the issue is happening due to a TLS version mismatch.

.NET Applications use WinHTTP by default for secure communications. Unfortunately, TLS 1.1 and TLS 1.2 are not enabled by default in Windows 7. To enable it, you'd need to install Update 3140245 and follow the instructions here:
https://learn.microsoft.com/en-us/mem/configmgr/core/plan-design/security/enable-tls-1-2-client

Let us know if you continue experiencing the problem after that.

Best regards,

Zhivko

 
Glenn
Top achievements
Rank 1
Iron
commented on 11 Apr 2024, 10:21 AM

THanks Zhivko for your response.

The weird part is that we havent changed anything on the server as far as i know and we havent changed the client app either!

Ive done a test on ssllabs and it does say 1.2 and 1.3 are supported but IE11, win7 -> win 8.1 nare not supported...
it does also say "fatal handshake" which is what wireshark and fiddler have been saying...

I'm just so confused why this has started now.  Just 2 days ago! (after 18 months)
Zhivko
Telerik team
commented on 11 Apr 2024, 12:47 PM | edited

Hi,

Without further information about the setup, I wouldn't be able to tell you why it started happening, however, it's possible that a simple dependency upgrade or a change in the configuration disabled the TLS 1.0 or TLS 1.1 from the server. You can continue the investigation with your engineering team.

Let us know if there's anything else we can help with!

Zhivko

2 Answers, 1 is accepted

Sort by
0
Angela
Top achievements
Rank 1
Iron
answered on 14 May 2024, 06:41 AM | edited on 14 May 2024, 07:16 AM

The issue you’re encountering with SSL/TLS secure channel failures on Windows 7 clients is likely due to the .NET application not using the correct version of the TLS protocol that’s required by the server. Since Postman and Google Chrome can access the API without issues, it suggests that the server is expecting a newer version of TLS than what your .NET application is using.

Update the Security Protocol in Your .NET Application: Set the SecurityProtocol to TLS1.2 before making any requests. This can be done by adding the following line of code at the start of your application:

System.Net.ServicePointManager.SecurityProtocol = System.Net.SecurityProtocolType.Tls12;

Ensure Compatibility: Make sure that your server supports TLS1.2 and that it is enabled on the Windows 7 clients.
Apply Patches: Ensure that all Windows 7 clients are fully patched, as there are updates available that add support for newer TLS versions.
Check Certificates: Verify that the SSL certificates are correctly installed and configured on both the server and the client machines.

 

Remember to test these changes in a development or staging environment before rolling them out to production. 

 

Best Regard.
Angela Huey

0
Glenn
Top achievements
Rank 1
Iron
answered on 15 May 2024, 01:37 AM

I finally figured this out and it is INSANE .. but worth people checking on.

So I'll describe it how I can, but perhaps get some wording incorrect.

My .Net app was FINE, there was nothing wrong with the code at all, it was all related to the cipher suite that my cpanel was using.

My Cpanel had actually dumbed down the cipher suite to allow for Win 7 Ciphers, it had selected RSA as the cipher suite (In cpanel SSL/TLS)

however my .net was forcing it to use ECDSA keys, so there was a handshake issue.

The Win10 had the RSA keys but were tagged as not safe (but still had them) so they continued to function!

 

All i ahd to do was go to SSL/TLKS on CPANEL and choose ECDSA and it recreated the SSL and was working right away...

OMG.

Tags
Windows
Asked by
Glenn
Top achievements
Rank 1
Iron
Answers by
Angela
Top achievements
Rank 1
Iron
Glenn
Top achievements
Rank 1
Iron
Share this question
or