2

I have an updater application that is being started when an update is available. This application is simply downloading a new exe to a specified path, but suddenly it is not working anymore. The updater downloads the file with a size of 0kb and does not give any error.

I had uploaded the new exe to the server 2 months ago and many clients downloaded the file successfully. Yesterday, one of my clients noticed when he started working with the application and the update failed. The updater is running on many clients and worked always. Could it be a server issue?

Here is the updater code in C#:

public void StartUpdate()
{
    WebClient webclient = new WebClient();
    try
    {
        //webclient.DownloadFile("http://www.example.nl/folder/example.exe", @"C:\example\example.exe");

        webclient.DownloadProgressChanged += new DownloadProgressChangedEventHandler(webclient_DownloadProgressChanged);
        webclient.DownloadFileCompleted += new AsyncCompletedEventHandler(webclient_DownloadFileCompleted);
        webclient.DownloadFileAsync(new Uri("http://www.example.nl/folder/example.exe"), @"C:\example\example.exe");
    }
    catch (Exception)
    {
        MessageBox.Show("Download Failed.\n\nPlease contact your system administrator");
        Application.Exit();
    }
}

void webclient_DownloadFileCompleted(object sender, AsyncCompletedEventArgs e)
{
    label1.Text = "Download successfully!";
    label3.Text = "Download complete!";
    timer2.Enabled = true; //here some other magic happens like start the program and exit this updater.
}

void webclient_DownloadProgressChanged(object sender, DownloadProgressChangedEventArgs e)
{
    progressBar1.Maximum = (int)e.TotalBytesToReceive / 100;
    progressBar1.Value = (int)e.BytesReceived / 100;
}

I am running Apache on CentOS where the exe file is stored. Folder/file permission are okay. When I open the exe URL in any browser, the file is being downloaded successfully. I never change the exe file within the past 2 months nor any other settings on the webserver. This method worked for 2 years and now it automatically stopped working.

UPDATE:

System.Net.WebException: The request has been aborted: Cannot create a secure SSL / TLS channel.
 at System.Net.HttpWebRequest.EndGetResponse (IAsyncResult asyncResult)
 at System.Net.WebClient.GetWebResponse (WebRequest request, IAsyncResult result)
 at System.Net.WebClient.DownloadBitsResponseCallback (IAsyncResult result) A first chance exception or type 'System.ComponentModel.Win32Exception' occurred in System.dll
Luca Kiebel
  • 9,790
  • 7
  • 29
  • 44
Salihan Pamuk
  • 175
  • 1
  • 2
  • 13
  • I tested this on different machines, it is not working anymore on all of them... – Salihan Pamuk Mar 29 '19 at 11:17
  • I'd bet the server requires TLS1.2 now. This isn't someting new, everyone is moving to TLS1.2 since 2016 and HeartBleed. Airlines dropped support for anything less than TLS1.2 as far back as 2016. Google, Azure, Amazon, banks etc. have announced they'd drop support for anything less for years now. – Panagiotis Kanavos Mar 29 '19 at 11:36

2 Answers2

2

It seems like your server SSL certifcate is broken. It is possible expired. If you are using a self signed certificate make sure you imported the the CA certiface you used to self sign your servers certificate. An other possibility is that your server (or client) has an invalid system clock. So the client thinks your certificate expired.

Pretasoc
  • 1,116
  • 12
  • 22
0

The program could not handle secured uri's. I added the following line

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

below this line

webclient.DownloadFileCompleted += new AsyncCompletedEventHandler(webclient_DownloadFileCompleted);

which fixed my problem.

Salihan Pamuk
  • 175
  • 1
  • 2
  • 13
  • That's not the problem at all. The problem is that the *server* dropped support for older TLS protocols, something that's been going on for the last 3 years among all service providers and companies. – Panagiotis Kanavos Mar 29 '19 at 11:38
  • My another concern now is that I am stuck since I don't know how to update all the updaters on every client machines :( Any suggestions are recommended. – Salihan Pamuk Mar 29 '19 at 11:42
  • The *correct* solution is to use a current .NET version and Windows OS. .NET uses the best algorithm available on the OS during SSL negotiation since 4.6.1. This means that when TLS1.3 becomes available on the OS, .NET will pick it up automatically. Hard-coding the TLS version was only needed in older .NET version. – Panagiotis Kanavos Mar 29 '19 at 11:44
  • Older OS versions like Windows 2008 R2 require patching to support TLS1.2 by default too. This matters because people are getting ready to move to TLS1.3. Hardcoding TLS1.2 may cause problems in the near future – Panagiotis Kanavos Mar 29 '19 at 11:45
  • Check [Transport Layer Security (TLS) best practices with the .NET Framework](https://learn.microsoft.com/en-us/dotnet/framework/network-programming/tls) – Panagiotis Kanavos Mar 29 '19 at 11:48
  • Thank you for this tip. Does this have impact on clients running old .NET framework on their computer? I can see that the use of SystemDefault on the Security Protocal is from .NET Framework 4.6 and above. Does this mean that every client needs to install/update their .NET Framework to 4.6? – Salihan Pamuk Mar 29 '19 at 14:44