Nishaliny Thurairatnam wrote:
Hi,
I've been tearing my hair out over this for quite some time now...
Stop doing that, because you will have no hair left before you find a
solution.
so,
this is the scenario:
I have 2 different virtual hosts, both with different server name's and
aliases, naturally with different sets of SSL certificates. My problem
is, no matter how I try to arrange them, one virtual host settings
ALWAYS takes precedence over the other. I don't want it to take
precedence, I want them both to be read as equals, meaning if I want to
access <VirtualHost1>, then I should access <VirtualHost1>, regardless
of whether <VirtualHostA1> takes precedence.
You see, the problem when it takes precedence is that, when I access my
web page on the browser for the Vhost that has lower precedence, the SSL
certificates for this host is matched incorrectly. It refers to the
certificates defined in the Vhost with higher precedence. It's truly
frustrating :-(
Please, if anyone could shed some light as to how I can resolve
this....I'd appreciate it very much... and please, if I'm doing
something wrong, feel free to let me know...I'm no 'guru' and I don't
claim to know the universe :-)
I think you are trying to do something that is currently not possible :
combine name-based virtual hosts with SSL.
The base of name-based virtual hosting is this :
A) When the browser sends a request over HTTP, it sends :
Line 1 : the requested URI :
GET /something HTTP/1.1
Line 2 :
Host: myhost.company.com
(then further header lines and body)
B) when the server receives this request, it parses the request *and*
the header lines, among which the "Host:" header line.
That is what tells the server *which virtual host* is supposed to handle
this request.
The server then goes on to compare this hostname, with the "ServerName"
of each <VirtualHost> section.
If it finds a match, then it handles the request using the configuration
of the matching <VirtualHost> section.
If it does not find a match, then it handles this request using the
configuration of the *first* <VirtualHost> section, because this is the
*default* virtual host.
Ok so far ?
(This is all explained pretty well in the on-line Virtual Hosts
documentation).
Now, the problem with SSL, is that everything is encrypted, even the
very first browser request. And to decrypt it, the server needs the
decryption key.
But it can only have this decryption key, when it knows to which host
this request is addressed, because the key is specific to the host.
So it can never decrypt the request (including the HTTP headers, and
particularly the "Host:" header) in advance.
So we have a chicken-end-egg situation.
The underlying problem is that the SSL communication channel is
something that must be established first, before Apache even gets the
request to examine.
The final result anyway, is that you can have a combination like
- several VirtualHost (non-SSL) listening on port 80
- one and only one VirtualHost listening on port 443, and it has to be
the only one because it must be the default host (for it's port).
---------------------------------------------------------------------
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
