> Krist explained it very nicely... But maybe you still didn't get it: > Without SNI, there is NO WAY TO DO THIS. It is a fundamental limitation of > the HTTPS protocol with no production-grade work-around. SNI (server-name > indication) was specifically added to address this limitation. There is > simply NO ALTERNATIVE.
To back up a moment, though -- another way to do this is to define multiple IPs on the network card and run multiple instances of apache, each with different config files. We run 20 or more on some of our production servers. > Having said that, if you have a research or academic environment and don't > care about browser warnings, you can just use the same cert for all sites. > You will get the encryption aspect of HTTPS but not the authentication > aspect. Some people get awfully upset when they see browser warnings, though. > Alternatively, if all sites have the same domain-name (eg, > sales.wibble.com, shop.wibble.com etc), you can get a wildcard cert that > certifies *.wibble.com. > > Aside from these special cases, there is NO WAY to have name-based SSL > VHs. But I wonder if name-based SSL VHs really are a necessity. The OP has a Linux box. If he has additional IPs the problem can be taken care of without virtual hosts. And, having done it both way in a group that supports multiple departments, it saves a lot of headaches trying to schedule upgrades, configuration changes, or even just restarts to clear a problem. But it all depends on the environment. Sheryl --------------------------------------------------------------------- The official User-To-User support forum of the Apache HTTP Server Project. See <URL:http://httpd.apache.org/userslist.html> for more info. To unsubscribe, e-mail: users-unsubscr...@httpd.apache.org " from the digest: users-digest-unsubscr...@httpd.apache.org For additional commands, e-mail: users-h...@httpd.apache.org
