Virtual machines are a much cleaner and nicer way to do this. Setting up a wildcard SSL is similarly as simple, an you get the bonus of learning how to do it on a "real" (normal, more standard) server.
Example setting up wildcard subdomain SSL cert (self-signed): https://serversforhackers.com/ssl-certs/
"Well, client X still uses PG 9.1, but I accidentally used a 9.3 feature, because thats what client Y uses."
Besides, I don't understand why you would choose not to trust the certificate, then click it and choose to trust it...
Makes it easy to develop from any machine, and even allows me to check it out from other machines. Including things like browserling.
On top of that, it can record and replay requests for you as you debug.
http://bens.me.uk/2013/multicast-dns-and-development-virtual...
This is especially useful as my application is multi-tenant, where you can potentially use lots of different hostnames.
I'm wary of trusting a development certificate on my development machines. One slight misconfiguration, and you've got a CA with a well-known private key which can be used to generate certificates for any name. Which would be very useful for MITMing a rather important machine.
I accept the inconvenience of having to click through the warnings, with conscious awareness of what I'm doing to avoid training myself to ignore them. I'm not entirely sure which is the bigger risk.
I also wish glibc had something similar.
I've put Apache with a wildcard cert (& local CA) in front of it to handle SSL termination.
It's very similar to the technique from the article, but I've found the ability to serve requests on the default port to be convenient.
