Debugging failing HTTPS WebRequest

大兔子大兔子 提交于 2019-11-26 16:36:41

问题


I'm writing a small program which will make a GET request to a server using HTTPS and the HttpWebRequest class. The server (obviously) has a server certificate. It also expects the client to provide a certificate.

When making the request, however, I get a System.Net.WebException stating that it wasn't possible to establish a secure TLS/SSL connection. I quickly discovered that the server's certificate wasn't valid. Assuming this was what was causing the exception, I tried to accept the invalid certificate (updating the certificate is, unfortunately, not an option) using the code below:

ServicePointManager.ServerCertificateValidationCallback += delegate {
    return true;
};

That didn't solve the problem, however.

Since the exception doesn't give any detail, it's hard to actually determine what is causing it. Is my attempt to override the invalid server certificate not working? Is the client certificate I'm providing not trusted by the server? Am I not loading the client certificate in the proper manner?

I'd love tips on how to debug this sort of problem. I do not have access to the server or its logs, unfortunately.

Below is the important parts of the code:

ServicePointManager.ServerCertificateValidationCallback += delegate {
    return true;
};
HttpWebRequest req = (HttpWebRequest)WebRequest.Create(url); // url is an HTTPS URL.
X509Certificate clientCert = new X509Certificate("certificate.crt", "password");
req.ClientCertificates.Add(clientCert);
WebResponse resp = req.GetResponse(); // This fails!

回答1:


Slap some tracing on it! Traces are your best friend when debugging theese things. I once had one client which couldn't connect to our SSL-enabled service. Using tracing I found that someone had moved the system clock past our certificate expiry date. But I digress.

Enable all applicable trace sources and see if something interesting show up in the logs.

There's an old (2005) but excellent post by Durgaprasad Gorti that you should check out. It'll show you exactly what sources to add and in it he also shows some SSL traces using a custom validation callback.

Example app.config from the very same blog post:

<?xml version="1.0" encoding="UTF-8" ?>
<configuration>
  <system.diagnostics>
    <trace autoflush="true" />
    <sources>
      <source name="System.Net">
        <listeners>
          <add name="MyTraceFile"/>
        </listeners>
      </source>
    </sources>

    <sharedListeners>
      <add
      name="MyTraceFile"
      type="System.Diagnostics.TextWriterTraceListener"
      initializeData="System.Net.trace.log"
    />
    </sharedListeners>

    <switches>
      <add name="System.Net" value="Verbose" />
    </switches>

  </system.diagnostics>
</configuration>

Hopefully that'll provide you with some more data.




回答2:


Some thoughts:

  1. TLS defines some error codes and alerts. SSL/TLS libraries often provides this code when an exception is thrown. Maybe could you find this information in the server log.

  2. Maybe there is some missing certificates when the server sends its certificate chain. For instance if the server sends only its certificate the client may not be able to attach this certificate to a root certificate if there is some intermediate CA certificate.

  3. If the client is expected to use a certificate for authentication the server is supposed to send the names of the accepted root certificates. My previous point is also valid here, if some intermediate certificates are missing the cannot build a chain between its certificate and a root sent by the server. The client does not find a suitable certificate (because a private key is not available) is another possible issue.




回答3:


I agree with Markus's solution above. I once had a similar issue, and I found that the best thing to do is get that exception under a debugger.

If you can run a build locally and look at that exception in the debugger, you have to drill down several levels before you get to the real meat of the issue.

In the case I'm thinking of, I had to look through 4 or 5 innerExceptions before I got to the message that told me specifically what was wrong.

I found that this tends to be true in many cases in .Net generally - you will get an exception which has a very generic error message, and you need to dive several "innerException" levels down before you get to the meat of the issue.

Hope this helps.



来源:https://stackoverflow.com/questions/5977817/debugging-failing-https-webrequest

易学教程内所有资源均来自网络或用户发布的内容,如有违反法律规定的内容欢迎反馈
该文章没有解决你所遇到的问题?点击提问,说说你的问题,让更多的人一起探讨吧!