CODEWITHSUNDEEP
c#web-servicessslhttpscertificate
Marcelo
Marcelo

Reputation: 3391

SSL connection to WebService with invalid certificate workaround not working

In my WPF application I want to make a connection with a Web-Service through HTTPS ignoring possible certificate errors, which seems to be a fairly common thing to do, from what I've been researching.

I've found this nifty snippet:

ServicePointManager.ServerCertificateValidationCallback = delegate { return true; };

I've set a breakpoint on the return statement, and it is never called (tried it with a separate method too).

I've also tried setting the following properties to false:

ServicePointManager.UseNagleAlgorithm = false;
ServicePointManager.Expect100Continue = false; //tried true too
ServicePointManager.CheckCertificateRevocationList = false;

I've also tried to create my own ICertificatePolicy with a CheckValidationResult that always returns true and attributing it to ServicePointManager.CertificatePolicy. That also hasn't worked.

In all of these attempts, I get the following:

The underlying connection was closed: An unexpected error occurred on a receive

I've created a separate windows forms application with just three lines:

WebReference.MySebService myWebService = new WebReference.MySebService();
ServicePointManager.ServerCertificateValidationCallback = delegate { return true; };
bool result = myWebService.TestConnection(); 
//TestConnection is a method in my WebService that simply returns true.

And it WORKED.

What else could I try ?

Info:

Upvotes: 1

Views: 2315

Answers (1)

Marcelo
Marcelo

Reputation: 3391

After stressing a lot about this, we've finally come to a solution.

The hint to it was in the inner-exception, which passed unnoticed before. It stated that it failed to load a Security assembly.

Coincidentally we had a project named Security with an output assembly named Security on this solution, which caused a conflict. And it was only incorrectly accessed when SSL was being used.

Interestingly enough, neither Visual Studio, nor the compiler have warned me that this wasn't such a good idea, and not even that there was a .NET assembly named just like ours.

The solution was to rename this assembly, and everything worked perfectly immediately without a flaw.

Lessons learned:

  • Use customized names that could never exist already, like SPONGEBOBSQUAREPANTS_Security.
  • Do not trust that Visual Studio will check if my assembly is conflicting with anything.
  • Always check for inner exceptions, no matter how familiar their outer ones may seem.

Upvotes: 2

Related Questions