Load balanced web farm using SSL

Paul

Thanks for the response! Unfortunately, not the "Griff" you're thinking
of....in fact....don't think I've ever been to Manchester.

Griff 2
 >> Stay informed about: Load balanced web farm using SSL 

Yes, you can install the same certificate, but you don't solve your problem
that way as even with identical certificates, the SSL session won't survive
a switch to another server as the session key is unique per connection. A
new connection to a different server will require a new key regardless of
the certificate used. Having a common certificate will help with replication
issues however as it is one less unique property to manage.

The best solution I know about for your problem is to use a device for
balancing that does SSL in front of the IIS servers. Many hardware load
balancers can do this. ISA server will do this too with reverse proxying
although it is not a load balancing solution.

-brett hill IIS MVP
iisanswers.com


"Griff" <Howling RemoveThis @The.Moon> wrote in message
news:u1KFu13YEHA.2456@TK2MSFTNGP10.phx.gbl...
 > Paul
 >
 > Thanks for the response! Unfortunately, not the "Griff" you're thinking
 > of....in fact....don't think I've ever been to Manchester.
 >
 > Griff 2
 >
 ><!-- ~MESSAGE_AFTER~ -->
 >> Stay informed about: Load balanced web farm using SSL 

Hi,



There are two [main] ways to handle load balancing with SSL.



1. Method 1: Have the IIS server handle the SSL connections.



In this case, you will need to buy a certificate for each server that will
handle SSL traffic. Note that the certificate will be the same across the
servers that have it installed.



The problem with this method is that you're limited in that the only
semi-reliable method to stick (by using a hardware-based load balancer)
users to the server that they started on is to stick them based on their IP
address coupled with a netmask that you define. So for example, say you
stick on a /24 netmask - a user with the IP of 192.168.100.5 gets load
balanced to server 1. When a second user with an IP of 192.168.100.90 visits
your SSL site, they too, will go to server 1. This method can become a
problem when dealing with the AOL's of the world because of their rotating
proxy servers that don't all use /24 netmasks. While you can change the
netmask on your end to anything you want that's valid, you need to consider
that you may be overloading some servers.



This method is good if your applications do not rely on in-process session
state because you can get away with a longer prefix (i.e. /22. /24) because
the worse thing that will happen is some of your clients may need to
renegotiate the SSL connection with another server, Also, like you asked
about, you can have 1 lucky server handle all the SSL connections provided
you're not using in-process session state. It's not the most ideal solution,
but it works.



This method is especially bad if you load balance based on information in
the request because the load balancer will not be able to read the request
(because it's encrypted)



2. Method 2: Have you load balancers or SSL decryption devices decrypt
SSL



You have lots of flexibility using this method. The most notable advantage
with this method is since the load balancer decrypts the traffic, it can
load balance based on any method that your LB's support when using standard
http. Once the SSL traffic is decrypted and a load balancing decision has
been made, you have the option of sending the traffic back to your IIS
servers in clear text or you can re-encrypt it using the SSL certificates
that are on your web servers. A nice feature of the F5 product line (and I'm
sure others too) is that you can use self-signed SSL certificates on the IIS
servers if you want to re-encrypt traffic from the load balancers to the IIS
servers. You still must have a trusted certificate on each of the load
balancers, but this way, you don't have to buy certificates for each of the
servers if you need to re-encrypt traffic.



There are other methods too. For example, you have a unique SSL certificate
for each server and have your application redirect the user to the SSL site
for a particular server. For example, say you have server1 and server2. If a
user goes to server1 using standard http then they go to check out using SSL
(as is the case for a typical ecommerce site,) your app can direct them to
<a style='text-decoration: underline;' href="https://server1.domain.tld" target="_blank">https://server1.domain.tld</a> whereas a user that started on server2 will be
redirected to <a style='text-decoration: underline;' href="https://server2.domain.tld" target="_blank">https://server2.domain.tld</a>



Let me know if you have any more questions.



Regards,



smk



"Griff" <Howling.RemoveThis@The.Moon> wrote in message
news:%23ioQZJ1YEHA.716@TK2MSFTNGP11.phx.gbl...
 > One method to improve scalability is to implement a web farm where several
 > "identical" web servers sit behind a load balancer.
 >
 > However, if these web servers support SSL then they're not "identical" as
 > they will have their own unique certificates.
 >
 > The SSL hand-shake presumably can't survive if the load balancer keeps
 > swapping servers, so....how does this work?
 >
 > Two scenarios that I can think of:
 >
 > 1 - all servers handle SSL (with their unique certificates) and the Load
 > Balancer only load balances http requests; all https requests remain
 > "sticky" to always call the same web server. Is this possible?
 >
 > 2 - one of the web servers in the farm is chosen to be the "lucky" one and
 > handle all SSL connections. The load balancer is made aware of this and
 > load balances http requests, but sends SSL ones through to only server A.
 > Is this possible?
 >
 > If both 1 & 2 are possible, which is preferred? (Guess it's a case of 2
 > being cheaper since it involves purchasing one verified certificate and
 > therefore being the preferred option providing that it can cope with the
 > load...).
 >
 > Thanks
 >
 > Griff
 >
 ><!-- ~MESSAGE_AFTER~ -->
 >> Stay informed about: Load balanced web farm using SSL