Testing SSL/TLS in your development environment can be a pain.

I've generally used environment variable switching so that the secure layer is only required in production, i.e. different settings are applied depending on the current hostname.

Since IIS7 made it easy to create self-signed certificates, I've been trying to include some manual testing with SSL turned on in development. But this is cumbersome because you can only have one secure site bound to the machine's single IP address at a time. Host headers don't work because they are sent too late in the negotiation process.

Were I using IIS8, SNI would deal with the issue—but I'm not.

Assigning multiple IP addresses to my network adapter—as happens in production—would also solve the problem. But I develop on a laptop and frequently switch between wired and (multiple) wireless LANs and so can't rely on being able to use a pre-determined set of addresses.

Wildcard certificate

It turns out, however, that my assumption about host headers and SSL not mixing was only partially correct. After reading Using Host Headers and SSL in IIS 7 I am now aware that a wildcard certificate is able to support multiple sites bound to the same IP address (although I don't fully understand how).

Straightforward instructions can be found in that post, but if you are just creating a development/self-signed certificate environment it's even simpler. No need to fiddle with the MMC console unless you want to edit existing certificates.

1. In the IIS Manager root view, open Server Certificates.
2. Click Create Self-Signed Certificate... and enter *dev as the "friendly name". You can choose a different name if you prefer, but make sure it starts with an asterisk * and is the only certificate listed.
3. Once the certificate has been created, go to each site to which you want to add SSL and repeat the following:
   1. Click Edit Site > Bindings
   2. Add a new binding of type https to "all unassigned" ip addresses and choose the *dev certificate.
   3. Enter a domain name for the site into the host name box (which will have become editable)—for example siteA—and click OK.
   4. Add an entry to your hosts file so that the name will resolve locally, i.e. siteA 127.0.0.1

You should now be able to access each of your sites using https (after making a security exception according to your browser's requirements as normal).