httpd-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From André Warnier ...@ice-sa.com>
Subject Re: [users@httpd] Two virtual hosts with 2 different sets of SSL certificates
Date Thu, 30 Apr 2009 13:29:58 GMT
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-unsubscribe@httpd.apache.org
   "   from the digest: users-digest-unsubscribe@httpd.apache.org
For additional commands, e-mail: users-help@httpd.apache.org


Mime
View raw message