Ah! I understand now! (and need to smack my self in the head) Jacob's explanation brought me closer to understanding, and your answer drove it home. The SSL server/"listener" can only proffer 1 cert per IP. As ridiculously easy as the explanation sounds, I'm beginning to wonder why I was being so obtuse about it :)
Yes, my example was not a fair example, because what I was trying to do did not match the google example I gave. For the google example, everything is mail.google.com that it redirects to on the back end. 1 request in brokered out to many on the back end. I was still missing the fact that there is no way to have 2 requests in brokered to different servers on the back end because the receiving host cannot overlap SSL responders/services on 443 with different certs on a single web server/IP. Everyone, thanks for helping me straighten this architecture out mentally. I hope it didn't take too much of your time! On 10/9/08, Miles Raymond <[EMAIL PROTECTED]> wrote: > Andy, > > The key difference between what you are trying to do, and what Amazon and > Google are doing is that you are trying to have multiple SSL certs on 1 IP > address. Amazon and Google have 1 SSL cert on multiple IP addresses. > > If you read the pound documentation ( http://www.apsis.ch/pound/ ), you will > read that: > "The vital point to notice here is that connection authentication takes > place BEFORE any request was issued." > This means that when a connection is made, there is no URL information sent > until the SSL cert has been verified. Your server cannot pick and choose > between different certs to give to the client because all it sees is > 'connection from x.x.x.x'. Only AFTER the SSL cert has been sent by your > server, does the client request 'ok, give me mail.company.com' to the > server. > > In our datacenter, we have an external IP for mail.company.com which is > different from the external IP for vpn.company.com. The firewall redirects > the requests to different ports on our pound server. Our pound server has a > listener on 443 for mail.company.com and a listener on 444 for > vpn.company.com. Out pound server then balances the request to a multitude > of back-end servers to actually process the unencrypted request. The key > difference between this solution and Jacob Anderson's is that our solution > has combined the SSL encryption/decryption and balancing in one single > instance of pound. > > -Miles Raymond > ITI Internet Services > > Andy Ray wrote: >> Thanks Alfonso, >> >> That is actually the way we have things configured right now and it is >> good enough to get by... but my curiosity was peaked when discussing >> the issue with a colleague about how this is done in the "real world". >> >> I just sent a reply to David where I outlined the heart of my question >> - but basically I can't understand why this is so difficult. When I >> access a web address like https://secure.amazon.com or >> https://mail.google.com I come in through a single IP. When I look at >> the cert for mail.google.com, there is no IP information that >> identifies the site. If certs were tied to a single IP, how do farms >> of servers handle a site like https://mail.google.com? >> >> The only difference in the solution I'm trying to achieve is that on >> the back end I only have 1 server instead of 1000 like Google :). >> >> Andy >> >> On 10/9/08, Andy Ray <[EMAIL PROTECTED]> wrote: >>> 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.
