Working with software developers, I’ve probably seen SelfSSL used more often than in most lines of work, and also misuse of it. The purpose of this article is to draw some boxes around the different areas that come in to play when a site is self-certified.
Most obviously, the user requests the page through the browser, but the browser also warns of Certificate/DNS name mismatches. Unless the certificate was issued to the address through which the site is being browsed, the browser will produce certification warnings. This behaviour is expected and desirable as part of browser security.
The browser also verifies that the certificate is trusted. One of the most frequent problems with SelfSSL is that the certificate does not get installed properly. There are a few ways that this can be approached, but the easiest way (given that SelfSSL should only be used for testing) is to install the certificate in to the automatically selected location, or in the Trusted Root Certificate Authorities store if that should fail (obviously this isn’t something you’d normally recommend, but since you issued the certificate yourself, there isn’t much risk). This can be installed manually through the Certificates MMC in Administrative Tools or in response to errors in the browser on the first visit to the newly-certified site. If installing through the browser, the certificate errors will not go away until after all instances of the browser have been closed and re-opened.
Last but not least, the browser decrypts communication using the private key stored in the trusted certificate.
If a test environment requires multiple self-certified sites, these sites will need to have new certificates issued to unique port/IP address pairs (this is fundamental to how SSL works). By default, one would use <IPAddress>:443. A second could be issued on <IPAddress>:444, etc, but it is often more desirable to issue additional certificates on port 443 as well.
I’m always amazed at how many people don’t know that a single NIC can have multiple IP addresses, in the same or different ranges. When planning self-certified sites, always keep in mind the number of addresses that will be needed, don’t forget to add them to the NIC, and make sure that the HOSTS file or DNS is updated accordingly.
The Application Server uses the certificate assigned through the site security settings (or via the SelfSSL command) to assign a public key for encryption and a private key for decryption. Put more simply, IIS establishes the relationship between site and certificate.
As mentioned earlier, IIS binds SSL traffic to a single port-per-IP-address. If use of the default SSL port (443) is desirable for multiple sites, each site must be assigned a specific IP address in IIS and the DNS or HOSTS file settings must resolve the host name to that IP address. It’s worth repeating that the browser will warn of any mismatches between the certificate’s address and the URL through which the site is browsed.
SelfSSL is a free command-line tool in the Windows Server 2003 IIS ResKit. SelfSSL is like a local CA for issuing a single certificate per-IIS instance. However, it does not take the place of a proper domain or Trusted Root CA, as the certificate needs to be manually installed on the end user’s machine (see Browser comments above), and it can only issue a single certificate.
In order to get around this limitation, we can issue a wildcard certificate (*.domainname.com) that can be exported from the first site it is created on and imported to other sites with the same domain name. See the notes above about running multiple sites on SSL in the NIC/DNS and IIS sections.
NOT FOR PRODUCTION
I would like to think that I needn’t issue any further reminders about using SelfSSL in production, but I’ll say it anyway. If all of this wasn’t persuasive, then please remember that every user of the site will need to manually install the certificate. Try and talk someone through this over the phone, multiply the time it takes by ten and then go buy yourself that immeasurably cheaper certificate.