Local development with OSX Yosemite

Immediately after upgrading I noticed my local instance of Apache wasn’t working.

I expected this.

In this post we’ll briefly look at some updated configurations for Apache to let you keep using dynamic vhosts, explore the source of Chromium, and get wildcard SSL certificates working. If you’re looking to get started with Apache and Dnsmasq on OSX, my previous post still applies.

Updating Apache

You’ll notice that Apple upgraded the built in version of apache to 2.4.9, httpd -version. This is pretty great, but some of our previous configurations need to be changed.

If you’ve setup Apache previously, check the Console application for what might be happening. I’ve included my updated configurations for both HTTP and HTTPS connections.

You’ll need to restart Apache for these to take effect, remembering to change {USERNAME} to your username.

Updating SSL

I didn’t want to have to click past Chrome’s nice, but tiresome, warning each time I wanted to use HTTPS for one of my local development sites.

My previously generated certificate was good for anything under the .dev domain, *.dev. Easy, but not acceptable.

Chromium kindly gives us easy access to their source, and by looking at x509_certificate.cc we can get a better understanding of what’s going on.

This essentially boils down not allowing wildcards at the first level to prevent too broad of a match. If you’d like to know more about the logic behind this, the RFC about PKIX and TLS is a great resource.

Knowing that Chrome won’t accept a first-level wild card certificate, I created (self-signed) another, with the domain set at *.ssl.dev. Make sure to add another line to your Dnsmasq configuration to ensure these new domains resolve correctly, address=/.ssl.dev/127.0.0.1. If you’re following the pattern for adding vhosts outlined previously, create a symlink to the folder you want to server over HTTPS, ln -s ~/sites/test.dev ~/sites/test.ssl.dev.

Additionally, you’ll want to add the certificate to your login keychain, and setting the appropriate trust levels.

At the end, you should be able to visit your test domains, and see a correctly trusted connection!