Hello Andy,
The SSL is bound on an IP address. There's no way around that. We typically
terminate the SSL on pound, but you can use another SSL terminator to handle
the encryption.
There is no way for pound to ever multiplex a host header in the SSL
protocol until after SSL is negotiated (it's a layer that pre-empts the
application layer).
You could do:
(internet) ==> [Pound SSL] ==> [Pound For Domain Multiplexing] ---| Servers
|| /\
================================|| (for port 80 traffic)
That doesn't really buy you anything. You can't have all of your domains
bind on the same IP address and attempt to share the same SSL, unless they
are all subdomains (wildcard SSL). Why not? Because the cert validation will
always fail on the cert domain name. You'll still get SSL crypt but you will
always get the "This certificate is not valid" error on the client.
The above configuration would be a nifty way to handle load balancing a
"farm" of subdomains. The wildcard would terminate on the SSL side, then
your multiplexer pound would handle the subdomains via the host header. That
might be what you're looking for?? That means you can handle *.mydomain.com.
Wildcards are not that expensive if you want a cheapie cert. Try
www.rapidssl.com for that.
We use wildcards for our service and it works just great.
-- jake
> -----Original Message-----
> From: Andy Ray [mailto:[EMAIL PROTECTED]
> Sent: Thursday, October 09, 2008 2:01 PM
> To: [email protected]
> Subject: Re: [Pound Mailing List] Pound usage for multi-domain
> solution.
>
> Thank you for your quick reply David!
>
> So, talking theory here, and trying to better understand the options
> available:
>
> Can the SSL cert be loaded on the router/firewall/gateway device
> hosting Pound? I am assuming that would give Pound access to the host
> header in a later request, then the traffic is redirected to the
> appropriate internal host? Or am I way off base here?
>
> How is this typically handled in a web server farm? Though I am not
> scaling this to anything near that size, I picture this as no
> different than accessing https://secure.amazon.com (or other such
> address) where the traffic is load balanced/proxied to multiple back
> end servers? Except, for the proxy/load balance on my scale it only
> has 1 host behind it. When I resolve secure.amazon.com I only get 1
> IP address - but I'm pretty sure that it doesn't go to 1 host publicly
> exposed on the back end at Amazon HQ.
>
> Thanks for helping me sort it out....
>
> Andy
>
> On 10/9/08, Dave Steinberg <[EMAIL PROTECTED]> wrote:
> >> What they would like to do is direct mail.company.com:443 to the OWA
> >> resources and vpn.company.com:443 to the SSL VPN appliance (two
> >> separate internal IP addresses).
> >>
> >> I understand that the preferred/accepted way for doing this is to
> >> obtain multiple IPs from the ISP and map those internally.
> >> Unfortunately that is not an option with the provider available in
> the
> >> area at this time.
> >
> > Its preferred because most people do not want their
> > clients/customers/service users to see SSL validation errors when
> they
> > try to access the service in question.
> >
> >> From the landing page for Pound, it looks like there is a problem
> with
> >> multiple domain redirection to single internal host IP with virtual
> >> servers on that same IP, unless a wildcard cert is used, which seems
> >> to indicate that it may be possible if all 443 traffic is redirected
> >> to a single host/ip.
> >
> > I've not tried it, but yes, a wildcard cert should work. They are
> > unfortunately much more expensive than regular certs.
> >
> >> From my small understanding of what I've read, Pound (or any other
> >> reverse proxy) is unable to decipher the host header because it
> comes
> >> after the SSL tunnel is negotiated. It would seem that the only
> >> solution left would be to use a product like Microsoft's ISA server
> >> that does seem to be able to reverse proxy SSL connections. If this
> >> is the case, I'm just a bit surprised that there isn't an option in
> >> the *nix world to achieve this goal.
> >
> > This is not a software or OS limitation but rather a protocol
> > limitation, for the reasons you describe. It is software agnostic,
> > which is why the wildcard cert is the only option that will avoid
> > warnings in your client software.
> >
> > Regards,
> > --
> > Dave Steinberg
> > http://www.geekisp.com/
> > http://www.steinbergcomputing.com/
> >
> > --
> > To unsubscribe send an email with subject unsubscribe to
> [EMAIL PROTECTED]
> > Please contact [EMAIL PROTECTED] for questions.
> >
>
> --
> To unsubscribe send an email with subject unsubscribe to
> [EMAIL PROTECTED]
> Please contact [EMAIL PROTECTED] for questions.
--
To unsubscribe send an email with subject unsubscribe to [EMAIL PROTECTED]
Please contact [EMAIL PROTECTED] for questions.
