Michael,
Your comment earlier :
I imagine the reason is a classic catch-22. nsvhr would look at the host header that the client sends to identify which virtual domain was being requested, but on an SSL connection the SSL handshaking/certificate exchange happens before the client sends any headers, and since the client verifies that the SSL certificate matches the host requested browsers will display warnings/errors when there is a mis-match. And the server would have no way to know which SSL certificate to send if you had multiple domains on a single IP. So in the end everyone is effectively stuck with one SSL host per IP address.
Your explanation sounds spot on to me. But is that one certificate per IP address or one certificate per domain name? I think that it should be fine to use a different keyfile and certfile with each running instance of AOLServer (i.e. on 8443, 8444, 8445) on any one machine/IP - the correct ssl negotiations should take place. It is the reverse proxy situation that is obviously problematic because if the proxy instance on AOLServer has to have its own key and certfile, it cannot authenticate on behalf of another AOLServer instance.
Cannot think of an easy way around that - kind of what ssl was designed to protect against!
Regards
Richard
