What exactly does "every SSL certificate requires a dedicated IP" mean?

Question

I've read a bit about SSL certificates, and in particular I've read that an SSL certificate "requires a dedicated IP address". Now, I'm unsure of the meaning of this; does it mean that the certificate requires a dedicated IP address separate from the IP address used for normal HTTP communication, or just that it can't share the IP address with other SSL certificates?

To clarify, I have a VPS with a dedicated IP address. The VPS is hosting quite a few different sites, including several subdomains of the main site, but only the main site and the subdomains requires SSL. Can I simply purchase an SSL certificate for *.example.com using my current IP address, or do I need to get one that is separate from the other sites on the VPS? Or even worse, do I need to get one that is separate from all HTTP traffic on the server? Keep in mind that none of the other sites needs SSL.

Thanks for any clarification on the topic.

---

Edit: Some sources for my worries:

http://symbiosis.bytemark.co.uk/docs/symbiosis.html#ch-ssl-hosting

Is it necessary to have dedicated IP Address to install SSL certificate?

Solution 1

1. There's no such thing as "SSL certificate". The term is misleading. X.509 certificates can be issued for different purposes (as defined by their Key Usage and Extended Key Usage "properties"), in particular for securing SSL/TLS sessions.

2. Certificates don't require anything in regards to sockets, addresses and ports as certificates are pure data.

3. When securing some connection with TLS, you usually use the certificate to authenticate the server (and sometimes the client). There's one server per IP/Port, so usually there's no problem for the server to choose what certificate to use.

   HTTPS is the exception — several different domain names can refer to one IP and the client (usually a browser) connects to the same server for different domain names. The domain name is passed to the server in the request, which goes after TLS handshake.

   Here's where the problem arises - the web server doesn't know which certificate to present. To address this a new extension has been added to TLS, named SNI (Server Name Indication). However, not all clients support it. So in general it's a good idea to have a dedicated server per IP/Port per domain. In other words, each domain, to which the client can connect using HTTPS, should have its own IP address (or different port, but that's not usual).

Solution 2

SSL certificates do not require a dedicated IP address. SSL certificates store a so called common name. Browser interpret this common name as the DNS name of the server they are talking to. If the common name does not match DNS name of the server that the browser is talking to, the browser will issue a warning.

You can get a so called wildcard certificate, that would be admissible for all hosts within a certain domain.

Solution 3

...following up on @Eugene's answer with more info about the compatibility issue...

According to this page from namecheap.com SNI does not work on:

• Windows XP + any version Internet Explorer (6,7,8,9)
• Internet Explorer 6 or earlier
• Safari on Windows XP
• BlackBerry Browser
• Windows Mobile up to 6.5
• Nokia Browser for Symbian at least on Series60
• Opera Mobile for Symbian at least on Series60

Web site will still be available via HTTPS, but a certificate mismatch error will appear.

Thus, as we enter 2016 I would venture to stick my neck out there and say, "If you're building a modern website anyway (not supporting old browsers), and if the project is so small that it cannot afford a dedicated IP address, you'll probably be fine relying on SNI." Of course, there are thousands of experts who would disagree with this, but we're talking about being practical, not perfect.

Comments

[Pacerier]

Wait, SNI is widely supported right? Why would each domain need its own IP?

[Eugene Mayevski 'Callback]

@Pacerier No, SNI is not as widely supported as it seems. Actually until '2014 TLS 1.1 was not widely supported at all, with many servers using old versions of OpenSSL which just crashed when the request included TLS 1.1 or 1.2. Also the referenced answer mentions browser support and forgets that there exist plenty of HTTPS clients which are not browsers (IIRC browsers are minority of all HTTPS clients). Finally, if you read my answer, I've written "not all clients support it". If you don't care about compatibility - no problems.

[Pacerier]

You stated that SNI is to fix the problem that "the web server doesn't know which certificate to present". Doesn't this mean that SNI must be sent before the TLS handshake as opposed to after it?

[Eugene Mayevski 'Callback]

@Pacerier The TLS handshake consists of several steps, and SNI is sent during a handshake.

[Pacerier]

Then couldn't a MITM sniff out the SNI and know which domain you are visiting?

[Eugene Mayevski 'Callback]

@Pacerier You are welcome to read the TLS specification to learn the details of the handshake. The domain to which the client is connected can be learned from the certificate presented by the server anyway, so this is not the top secret.