Hello all Pardon me for being dense.
Also, I haven't searched the archives on this subject, the archive search page was down, so I hope I am not starting a flame by rehashing what I suspect could be a rather heated topic. I am not convinced by the argument that name based SSL virtual hosting is impossible. Yes. I understand that in order to understand your ssl configuration you need to pick a virtual host context. Since you don't have the hostname the server was requested as at the time of the SSL negotiation, you end up falling through to the default SSL host. However, this seems like an artifact of the config file data data organization and/or an apache implementation limitation, rather than a limitation on the protocol itself. For example: Suppose I wanted to mangle apache into doing something like name virtual hosting for SSL enabled clients. Here is how I envision this being possible: - Tell apache to listen on a new port (say, 444). - For the default first host on port 443, I create a script, which reads the http Host: header and then issues the exact same request on port 444 of the machine and echo's the output. - Now create name based virtual host definitions for port 444 anywhere you would like to have name based SSL virtual hosts. Granted, there are some pretty serious limitations with this design. For example: -you would probably only want port 444 available from local interfaces (which can be enforced with a firewall). -you can't create access rules based on ip address or ssl status from within apache. -You need to filter the response headers to keep up the facade, as it were. (for example, making sure you filter redirects to redirect to the proxy script and not what the virtual host thinks it is). -the named based virtual SSL hosts would effectively all have the same SSL certificate. This, however, can be dealt effectively and completely with the SubjectAltName field of the server cert. -numerous other issues with the documents you are serving being shown a different port number than is actually being served. This would have the effect that people are looking for. One ssl enabled host, which presents a different DocumentRoot based on the Host: http header. The code to do this would only be a few hundred lines in php or perl, if you rely on an already existing http request class. However, I don't see why this couldn't be implemented in apache, and remove all the limitations I mentioned above, except for the need for a certificate with a subjectAltName. For example, suppose you have a second name virtual host style configuration directive that looked something like: <SSLNameVirtualHost *:443> /all ssl options here/ </SSLNameVirtualHost> Then, instead of picking a virtual host definition in order to be able to negotiate the SSL session, the SSLNameVirtualHost statement would have all that it needed to negotiate the SSL session, then, after the SSL session is negotiated, the virtual host definitions could be consulted for a suitable virtual host to serve to the client. This would allow the virtual host to define access controls again. This would also mean that it would be impossible to specify SSL options in a particular virtual SSL host definition, but I would certainly be willing to accept that limitation, especially compared to our choices now (and I bet others would as well). In fact, the fact that the ssl negotiation parameters have to be the same for all the name virtual hosts would be the only significant limitation. And because you can use subjectAltName to specify alternate hostnames in a SSL certificate will almost completely mitigate this limitation for most people. Is there any reason why this can't be implemented in apache? Again, to be clear, I made name based virtual ssl hosts work. The documentation says this is impossible. It is not. It would, however, work worlds better if implemented from within apache. -- Daniel Rogers [EMAIL PROTECTED]
