Wandering Thoughts archives

A trick to testing https setups on test machines

Suppose that you are building a new version of an existing machine that runs a https web server (perhaps you are rebuilding it under a different base OS version). Of course you want to test it before you switch it into production, which means that it needs a new temporary name of some sort. And a different name means problems with the SSL certificates for your https web server instances.

(There are people who will tell you, in all seriousness, that you should have a completely independent, isolated test network so that you can give your new machine the exact same name and IP address as it will have in production. These people either have very simple systems or have much, much larger budgets than I have ever been near.)

It turns out that there is a way to get around these problems: the SSL certificate validation process only cares about what the client sees as the IP address for the certificate's hostname, not what the server thinks it is. As long as your test client machines will resolve 'prod.yourco.com' or the like to a suitable IP address on your new machine, your new machine can carry the real SSL certificates that will be used in production, clients can be tested using the official name, and no one will get any certificate errors.

There are various ways to do this depending on what the client machines are running; on Unix, you can just edit /etc/hosts and then make sure it's consulted before DNS. I believe that other operating systems have similar features.

(Although it's a tempting hack, I personally think that building your own DNS server to return carefully crafted answers to your test machines is perhaps going a bit too far.)

The same trick generalizes to other SSL-protected protocols such as the various forms of SSL'ized IMAP, and may be even more handy there (where common clients may not actually give you any way to override certificate problems). It even works for ssh, in case you have an automated ssh-using system that you need to test.

(The in a nutshell version of why it works this way for SSL is simple: no one wants to pay certificate vendors yet more money every time they change the IP address (or, for large places, addresses) of their web servers.)

One can also take advantage of this to commit some interesting hacks with various forms of split-horizon DNS resolution, where the same nominal name can go to different machines that all carry the same SSL certificate but behave quite differently.