SSL certificate for cluster behind load balancer

[Guest]

[chenxg]

Hi, would like to get some advice on what kind of SSL certificate we could use for our scenario specified below:

We have two windows servers (running IIS as the webserver) forming a cluster for high availability. Each windows server has its own IP, hostname and virtual dns/domain, e.g. abc1.com.sg and abc2.com.sg.  We also have assigned virtual dns abc.com.sg to a load balancer, and defined the rule that when user reach the load balancer at abc.com.sg, it will direct the traffic to abc1.com.sg and abc2.com.sg in a round-robin manner.

We want to protect the abc.com.sg as this is the URL that users are using to access the application.

Please advise what kind of SSL cert we should purchase.

Thank you.

[Ronny]

Please advise what kind of SSL cert we should purchase.

Hi chenxg,

If you want people to be able to trust your site as being your company URL you need a so called EV certificate.
That means the business behind the site is verified and trusted, for the other types only the domain-name is validated but that tells the user nothing about the company behind it.

http://ssl.comodo.com/comodo-ev-ssl.php

[chenxg]

Hi Ronny,

Thanks for the prompt reply.  Would like to clarify that this is an internal application behind the company firewall, and it is accessed by our internal staff within the intranet, not an internet facing URL.  The reason we want to use the SSL certificate is to encrypt some confidential data while being transmitted between the client and server. 

My issue here is that the two clustered servers (IIS as the webserver) are having different domain names, i.e. abc1.com.sg and abc2.com.sg and the two servers are behind the load balancer.  We want people to access the application via the load balancer at domain name abc.com.sg so that the load are shared by two servers.

By the way, we are using hard ware load balancer, not the software load balancer, e.g. NLB that comes with the windows server.

Your advice is very much appreciated.

Thanks.

[technion]

Typical load balancer configuration involves the SSL offload functionality being present inside that load balancer.

This would mean the balancer itself would have an SSL certificate for the name "abc.com.sg". For the traffic between the balancer and the server itself, you have a few options. The obvious "ideal" solution is purchasing a separate certificate for each server, abc1, abc2 etc such that the balancer passes traffic encypted to them directly. You have a few realities though:

* The network between your balancer and the internal servers should be an isolated, out of band network. It is therefore not prone to intercept and arguably there is no need for SSL there at all
* Self signed certificates on these servers will never be visible to the end user, only to your load balancer. That hardware is probably unconcerned with the quality of a certificate.

Your third option here is buy a SAN certificate, place all relevant names on that cert, and install the same certificate on all your servers and on load balancer. The more servers you have, the more cost effective this becomes.

I'm not sure Ronny's post is much more than a sales pitch with regards to answer your question?

[Ronny]

I'm not sure Ronny's post is much more than a sales pitch with regards to answer your question?

I have nothing to sell here, I'm NOT COMODO STAFF just a volunteer helping around on the forums.
I was trying to keep my questions simple to not overly confuse the OP with to much questions and technical details in the first response.

[Ronny]

Hi Ronny,

Thanks for the prompt reply.  Would like to clarify that this is an internal application behind the company firewall, and it is accessed by our internal staff within the intranet, not an internet facing URL.  The reason we want to use the SSL certificate is to encrypt some confidential data while being transmitted between the client and server. 

Your welcome.

My issue here is that the two clustered servers (IIS as the webserver) are having different domain names, i.e. abc1.com.sg and abc2.com.sg and the two servers are behind the load balancer.  We want people to access the application via the load balancer at domain name abc.com.sg so that the load are shared by two servers.

Is it enough to only encrypt the traffic between the client and the SSL Terminator (Loadbalancer/Content Switch) ?
or does the traffic between the SSL Terminator and the web servers also need encryption?
In the first case the loadbalancer only needs to be configured for Client side SSL Termination.
In the second case the loadbalancer needs to act as a SSL client to access the web servers which in that case also need to run SSL with some sort of Certificate.

