[buug] two urls one ip...with ssl

[Rob Helmer]

Jeff Harris wrote:
> On Wed, 1 Sep 2004, Rob Helmer wrote:
>>The SSL negotiation happens before any HTTP headers are passed, which is 
>>why you do need one IP per domain. Named-based virtual hosting works by 
>>looking at the "Host:" HTTP header, so you're pretty much stuck with 
>>whatever the domain the certificate has on it, and this needs to match 
>>what the user typed into their web browser. By the time the "Host:" 
>>header is encountered by Apache, SSL negotiation has already been decided.
>>
>>This also means that you need a seperate SSL certificate for each domain.
>>
> 
> 
> SSL can work with name based virt hosts if each one uses a different
> port. I remember seeing this come up somewhere when I wasn't looking for
> it, so I didn't commit it to memory. 
> 
> IIRC, Each IP:port combination can use a different certificate, but I
> don't remember if they can be run from the same apache or if you need an
> apache instance for each set of ports.

True. One Apache instance can bind to multiple ports and send the 
traffic to different name or IP based vhosts.

However if each port represents a site being served on a different 
domain name, you will still need two certificates.. this could be a way 
to save on IP addresses, if you don't have any to spare. I've used the 
same certificate to serve both HTTPS (:443) and IMAPS (:993), and I know 
that when requesting a certificate you don't need to specify the ports 
you intend to use. I don't know if any user agents care if you're using 
a non-standard port for HTTPS though.

If it's for a public site and I had to do the above, I'd be concerned 
about users neglecting to enter the port as part of the URL. I'd 
probably set up a name-based non-SSL vhost for each domain, and 
advertise that as the website address. This non-SSL vhost would then 
redirect to the proper domain:port at the proper time. This seems to be 
how most public websites work anyway, because most browsers substitute 
"http://" for the user, and the general public doesn't neccessarily 
notice the "https://".


--
Rob