如何设置“ServerCertificateValidationCallback”属性恢复到其默认行为?
我在单个方法中使用以下代码行来显式检查并信任来自以下主机的 SSL 证书:MyTrustedCompany.com:
ServicePointManager.ServerCertificateValidationCallback = Function(obj As [Object], certificate As X509Certificate, chain As X509Chain, errors As SslPolicyErrors) (certificate.Subject.Contains("CN=MyTrustedCompany.com"))
代码没有问题 -> 100% 完美运行。
问题是,它影响太深远了。我认为它的范围只会在我贴上它的方法内,但显然它是“ServicePointManager”对象上的共享属性,并且必须在整个应用程序中持续存在,这是我不希望的。
问题是后来我调用我的网络服务等并得到“无法建立信任关系...”异常。这是因为在上面的代码行中,我检查了特定于该方法的 SSL 证书的主机名。我快速测试了从回调返回“True”,因此所有证书都将受到信任,而不是检查特定名称(即 MyTrustedCompany)和后续请求有效。这就是我知道这个回调分配比那个单一方法到达父亲的方式。当然,我可以扩展回调以包含所有其他证书名称,但我宁愿将“ServerCertificateValidationCallback”设置回其默认行为。就像下面的伪代码一样:
ServicePointManager.ServerCertificateValidationCallback = Nothing 'Default checking behavior
如何删除自定义验证并将其设置回默认行为?谢谢!
I use the following line of code within a single method to explicitly check and trust an SSL cert from the following host: MyTrustedCompany.com:
ServicePointManager.ServerCertificateValidationCallback = Function(obj As [Object], certificate As X509Certificate, chain As X509Chain, errors As SslPolicyErrors) (certificate.Subject.Contains("CN=MyTrustedCompany.com"))
No problem with the code -> works perfectly 100%.
The problem is, it is too far reaching. I thought its scope would only be within the method I decalred it, but apparently it is a Shared property on the 'ServicePointManager' object, and must then persist for the entire application, which I do not want.
The problem is later I am calling web services of mine, etc and getting the "Could not establish a trust relationship..." exception. This is because in the line of code above I check for the host name of an SSL cert specefic to that method. I quickly tested Returning 'True' from the callback so all certs would be trusted instead of checking for a specefic name (i.e. MyTrustedCompany) and subsiquent requests worked. This is how I know this callback assignment reaches father than that single method. Sure I could extend the callback to include all other certitificate names, but what I would rather do is set the 'ServerCertificateValidationCallback' back to its default behavior. Like the pseudo code below:
ServicePointManager.ServerCertificateValidationCallback = Nothing 'Default checking behavior
How do I remove the custom validation and set it back to its default behavior? Thanks!
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(5)
这实际上看起来有效(就这么简单)并使对象以其默认方式运行。
This actually appears to work (as simple as it is) and makes the object behave in its default manner.
您只想对某些 URL 返回 true,
但除此之外,这就是您想要的,留下了使用多个委托的可能性。每个回调的逻辑可以包括通过反射进行检查,以便回调仅在从某些组件调用时返回 true,从而在某些 URL 和某些应用程序之间创建某种隧道。
使用此代码的一种方法:
1. 在对象生命周期的早期定义 mIgnoreBadCertificates 委托
2. 将包含“beSecure”代码的属性设置为 true
3. 发送 Http 请求。
4. 将属性设置为 false。这非常重要,应该以保证它被调用的方式实现。 IDisposable 模式是一种选择。
You'll want to only return true for certain URLs,
but otherwise, this does what you want, leaving the possibility of using multiple delegates. The logic for each callback could include a check via reflection so that the callback only returns true when called from certain components, thus creating a sort of tunnel between certain URLs and certain applications.
One way to use this code:
1. Define the mIgnoreBadCertificates delegate early in your object's life
2. Set a property containing the 'beSecure' code true
3. Send the Http Request.
4. Set the property false. This is very important, and should be implemented in a way that guarantees it gets called. The IDisposable pattern is one option.
解决问题的关键点是
RemoteCertificateValidationCallback
的sender
参数是WebRequest
。您可以根据您的网络请求检查发件人,这样您只需检查您的网络请求。这是我的(相对未经测试的)解决方案:A key point to solving your problem is the fact that the
sender
parameter to theRemoteCertificateValidationCallback
is theWebRequest
. You can check the sender against your webrequest so you only do checking for your webrequest. Here is my (relatively untested) solution:在我的program.cs命令行测试中:
可以使用证书和发件人参数执行更多操作,但OP要求执行上述操作。
and in my program.cs commandline test:
It is possible to do more with the certificate and sender parameters but the OP asked for the above.
确保自定义回调可靠地恢复并且整个过程也是线程安全的唯一可靠方法是将需要颠覆回调的代码放入单独的进程中。在许多情况下,这很容易做到 - 例如,您可以使用 Process 类运行单独的进程代码并向其传递命令行。 gRPC 或 WCF 是其他通信选项。
这样,只有单独的进程设置自定义回调,主进程不受影响。
The only reliable way to make sure that the custom callback is reliably reverted and the whole thing is also thread safe it to put the code which needs a subverted callback into a separate process. In many cases this is quite easy to do - you could for example run the separate process code using
Process
class and passing it a command line. gRPC or WCF are other communication options.This way only the separate process sets the custom callback and the main process is unaffected.