[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: svn with virtual hosts

From: Ryan Schmidt <subversion-2005_at_ryandesign.com>
Date: 2005-03-12 03:40:28 CET

On 10.03.2005, at 08:41, Eric Penfold wrote:

> dave wrote:
>> I'm not using IP-based virtual hosting, but name based such as:
>> NameVirtualHost www.example.com:443
>> <VirtualHost www.example.com:443>
>> ...
>> </VirtualHost>
>>
> As it says here
> (http://httpd.apache.org/docs-2.0/ssl/ssl_faq.html#vhosts), due to the
> way the SSL protocol works, you cant use name-based virtual hosting to
> run multiple https virtual hosts on a single IP/port.

Generally true. I know of three ways to serve multiple SSL sites from a
single IP.

1) Use a different port on the same hostname for each site. You could
then set up redirects at various other domain names pointing back to
the correct port on the secure domain. I had this set up on my laptop
for a while to try it out. I set up a certificate for
"secure.example.com" and set that up to be my secure site in Apache.
Then I set up normal port-80 virtual hosts at
http://site-one.example.com/ and http://site-two.example.com/, which
redirected to https://secure.example.com:10010/ and
https://secure.example.com:10020/. Works, but the URLs aren't
particularly pretty.

2) You can do name-based virtual hosting of SSL hosts if you don't care
that the browser can't validate the certificate. We are currently doing
this at work for some internal sites we needed to make accessible for
employees to access from home. The "invalid certificate" box the
browser displays is even uglier than the port number in the URLs.

3) There are special wildcard SSL certificates you can buy which
protect a whole domain worth of hostnames, not just a single hostname.
So, for example, the certificate wouldn't be issued to
secure.example.com, but instead to *.example.com. The traditional
problem is that the server doesn't know which certificate to send you,
because the Host header hasn't appeared yet, so a wildcard certificate
works around the problem by letting the server just always send the
same certificate. The problem is that only newer browsers know how to
validate the certificate, and it does only work for one domain name --
you couldn't protect both *.example.com and *.example.org this way. Do
a Google search for "wildcard ssl certificates" and you'll find a
number of places selling them.

Our virtual host situation at work has gotten rather out of control, so
I'm in the process of consolidating everything back into a single host,
with usefully-named subdirectories for everything we need. Then we can
issue the SSL cert for www.example.com and have our sites at
https://www.example.com/site-one/ and https://www.example.com/site-two/
and so forth.

And if SSL on multiple domain names really is required, then for now
you probably will need multiple public IPs.

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Sat Mar 12 03:43:08 2005

This is an archived mail posted to the Subversion Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.