If we focus on the first case you need to make sure both servers are configured to listen to the host-header 'abc.com.sg' because that will be the name the clients send out to the IIS server.
IIS needs to be able to show the proper content based on that name.

By the way, we are using hard ware load balancer, not the software load balancer, e.g. NLB that comes with the windows server.

Be very glad, because NLB can hardly be called a loadbalancer, it's a very dirty trick Microsoft is pulling there on the network.
My advice would be to stay as far a way as possible from implementing NLB.

[chenxg]

Hi Ronny,

Appreciate your comments very much, at least I can see some light. 

If we want to encrypt the traffic all the way from browser to the server, do we need to install the SSL cert for domain "abc.com.sg" on the load balancer and install SSL cert for "abc1.com.sg" on one server and cert for "abc2.com.sg" on another server?

By the way, I fully agree with you regarding the Microsoft NLB.

[Ronny]

I would test the following first.
Install the abc.com.sg on all 3 the Certificates are not bound to how many machines you install them on so you can buy one and use them on all 3 if your setup allows this.

Both servers should listen for (Host-Header) anyway and have the certificate for abc.com.sg

[chenxg]

Hi Ronny,

Before I saw your reply, we did exactly the same testing, and you know what, it works....

We install the certificate for abc.com.sg on the 2 servers behind the load balancer, and it just works, we don't even need to install the cert on the load balancer. 

The conclusion: The end user is accessing the application at abc.com.sg, so that is the domain to be protected and the cert to be installed on both servers behind the load balancer.  The domain names of abc1 and abc2 are irrelevant here as they are not part of the URL at all. 

PS: Seems the forum here is much more helpful than sending emails directly to Comodo tech support, who, in my opinion, doesn't really understand my problem and yet keep asking us to buy those expensive SSL cert, like wildcard or UCC.

[Ronny]

We install the certificate for abc.com.sg on the 2 servers behind the load balancer, and it just works, we don't even need to install the cert on the load balancer. 

In that case the Loadbalancer is only doing Layer4 balancing (TCP port 443) and not the SSL termination (CPU off-loading from web servers).

Is your setup sticky so that a user always get's balanced to the same web-server after the initial balance decision?

[chenxg]

Is your setup sticky so that a user always get's balanced to the same web-server after the initial balance decision?

No, it is not sticky.  We tested, it randomly direct my requests to the two servers in a round-robin manner, which is what we want.

[Ronny]

Are you sure that is the desired design? because your causing SSL handshake/CPU overhead with this setup.

Say the client get's connected to the first server and starts SSL negotiation all finished CPU cycles done second request ends up on the second server SSL needs to be negotiated again because that specific server doesn't know the client's key/session etc causing CPU overload and troubleshooting complexity.

[chenxg]

Are you sure that is the desired design? because your causing SSL handshake/CPU overhead with this setup.

Say the client get's connected to the first server and starts SSL negotiation all finished CPU cycles done second request ends up on the second server SSL needs to be negotiated again because that specific server doesn't know the client's key/session etc causing CPU overload and troubleshooting complexity.

Now I understand why you ask the question about the stickiness in the other post.  I guess the stickiness has to be set up at the load balancer, right?  I need to check with my network guy on this.

But what will happen if the client gets connected with the first server, and subsequently the first server is down, would the client still be directed to the first server by the load balancer because of the sticky set-up?

[technion]

Now I understand why you ask the question about the stickiness in the other post.  I guess the stickiness has to be set up at the load balancer, right?  I need to check with my network guy on this.

But what will happen if the client gets connected with the first server, and subsequently the first server is down, would the client still be directed to the first server by the load balancer because of the sticky set-up?

The usual goal of a load balancer is to help reduce load on servers. Therefore any optimisation step is beneficial. Reestablishing the SSL handshake is not optimal, but if your servers are capable and your goal is availability, you may not care.

A "sticky" configuration will usually detect when one server is offline and act accordingly.

[Tags:]