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 exp
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:
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.
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.
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.