Darwinweb

Localhosting Multiple SSL Domains on Mac OS X

January 13, 2007     

Localhosting is big part of why I chose Mac OS X for web development. Apache comes installed and is generally quite similar to industry-standard hosting setups on Linux, BSD or Solaris. This means that I can perform entire development cycles locally. Over the years I’ve steadily enhanced my localhosting setup; first with the basics such as virtual hosts and MySQL, later by adding GD support to PHP and SSL to Apache.

Having SSL installed locally has turned out to be huge. A lot of web apps won’t work without SSL. I’ve been hobbling along using mod_rewrite to provide shared SSL support my localhosting needs. mod_rewrite can take you far in this endeavor, but isn’t quite powerful enough to get the job done for otherwise excellent software.

/etc/hosts on Mac OS X 10.4

Although tangential to the topic of SSL certificates, I’ve discovered a lot of conflicted information about use of the /etc/hosts file on Mac OS X. For developing sites locally (or ad-blocking) creating local domains is indispensable. Early versions of OS X did not use the /etc/hosts file unless explicitly configured to do so. However as of 10.4 (at least) /etc/hosts is a first-class citizen like in other unices; the only possible conflict arises from DNS caching. To get the system to honor new changes to /etc/hosts all that is necessary is to run the command:


lookupd -flushcache

All the NetInfo crap you see when you search on this topic is totally unnecessary (at least under the latest version of OS X—unless I made some configuration changes that I’ve since forgotten).

SSL Requires a Unique IP

Although Apache is master of name-based virtual hosting, SSL requires a unique IP for each certificate. So to install additional certificates you need more than one IP at your disposal. Unless you are setting up Apache on a server that already has multiple dedicated IPs this presents a bit of a conundrum. The trick is to set up additional loopback IP addresses within your system. By default 127.0.0.1 is the loopback address, but defining additional loopback addresses is easy. I picked this tip up from Damon Parker’s blog:


sudo ifconfig lo0 alias 127.0.0.2 netmask 255.255.0.0

You can define as many additional loopback addresses as you need this way. Once you have those setup it’s just a matter of creating more certificates and adding VirtualHosts to your httpd.conf.

Creating and Installing Additional Certificates

If you followed the Apple’s directions then you already have half the work done. Just reuse the Certificate Authority that you created for the first certificate. To create another certificate choose a unique name for the new files. For instance, instead of server.key just create server_localdomain.key so the filenames don’t conflict. That way you can install all the certificates in the same directory. I suppose it also works to keep the same name but install them in individual subdirectories (I haven’t tried it). The steps to follow from the tutorial are:

  1. Create certificate
  2. Create CSR (certificate signing request)
  3. Skip CA (certificate authority) creation
  4. Sign certificate using sign.sh script
  5. Copy the new files (certificate, key, and csr) to /etc/httpd/ssl.key
  6. Decrypt key so startup works
  7. Duplicate the Apache VirtualHost for 127.0.0.1:443 and change the relevant values (probably VirtualHost, ServerName, DocumentRoot, SSLCertificateFile, SSLCertificateKeyFile)
  8. Restart Apache

Now profit!

molaro says…
March 15, 2011 at 1:22AM

Great instructions. They worked great. Simple and straight forward. One quick question, should I need to re-issue the ifconfig command to setup a loopback address each time I restart?

I ask because I just ran a Mac OSX system update (iTunes, Safari, and Java) which required a reboot. After the install, my regular custom addresses work, but neither of my secure addresses worked (on 127.0.0.1 and 127.0.0.2). I rebooted again and still nothing. I then re-issued the ifconfig command and they seem to work again.

If that is correct behavior, what is the best way to make that “permanent”? a start up script?

Gabe da Silveira says…
March 15, 2011 at 7:45AM

Yes, you will need to issue it on restart. I rarely restart, so it was just one of many things I might need to type into my terminal once a month or so. If you want to make it permanent, look into launchd.