Setting up ssl made easy

ySetting up SSL made easy…
This blog post is about a small tool I just finished. It makes configuring and using SSL much easier. In the first part of the blog post I quickly review the problems and difficulties you run into when setting up SSL. Then I introduce SELFSSL7 and finally walk through several usage scenarios.

Setting up SSL - what a pain!
I'm sometimes amazed how hard seeminglysimple things still are. Take SSL as an example. Shouldn't setting up SSL be easier than what's shown in the walkthrough on how to set up SSL in IIS7. Here are the typical steps you have to go through before you can access your SSL site.

Steps to set up SSL
• • • • •

Generate a certificate request Send the request to a Certificate Authority Wait until the certificate is returned to you Installthe certificate and finally you need to add a SSL binding in IIS

Once you've completed all of these steps you are able to use the magic "https" prefix to browse to your web-site. There are all kinds of things that can go wrong during these steps not to talk about the time it takes until you finally have SSL working. It's certainly a royal pain if you want to do that on your local dev box.Self-signed certificates
IIS7 made it much easier by allowing you to create a self-signed certificate and use this certificate for your SSL site. But there are still issues, for example TRUST. As soon as you are using self-signed certificates Internet Explorer will complain that it doesn't trust the certificate:

Firefox will do the same:

Establishing trust between your browser and your webserver
When a web browser like Firefox or Internet Explorer receive a SSL certificate from the server it usually checks the certificate for the following three things: 1. Is the certificate still valid or is it already expired? 2. Is the common name of the certificate the same as the user entered in the browsers address bar? 3. Does the browser trust the certificate or the issuer of thecertificate? Checking for #1 and #2 are pretty straightforward. For #1 the browser simply compares the current date with the expiration date of the certificate. The browser complains if the current date is already past the expiration date of the certificate. Checking #2 is easy, too. Compare the address entered in the address bar with the "common name" property in the certificate. If the name doesn't matchthe browser will complain. Checking for trust is a bit trickier. All browsers have a list of baked-in certificates (Trusted Root Certificates). The browser will complain if the SSL certificate IIS sends you is not a descendant from one of these Trusted

Root Certificates. Here is the list of Trusted Root Certificate Authorities" that Internet Explorer uses ("Tools" - "Internet Options" -"Content" - "Certificates" - select the "Trusted Root Certification Authorities" tab).

The problem with IIS7 self-signed certificates
IIS7 introduced a new feature which allows you to create a self-signed certificate that can be used for SSL. Problem is that it is a bit limited in what you can do with it. 1. The common name is always the machine name of your IIS server. 2. The certificate is onlyvalid for one week. 3. The certificate is not added to the "Trusted Root Certificate Authorities" of any browser. Not even on your local machine. You need to export the certificate to a file and import it back in so that it can be added to the "Trusted Root Certificate Authorities".

Here comes SelfSSL7!
SelfSSL.exe was a tool that we shipped as part of the IIS6 Resource Kit. By simply executingit you got the full monty:
• • •

a self-signed certificate with a configurable common name and a configurable expiration date an IIS SSL binding and SelfSSL also added the self-signed certificate to the "Trusted Root Certificate Authorities" list so that #3 didn't get in your way

SelfSSL still works if you have "IIS6 Management Compatibility". It was time however to rewrite this tool for...