Tim:
If the numerical IP address of your service is shared between yourselves and others, whether that's because your IP can change at different logins, or other's use it simultaneously (such as webserver hosts that service many clients on the same numerical IP), you're not going to get the host to point their reverse DNS look-up to your domain name. You need a permanently unique IP to be able to do that. The same situation applies for HTTPS and certificates (you need to be the sole user of your IP).
Samuel Sieb:
This hasn't been true for a long time. I don't remember the acronym, but you can have an unlimited number of website hostnames on the same IP address that all have their own unique certificates.
"SNI"? RFC'd in 2003, and still not supported by all browsers, but appears to be by all the major web server software.
I was under the impression that /that/ problem was unsolveable. Due to both web client and server first trying to connect *before* requesting the hostname, therefore it wasn't possible to provide a certificate for the right host. Of course if the HTTPS protocols have changed, but it appears not, just an addition has been made:
SNI put the requested domain name into the client's TLS negotiation, so the server can provide the right site's certificate.
The requested hostname is not encrypted, so it can be spied upon. Experiments are afoot to encrypt this, too, but only very recently (last year).
In most cases, it probably doesn't matter that some third party could find out you wanted to connect to a particular website (which used to be hidden with the old way of doing HTTPS, although they still knew the IP you were connecting to, and could see what DNS lookup you'd done just prior). But it can be used for surveillance and censorship.