It looks like this is possible, provided all the required pieces of the puzzle are in place.
According to the Tech Republic article Configure Apache to support multiple SSL sites on a single IP address recent versions of Apache and OpenSSL support the SNI (Server Name Indication) extension to the SSL protocol - however you'll need to be happy that your users are also on more modern browsers (as there's no support for this from IE7 on Vista machines, nor from Safari 3.2.1 before OS X 10.5.6 - Chrome and Firefox should be OK these days).
In terms of server-side configuration you need to be running:
- Apache 2.2.12 or higher.
- OpenSSL 0.9.8f or later and must be built with the TLS extensions option.
- Apache must be built against this version of OpenSSL as it will enable SNI support if it detects the right version of OpenSSL — the version of OpenSSL that includes TLS extension support.
You can then configure Apache as follows:
Listen 443
NameVirtualHost *:443
SSLStrictSNIVHostCheck off
<VirtualHost *:443>
DocumentRoot /srv/www/example1.com/
ServerName www.example1.com
...
</VirtualHost>
<VirtualHost *:443>
DocumentRoot /srv/www/example2.com/
ServerName www.example2.com
...
</VirtualHost>
This tells Apache to listening to port 443 for virtual host requests on all IPs. The new keyword SSLStrictSNIVHostCheck is disabled, meaning we will not throw a 403 error if the client does not support SNI; instead, they will be redirected to the SSL site defined first (example1.com in the example), so be sure to define your default site first.
You've already ruled out the best option: which is to add a second network adaptor and IP address to the server and bind the second SSL site to that IP address (so you have the standard 1 to 1 mapping of IP and SSL).
A final option that I've seen in the past is to have the SSL certificates reside on a firewall/load-balancer, so the requests are decrypted there, and are then sent unencrypted to the appropriate web server and the response is then encrypted on the way back to the browser - this is effectively putting the firewall as a "man in the middle" proxy, which will may be an issue for your company, and the sort of kit that supports this ("Layer 7" I believe) tended to be fairly expensive - and I believe we had multiple IP addresses on the load-balancer to support this anyway.
One example of a public facing website I worked on had two different CMS systems running in parallel on different servers, but both needed to be able to serve some content under SSL without using a different URL (for logging in, user profiles, etc.) so the load-balancer needed to be able to decrypt the request to work out which CMS to send the request to, and do so.