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:
- 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.
- 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).
- 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).
- 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 ?