Develop Reference

The request was aborted could not create SSL/TLS secure channel - HttpWebRequest

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

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:
Microsoft TLS 1.3 Support Reference
Transport Layer Security (TLS) best practices with the .NET Framework
TLS1.3 is it supported?
Protocols in TLS/SSL (Schannel SSP)

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

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

HTTP2_Protocol Error in Production with https protocol

While using https with IIS we are intermittently getting ERR_HTTP2_PROTOCOL_ERROR on Dev tool in Production env.
This works fine with http protocol (QA). We are using IIS 10.
We are using React Framework 16.11.0 version and the fetch method fails.
This happens in all the browsers (edge, chrome etc.) See attachment below.
Sharing below the net log data.
{"params":{"**description":"Server reset stream.","net_error":"ERR_HTTP2_PROTOCOL_ERROR","stream_id":183},"phase":0,"source":**{"id":2567,"start_time":"1619763469","type":1},"time":"1619779275","type":222},

Does the error occur in other browser? Such as Firefox or EDGE. It seems that the error only relates to the client-side not server-side. Alternatively, try to disable HTTP/2 in IIS10.
How to disable HTTP/2 on IIS of Windows Server 2016
or disable TLS1.2 to see if it works.
https://support.secureauth.com/hc/en-us/articles/360019889231-Enable-Disable-SSL-TLS-versions-via-Registry-Editor
Check this link for more information.
https://forum.seafile.com/t/http-2-breaks-some-functionalities/9474

C# FtpWebRequest with SSL to Ubuntu VSFTPD

I have spent hours trying to get the .NET FtpWebRequest library to communicate with my Ubuntu 16.04 FTP server using vsftpd over SSL.
No matter what I try, I always end up with the exception "A call to SSPI failed. The message received was unexpected or badly formatted."
I have tried generating client and server certificates, installing them in windows, loading them with the X509 class in .NET, toggling various client and server side options. No matter what I do, it's always the same error. I believe this has something to do with my certificate not being verified by an authority. Here are my basic questions:
1) Can .NET just ACCEPT a suspicious certificate?! Installing it 30 different ways seems to have no affect?
2) What does "a call to SSPI failed" really mean? I've read conflicting answers. I have no problem connecting with TLS/SSL via FileZilla, but .NET 4.5 just won't have it.
3) Can someone give the minimum amount of steps to have a Windows 7 client using the .NET framework connect to a Linux server using vsftpd over SSL? I strongly believe the problem lies in my Windows/.NET settings since FileZilla on my Windows machine has no problem connecting.
Thank you in advance.

Insert the line below in your vsftpd.conf:
ssl_ciphers=AES128-SHA

How to make TLS requests in .Net 4 on Windows XP to servers with SSL3 disabled?

I'm supporting a Windows application built with .Net 4.0 (Visual Studio 2010) which is connecting to a variety of web services onto our Apache webservers. Due to the Poodle bug, SSL3 has been disabled on these servers. An updated version of the application is using the WebClient class with TLS enabled and can successfully connect:
using (var client = new WebClient())
{
ServicePointManager.SecurityProtocol = SecurityProtocolType.Tls;
client.DownloadString(uri);
}
Not our customers stuck on Windows XP however (Forcing them to upgrade the OS is unfortunately impossible). I can reproduce their error reports that SSL/TLS channels cannot be established.
Even disabling the certificate check (for testing purposes only) doesn't help:
ServicePointManager.ServerCertificateValidationCallback = delegate { return true; };
From my research I know that Windows XP and .Net 4.0 supports TLS 1.0, so theoretically this should still be possible. Due to the little information given in the thrown exception, I cannot find out what fails exactly.
Could this be an issue with the server configuration?
Sample URL: https://api.meteotest.ch/ssl.txt

At MSDN you will find the cipher suites supported by Windows XP. This shows, that XP does not support any AES cipher suites. But, as shown on SSLLabs all ciphers supported by your server are AES. Therefore there are no common ciphers between client and server and the SSL handshake will fail, which is also shown for XP in the output from SSLLabs.
Since RC4 is broken too I would not recommend to use any RC4 ciphers. So it might be the best to enable the 3DES ciphers to support XP clients, that is TLS_RSA_WITH_3DES_EDE_CBC_SHA (DES-CBC3-SHA in apache config). Of course you should put this cipher at the end, so it gets only used if the client does not support any of the other ciphers.

Cannot connect to WebSocket Server. No idea why

I'm using the code from this article just to try and get something up and running. However, I cannot seem to connect to the web sockets server once it's running.
I have tried forwarding both ports 8080 and 8181, ensuring that they are forwarded using canyouseeme, allowing the ports under my firewall, completely disabling my firewall, trying and forwarding different ports, etc.
Nothing has worked so far. Both the HTML browser page and console server application run just fine with no errors but I keep getting this error message when I try to connect through the HTML page in my browser:
Connecting to ws://localhost:8181/chat ...
Socket closed!
I have never used WebSockets before so I'm not sure if I'm missing something like if I need to install some framework, run some daemon, or what. I'm running Windows 7 64 Bit and using Visual Studio to run the solution. Not sure how to get this to work. Anyone have any ideas?

The server mentioned in that article is likely using the older Hixie protocol. If you are running a recent version of Chrome or Firefox then you are using the newer HyBi/IETF protocol. The article was written in Jun 2010 before the newer protocol was standardized and adopted.
Update:
Fleck looks like a descendant of the code in that article (via Nugget) that supports the old and new protocol variants.