Debugging failing HTTPS WebRequest

Question

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!

Answer 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.

Answer 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.