Wednesday, 25 June 2008

Stunnel and wcf 3.5 https testing, an easy dev setup

Just some quick notes:

Stunnel can act as an https proxy which is very convenient when you need to test / develop against https but don't want to set up or use a proper environment with real certificates etc in the short term.

I wanted to capture some packet traces of WCF3.5 over an https keep alive channel to a Jboss app server serving normal http on the default 8080 - here's what I did:

Download / install Stunnel. The installation process creates a default .pem self signed certificate (sufficient for dev purposes).

Default Stunnel config is in stunnel.conf (or stunnel.cfg on Linux).

For simple https proxying from the standard port 443 to port 8080, the basic condensed configuration in stunnel.conf looks like:

cert = stunnel.pem
socket = l:TCP_NODELAY=1
socket = r:TCP_NODELAY=1
debug = 7
output = stunnel.log
accept = 443
connect = 8080

where we can see the default certificate is being used and I've enabled logging. HTTPS listening on 443 and connecting through to HTTP on 8080 (happened to be Jboss in this instance).

Simple enough, what next. Running the WCF client application - it will barf over the certificate not being trustworthy (an error of the form):

login failed Could not establish trust relationship for the SSL/TLS secure channel with authority 'localhost'

Overriding .NET WCF 3.5 default certificate policy to allow all certs for testing/dev purposes

For test/dev purposes it's often handy to allow all certificates.

What you can do is override the certificate checking policy to "say yes to everything" (Remember to take this out for product release!)

The code looks something like this:

using System.Net;
using System.Security.Cryptography.X509Certificates;
using System.Net.Security;


// ***** WARNING - to be removed for release! *****
ServicePointManager.ServerCertificateValidationCallback +=
delegate(object sender, X509Certificate certificate, X509Chain chain, SslPolicyErrors sslPolicyErrors)
{ return true; };

Which is using an anonymous delegate callback to return true in all cases (true = accept) - which keeps the code nice and compact.

If you're specifically testing keep alive then these additional parameters for stunnel.conf control how the proxy behaves in terms of connection persistence:

session = 300
TIMEOUTclose = 0
TIMEOUTidle = 180

No comments: