Debugging SSL/TLS problems in .NET

In my previous post I discussed  some issues I discovered with SSL client certificates.

For this application, I’m dealing with PayPal. Rather annoylingly, if your client certificate doesn’t check out, they don’t even bother sending an error – they just drop the TCP connection mid-SSL-handshake. Depending on how fast the connection loss is realised, .NET can return a few different errors; none of which are actually much use when it comes to debugging.

Luckily, System.Net (as with most other areas of the framework) has wonderful tracing capabilities. Particularly with a complex process like an SSL handshake, these capabilities become critical to debugging.

Better yet – they’re incredibly easy to use. Just add a block like this to the end of your app.config!

  <trace autoflush="true"/>
    <source name="System.Net" maxdatasize="1024">
        <add name="TraceFile"/>
    <source name="System.Net.Sockets" maxdatasize="1024">
        <add name="TraceFile"/>
    <add name="TraceFile" type="System.Diagnostics.TextWriterTraceListener"
    <add name="System.Net" value="Verbose" />
    <add name="System.Net.Sockets" value="Verbose" />

Now, run your app again and take a look at the wonderful lines being added to your bin\Debug\trace.log file.

5 thoughts on “Debugging SSL/TLS problems in .NET

  1. My Visual Web Developer studio underlined the following part:
    Indicating that maxdatasize attribute is not declared.
    I just rempved it from the code and it worked fine.

    1. This is just an IntelliSense issue. The trace provider will still receive the attribute and react. It won’t really affect things having it there (IntelliSense will just show the false error) or not (it’ll log in a different batch size).

  2. Hi Mr. Oddie

    My VS 2010 Professional didn’t like the ‘maxdatasize’ attribute either. However, after compiling and running my app – a dll – I don’t see anywhere in my file system such a ‘trace.log’ file.

    Do you/anyone know/s why? A reply would be greatly appreciated

    1. You can change trace.log in the config to point to an absolute path like c:\temp\trace.log if you want. Sometimes the relative path can be a bit hard to track down based on how the app is loaded.

    2. I know this is late to the party, but for the benefit of future Googlers add the lines to the app.config file of the application that is calling the dll

Comments are closed.