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 seemingly simple 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
- Install the 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.
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 web server
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:
- Is the certificate still valid or is it already expired?
- Is the common name of the certificate the same as the user entered in the browsers address bar?
- Does the browser trust the certificate or the issuer of the certificate?
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 match the 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.
- The common name is always the machine name of your IIS server.
- The certificate is only valid for one week.
- 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".
SelfSSL.exe was a tool that we shipped as part of the IIS6 Resource Kit. By simply executing it 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 IIS7 and to add some features to it.
SelfSSL7 creates self-signed certificates with
- one or more configurable common name
- a configurable expiration date
- a configurable key size
SelfSSL7 also allows you to add a SSL bindings in IIS. Configurable are
- the site name SSL is to be configured on
- the IP address
- the port
When the /T parameter is specified the self-signed certificate is added to the "Trusted Root Certificate Authorities" of the current user which will make the certificate trusted and Internet Explorer won't complain anymore.
And best of all: SelfSSL7 has intelligent defaults, i.e. you only have to enter SELFSSL7.EXE and it will do the work for you to set up a fully functioning SSL for your local IIS7 machine.
SelfSSL7 can also export the self-signed certificate to a password protected PFX file. This allows you to import the certificate on another machine which then can also trust the self-signed certificate.
Examples and Usage
- Let's start with the command-line help by entering "SELFSSL7.EXE /?":
- Configure SSL on the local machine and make the SSL certificate trusted for the local user:
Defaults are used to configure the IIS binding and make the certificate trusted in the user's root certificate authorities store. With this you should be able to enter https://<machinename> without getting a certificate warning.
- Configure new SSL certificate that also works for https://localhost. Overwrite IIS binding that we configured in 2)
/Q to overwrite existing IIS SSL bindings
/T to add the certificate also to the user's certificate store so the SSL certificate is trusted by IE
/I to add an IIS binding
/S specifies the site we want to use to add the binding
/N specifies two common names: IIS7BRICK is my machine name and LOCALHOST is the local loopback adapter name
You should be able to browse to https://localhost and https://<machinename> without getting security warnings from Internet Explorer. If you click the the little lock at the right side of Internet Explorer's address bar
you can find the properties of the certificate we just created, e.g. the validity dates, the common names and the key size (1024 Bit).
- Let's now create a certificate with different properties using a stronger key size (/K 2048) and a longer validity date (/V 1000 = 1000 days).
If you look at the certificate properties you can see the differences:
- As a last step lets also export the certificate we are creating. This can be useful if you want to avoid the security warnings also on other machines. The only thing you have to do is to import the exported certificate into your other machines "Current User"-"Trusted Root Certification Authorities" store. You do this by simply double-clicking the PFX file you get after this step.
With SelfSSL7.exe it becomes extremely simple to set up a SSL site. There are several command-line options that allow you to customize the SSL experience. However, due to the smart defaults you are able to run SELFSSL7.EXE without any parameters and get a fully functioning SSL site.