Debugging failing HTTPS WebRequest

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)开发者_JAVA技巧; // url is an HTTPS URL.
X509Certificate clientCert = new X509Certificate("certificate.crt", "password");
req.ClientCertificates.Add(clientCert);
WebResponse resp = req.GetResponse(); // This fails!

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.

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.

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.