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
(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.