We bought into .NET Remoting early and have quite a few products in place that exploit the .NET Remoting lifestyle. Did I say lifestyle? Yes. It seems that, once you go remoting, you don’t want to go back — that is, until WCF came along. It is better (and worse) than remoting. I won’t go into any comparison here but I do want to show an example of using certificate based security to validate a client process because it is pretty cool. I’m using my standard Dog Pound example — which, someday, may run humane societies everywhere.
The architecture looks like this:
Both applications are WinForms apps. The DogServer is configured as the “Host” while DogClient is, you guessed it, the client. My requirement is to fire up DogClient and talk to the server without logging in but I want to be secure in the fact that I’m being authenticated and authorized. We can do this with WCF using either an http connection or a tcp connection and either using a self-hosted server or utilizing IIS as the host. My example is self-hosted because, lets face it, we want that control!
Assuming you have some kind of application architecture set up (download the code and you will) you can make a few minor changes to the config files to enable secure communication between client and host. Our example will not use https for the transport, but, even so, each message will be encrypted using a certificate. The first thing we need to do is create some certificates. If you have a Windows domain with a domain controller that you control, it’s fairly easy to get the certificate server service up and running on Windows Server 2003. For the purpose of this article, we’re using the makecert utility that comes with Visual Studio. Do this:
makecert -n "CN=DogBase" -sk DogBaseKey -pe -sr localmachine -sky exchange -ss TRUST -r DogBase.cer makecert -n "CN=DogServer" -sk DogServerKey -pe -sr localmachine -ss MY -sky exchange -ic DogBase.cer -is TRUST DogServer.cer makecert -n "CN=DogClient" -sk DogClientKey -pe -sr localmachine -ss MY -sky exchange -ic DogBase.cer -is TRUST DogClient.cer
After you execute the third makecert statement you should see DogClient and DogServer certificates in the personal store of [Local Computer]. Use the mmc certificate snap-in to view your certificates. You may need to copy the certificate from the Enterprise Trust store to the Trusted Root Certification Authorities store before things will work for you. I’m not a certificate guru by any means and getting this little sample running in a repeatable process was not the easiest thing i’ve ever done.
We’re finally ready to test some code. If you downloaded the code then you have everything you need to perform a test. If not then you need to modify your configuration files to use certificates and transport security as follows:
Some things to note about using makecert for your certificates: It is easy to get things set up and it provides a good learning experience for certificates but the certificates created should not be used in a production environment. There are also a few caveats. I had to configure the client and server to use PeerTrust on each other’s certificates instead of the default ChainTrust (see the config files). I believe this is partly because I’m using makecert for my certificates and partly becaues my computer is part of a windows domain. I didn’t have this trouble when using certificates issued by the certificate authority from my domain controller. For similar reasons, I had to set the negotiateServiceCredential to false and supply the service certificate in the client configuration.
In a future post I will dive into Mixed-Mode security where we use https for the transport and encrypt the messages.