Thanks for your replies, but I'm still unclear about this. (Sorry, just trying to get this crystal clear for myself - I really don't want to be a pain in the ass or something

)
kaisellgren wrote:I'm not sure anymore what do you want. If you want to have a private SSL certificate without having a dedicated IP for it, then you can forget it.
I'm aware of that, I have no illusions that I can break the rule - just want to understand why
Let's take a step back here - for all I know, we use https:// for two reasons:
1. Encryption (data protection), so we know nobody can be snoopin' in-between and peek at the data (or even change it, acting as a middle man).
2. Authentication (identity assurance), so we know that the company or people we're visiting are who they say they are.
If I understand correctly, the server has some private (internal) key, and sends a corresponding public key to the visitor. This is for purpose 1. For purpose 2, the identity that is bound to this key is verified and authenticated by a trusted, official issuer (e.g. Verisign and the likes).
kaisellgren wrote:What ever you do as a web hosting company, you can not change the way SSL works. Try generating a CSR and get an issuer to verify it and then switch the server IP or switch your domain name, either way you have to regenerate your CSR and certificate.
Does this mean that if I move to another hosting provider, I will need to purchase new certificates for all my sites?
Prior to the private key generation the dedicated IP is needed. This is a technical fact of private key creation. It is also needed for the issuer, issuers can not trust you if you change your IP or domain name.
If I remember correctly, I only specify a domain name when purchasing a certificate... Or is the IP enclosed in the CSR?
Also, SSL requires a dedicated IP, because name-based hosting does not support data encryption in HTTP requests.
How do you mean, name-based hosting? Shared servers which serve multiple domain names? How does that rule out the possibility of encrypted requests? Isn't a tunnel created for each connection, prior to exchanging keys?
The fourth reason is Defense in Depth.
How does that apply here, or how does this enforce the necessity of a dedicated IP?