I think it is a good idea how to explain what the problem really is with virtual hosts and SSL/TLS.
When you connect to an apache server over HTTP you send a set of http headers along. They look like this:
GET /index.html HTTP/1.1
Host: www.nice-puppies.com
If you have virtual hosting apache will look at the hosts field, then fetch the right index.html for you. The problem is when you add SSL/TLS. The server sets up the encryption before you ever send your http request. Therefor the server doesn't know if you are going to www.nice-puppies.com or www.evil-haxxor.com until after the authentication/encryption is completed. The server can not guess (as sending the wrong certificate gives you a nasty error message).
One solution is a wildcard certificate (as mentioned above), which is valid for *.nice-puppies.com. That way you can use the same cert for multiple domains, but you can't have a *.com certificate (okay, you can, but it would be very bad for everybody else), so in general you will need separate IP for each HTTPS domain.
It's only starting to be rolled out into servers and web clients, so it's not really something you can use now, but hopefully in a few years' time this won't be as big of a problem.
The problem is that the SSL certificate is bound to the IP address not hostname. When the connection comes in on the IP address for an HTTPS request the first action is to establish the SSL communication by passing the server certificate and/or client certificate. During this stage of the connection handshake the Apache server has no way of knowing what the request about to come through is for. This is different for HTTP (non-SSL) traffic as after the connection is established the Apache server can determine the virtual host configuration to use if the client sends the Host header or else it hands it off to the first virtual host configured.
If you had multiple virtual hosts under the same domain you could setup a single wildcard certificate on the IP address and have multiple virtual hosts with different server names defined; however, if those server names are not under the same domain name they would generate client server errors. This would work as the wildcard certificate would be valid for all host names under that domain name. You would need another IP address if the domain names were different as the first certificate defined for that IP address would be the one presented for connecting clients.
This can be added into one single ssl certificate as SAN (Subject Alternative Name). In my excperiance i had to request a organisation sll certificate. i used globalsign.
I have yet to use this myself, but it sounds good for internal and intranet sites. Most modern browsers support SNI. IE6 does not support SNI, but IE7 does.
I am working on same issue. As my test, IE7 and later (Only in Win7 & Vista)/Chrome/Firefox/Safari/Opera support "Server Name Indication". In fact, if browser uses Tsl 1.0, It supports "Server Name Indication".
If you will try to add two certificates on the same IP, only first read certificate will be used everywhere. One IP - one SSL certificate.
If you want to get more SSL certificates on the same IP, consider getting multiple-domain (so called UCC - check it out @ godaddy) or wildcard (more expensive) certificate.
I think that the OP is asking what happens if he adds an SSL cert to an IP that has many virtual hosts. If none of the other virtualhosts use an SSL cert then he should be in the clear.
I think it is a good idea how to explain what the problem really is with virtual hosts and SSL/TLS.
When you connect to an apache server over HTTP you send a set of http headers along. They look like this:
If you have virtual hosting apache will look at the hosts field, then fetch the right index.html for you. The problem is when you add SSL/TLS. The server sets up the encryption before you ever send your http request. Therefor the server doesn't know if you are going to www.nice-puppies.com or www.evil-haxxor.com until after the authentication/encryption is completed. The server can not guess (as sending the wrong certificate gives you a nasty error message).
One solution is a wildcard certificate (as mentioned above), which is valid for *.nice-puppies.com. That way you can use the same cert for multiple domains, but you can't have a *.com certificate (okay, you can, but it would be very bad for everybody else), so in general you will need separate IP for each HTTPS domain.
The real solution to this problem is "Server Name Indication":
http://en.wikipedia.org/wiki/Server_Name_Indication
It's only starting to be rolled out into servers and web clients, so it's not really something you can use now, but hopefully in a few years' time this won't be as big of a problem.
The problem is that the SSL certificate is bound to the IP address not hostname. When the connection comes in on the IP address for an HTTPS request the first action is to establish the SSL communication by passing the server certificate and/or client certificate. During this stage of the connection handshake the Apache server has no way of knowing what the request about to come through is for. This is different for HTTP (non-SSL) traffic as after the connection is established the Apache server can determine the virtual host configuration to use if the client sends the
Hostheader or else it hands it off to the first virtual host configured.If you had multiple virtual hosts under the same domain you could setup a single wildcard certificate on the IP address and have multiple virtual hosts with different server names defined; however, if those server names are not under the same domain name they would generate client server errors. This would work as the wildcard certificate would be valid for all host names under that domain name. You would need another IP address if the domain names were different as the first certificate defined for that IP address would be the one presented for connecting clients.
This can be added into one single ssl certificate as SAN (Subject Alternative Name). In my excperiance i had to request a organisation sll certificate. i used globalsign.
Actually, with modern software you CAN serve multiple HTTPS sites over a single IP address, using a new feature called 'SNI - Server Name Indication'.
http://en.wikipedia.org/wiki/Server_Name_Indication
http://wiki.apache.org/httpd/NameBasedSSLVHostsWithSNI
I have yet to use this myself, but it sounds good for internal and intranet sites. Most modern browsers support SNI. IE6 does not support SNI, but IE7 does.
(Correction: 20100426 -- SNI is not supported on Windows XP at all. Windows Vista and above do support SNI. See "Section 2.2.3" at http://msdn.microsoft.com/en-us/library/dd208005%28v=PROT.13%29.aspx#id8 ).
I am working on same issue. As my test, IE7 and later (Only in Win7 & Vista)/Chrome/Firefox/Safari/Opera support "Server Name Indication". In fact, if browser uses Tsl 1.0, It supports "Server Name Indication".
If you will try to add two certificates on the same IP, only first read certificate will be used everywhere. One IP - one SSL certificate.
If you want to get more SSL certificates on the same IP, consider getting multiple-domain (so called UCC - check it out @ godaddy) or wildcard (more expensive) certificate.
I think that the OP is asking what happens if he adds an SSL cert to an IP that has many virtual hosts. If none of the other virtualhosts use an SSL cert then he should be in the clear.
A UC certificate is definitely the way to go: http://www.sslshopper.com/unified-communications-uc-ssl-certificates.html