C# Rest Api TLS/SSL Connection Error

This is a dotnet error caused by your server configuration.

A google search for "The remote certificate is invalid according to the validation procedure" returned a tonne of possible answers, including this Stack Overflow post: c# - The remote certificate is invalid according to the validation procedure - Stack Overflow

But when I run the project on localhost, I cannot access the safe. Are you still saying it's due to the same reason? By the way, my domain name starts with http.

I don't know what you mean.

The error message is because the code cannot access the server due to an issue with the SSL handshake.  The error explicitly states that it's to do with the remote certificate.  My guess would be that the remote certificate used by the vault isn't trusted by your machine for some reason.  This could be an expired certificate, an untrusted CA, etc.

I'd start by looking at some of the content in the like I gave you.

So how can I solve this? The internet I use is the internet of a large multi-user company. Maybe a change has been made regarding the firewall or SSL/TLS settings. The machine I use is a machine that is remotely controlled by the system administrator and necessary changes are made from time to time. I have no knowledge about this subject. If I can fully understand the solution to the error, I can decide more clearly what to do. What do you suggest I do about this? Of course, if the error is on the m-files side, the situation is different. The project I developed was prepared in Visual Studio with C#. I'm trying to access the vault in this project.

I'm not sure how much more I can guide you.  As I said: this is a situation where dotnet is not accepting the remote certificate; the exact reason could be any number of things.  It's highly unlikely that the issue is directly related to M-Files at all, but to the infrastructure around it.

Trying to be helpful, maybe...

• Have you looked at any of the options shown on the link I gave you? There was a huge range of possibilities there, so have you researched into whether any are appropriate?
• Have you spoken to the administrator of the system(s) involved to see whether they've made a change?

First of all, thank you very much for your interest. I found the cause of the error. The error is caused by Restsharp removing the MFWSClient method from the relevant version. However, when I tried other versions, I saw that there was no relevant method. How can I find a solution to this problem?

Restsharp Version: 106.12.0

MFaaP.MFWSClient Version: 1.3.0-alpha

Now I'm getting this error message:

System.MissingMethodException: 'Method not found: 'Void RestSharp.RestClient..ctor(System.Uri)'.'

First of all, thank you very much for your interest. I found the cause of the error. The error is caused by Restsharp removing the MFWSClient method from the relevant version. However, when I tried other versions, I saw that there was no relevant method. How can I find a solution to this problem?

Restsharp Version: 106.12.0

MFaaP.MFWSClient Version: 1.3.0-alpha

Now I'm getting this error message:

System.MissingMethodException: 'Method not found: 'Void RestSharp.RestClient..ctor(System.Uri)'.'

I'm not sure the two are related.  The error was very specific.  I think you've upgraded the RestSharp project reference whilst testing this.  By changing the referenced version of RestSharp you've managed to reference a version that doesn't have a constructor that the library expects, thus causing that error.  I strongly suspect that even if you solve this specific issue you'll be back where you were.

That said: it appears you're using the MFWSClient sample.  Please note:

• This library is not official, and has no direct support.
• Feel free to open an issue on the github repository: GitHub - M-Files/Libraries.MFWSClient: An example .NET wrapper for the M-Files Web Service.  Please include a full project that reproduces the issue so that we can see the exact packages you're referencing.
• Note that the version you're using is relatively old.  Try:
  • Update the version of the package to the latest one.
  • Either do not explicitly target RestSharp or, if you have to, ensure you target the exact version that the project uses (108.0.2).

Ok I solved the problem. I think it's exactly Restsharp SSL error. To prevent this, I wrote the code that ignores the SSL error and also updated the MFaaP.MFWSClient library I was using to its latest version. Thanks very much for your help.

I would strongly recommend fixing the SSL issue rather than use a workaround that suppresses the SSL issue. 

But glad you have fixed it 

Yes, the solution I found is a temporary solution. I am also looking for a permanent solution. Do you have any advice as a permanent solution?

Yes: someone needs to identify the SSL issue and fix it.  You could use the link at the start of the thread as a starting point.

Ok I understand. I wonder if it is the people from Restsharp who will bring a solution to this issue? Who should find a solution when I ask a question from the link you shared? Or should I contact them directly?

I don't know what to say to you, as I feel I've said it all before.

I don't believe that the issue is with the MFWSClient library itself.  I don't believe that the issue is in RestSharp.  I believe the issue is with your infrastructure there.  I would assume that identifying and fixing the issue will be down to you and whoever administers the infrastructure.

Obviously feel free to create an issue on the RestSharp github project if you disagree with me.

Show me the code that you used to ignore the SSL error.  Maybe that'll convince me that it's a bug somewhere else, but I suspect you've simply told dotnet to ignore the SSL validation.

My code that I use to ignore ssl errors is as follows. 

ServicePointManager.ServerCertificateValidationCallback += (sender, certificate, chain, sslPolicyErrors) => true;

Yep; so you've told dotnet to ignore the SSL errors.

This further indicates to me that the issue is your infrastructure - as I said in the first post - and nothing to do with either library.