Is it possible to use only 1 SSL certificate across 4 Virtual Machines?

Question

First of all, I'm not handling the servers. My employers are Japanese but my manager can speak English and he want us to research about the possibility of the setup they are thinking.

So the way he explained it, they have one machine connected to the internet. In that machine there are four Virtual Machines (Windows 2008 server). They want to know if the SSL certificate hosted on the host machine can be used by the four VMs. I'm not sure how they envisioned the setup, but as far as I know there should be a separate SSL certificate for each VM.

I just want to know if it's possible or if there's a solution for a setup like this (4 machine 1 SSL) that can work.

Answer 1

It is possible if you have an additional machine responsible for terminating the SSL connection and proxying the traffic from those 4 machines to the internet. Now do note that the traffic between the proxy and the virtual machines will not be encrypted. This is called an SSL termination proxy.

Answer 2

I think you need to have a better understanding of what SSL is for and how it works.

SSL implements several security functions among which these are the ones that matter to you:

• Encryption of data in transit.
• Authentication of one or both ends of the connection.

(there are other functionalities, like compression or secure key negotiation, but you don't really care about these).

The part that is going to cause you trouble is the second one: authentication. More specifically, the server side of the authentication (in other words, how does the client certify that he is talking to the "right" server).

For this, SSL relies of two things: an X509 certificate and the DNS system. It does it through the following steps:

1. It uses the host name (e.g. www.mysecureservice.com) provided by the user or application to get an IP address through the client's DNS resolution.
2. It opens a TCP connection to that server and requests the remote machine's X509 certificate (in practice, there are usually more than one cert provided but let's assume there is only one for simplicity).
3. It verify the authenticity of the certificate. For this, it uses it's own internal rules (since it's not too important right now, and quite complex, I won't elaborate on exactly how).
4. It verify that the name inside the X509 certificate it received from the server is the same as the host name it used in step 1 for finding out the IP address.

If the host name doesn't match, the SSL connection will not be validated. Depending on what software is using the connection, it can trigger a simple security warning or fail the connection altogether.

Another mechanism that you should be aware of is that establishing an SSL connection is expensive in CPU and bandwidth so SSL connections typically are held for a rather long time. Also, there is a "strong binding" between the client and the server which makes it (almost) impossible for a client to change server once it has established the SSL connection without completely breaking it and restarting from scratch. This is not really an issue with statefull protocols because there is more state elements that must be maintained on the server anyway but for stateless protocols (like HTTP) it means that establishing an SSL connection can break load balancing.

Now, to your question directly.

First thing first: you can't "Share" an X509 certificate between the host and guest OS since the certificate is "installed" directly on the machine. However, what you can technically do is any of the following:

• Install the same certificate (with the same host name) on all the VMs and then use DNS round-robin or any other type of network load balancing to redirect users to one VM of the other. That, of course, assumes that all VMs are interchangeable.
• Install a reverse proxy server on the host (not recommended), in another VM or on another device in front of your host (the best solution). That reverse proxy will receive the SSL connection, decrypt it and the proxy the query to one of the VMs based on whatever rule you've setup. This will, however, (almost) only work if what you want to offer over the SSL connection is HTTP content and also requires the back-end system to be compatible with this scheme.
• Setup a so-called "SSL VPN" on the host (again, not recommended), another guest VM or some device in front of the whole thing. This type of setup is more complex because it all depends on what protocol you want to encapsulate inside the SSL connection and what usage scenario you're expecting.

If that explanation is not sufficient, could you please clarify exactly what you want to protect by SSL encapsulation ?

Answer 3

Your question is a bit vague, since you are not specifying what you want to achieve.

If you are talking about HTTP, this would be possible in a load-balanced setup, where every server uses the same hostname (through a load balancer). This is common and you install the same certificate on each and every server (remember that you can not re-issue the certificate for each server!). However, I don't really see the gain here, why would you virtualize 4 machines, on the same physical machine, and then load balance the traffic on them?

You second option is to use a special SSL certificate, a "wildcard" certificate which would be issued to *.yourdomain.com which would be considered valid for any sub host to your domain. It cost a lot more, and paranoid people might not consider it to be as trustworthy as an "fixed" SSL certificate. I personally use this for internal services where I don't really care, and I just want to get rid of warnings.

This might be of interest for you: Can you re-use a SSL certificate across platforms?

Remember that different SSL certificates has different licensing models. Some are "per server", and some are "per domain", or "unlimited servers". Read the fine print.