views:

57

answers:

1

I am trying to fetch a page using HttpWebRequest, but I am getting this exception:

Could not establish trust relationship for the SSL/TLS secure channel.

Is it possible to specify a custom RemoteCertificateValidationCallback for a particular instance of HttpWebRequest?

(I cannot use ServicePointManager.ServerCertificateValidationCallback, since my code is part of a library.)

+1  A: 

I cannot use ServicePointManager.ServerCertificateValidationCallback, since my code is part of a library

Do this, but filter calls to the delegate based on sender?

Update: Based on feedback: It might be necessary to spin up an AppDomain to do this (which will avoid interference with other things happening in the same process).

Richard
I know that the sender contains the instance of `HttpWebRequest`. But the library cannot change that, because applications that will be using that library may change `ServerCertificateValidationCallback` without noticing that the library has already modified that.
TN
If you're using HttpWebRequest to imlement functionality of your library, it seems like implementation details (HttpWebRequest) are leaking out of your API. Why do consumers of your library need access to that class? i.e. Why isn't that functionality encapsulated in your library?
Kirk Woll
@TN is the application (or another library) is making such global changes your screwed anyway. You can add/remove your delegate without interfering with other handlers attached (this is normal behaviour--events have no mechanism to remove all attached delegates).
Richard
@Kirk Consumers do no need to access that class. It is encapsulated in the library. The problem is that changing a global static property `ServicePointManager.ServerCertificateValidationCallback` in a library is not a good idea, since some applications may use that for their purposes.
TN
@Richard `ServicePointManager.ServerCertificateValidationCallback` is not an event but a property.
TN
Thanks for the clarification, TN. Sorry, didn't realize that was static.
Kirk Woll
@TN: Oops, really should check these things rather than relying on memory. I've updated the A, since there is a way to make the property non-global => your own AppDomain.
Richard
@Richard You suggest to run parts of the library in another AppDomain? It will become a fat library:) What about another solution?
TN
@TN: Not part of the library, but part of the *process*. This is the only way to have a different instance of a static property without a separate process. Unless you load many assemblies into the AppDomain it will not be a big memory impact. Also you only need the AppDomain the the downloads themselves, all other processing can take place in the calling AppDomain.
Richard
@Richard: OK, it seems that the API is really bad designed. There is no other way:(
TN