Server Fault is a question and answer site for system and network administrators. It's 100% free, no registration required.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

Here is our current production configuration at a 3rd party data center:

•2 LINUX/CentOS tomcat web servers behind a shared load balancer •DNS entries point to the load balancer •Web apps are written using Java 6, Spring 3, Hibernate 4.

The data center techs have told us that in order to use the load balancer to forward port 80 to 8080, and forward 443 to 8443 (so we don't have port numbers in our URLs) we must have SSL certificates installed on BOTH the load balancer AND on the tomcat web server. But this affects our performance/throughput, and limits the number of SSL connections (i.e. users) we have connecting to our web apps concurrently.

Does having both SSL certs make sense, or can this be simplified and just install the SSL certificate on either the load balancer, or the tomcat web server, but not both. And which one would be preferred?

Thanks in advance - Mark

share|improve this question
I would prefer to have port 80 redirect to 443 on the LB, terminate SSL on the LB, and proxy over to the Tomcat port. This is a pretty common request for LB, not sure why they are giving you a hard time. – Schrute Apr 4 '14 at 4:11

I suspect this limitation is due to a limitation of their product, or in their management of that product. I don't see any technical reason that would require it in principle.

However, I would suggest that it may well be better to have a web-server (eg. Apache, nginx) fronting your Java container on each of the member-servers. That gives you the ability to let the web-server do more of the work with regard to serving static content and caching, etc.

I would expect that for a deployment where SSL can be terminated at the load-balancer (ie. not a high-security site where you really want SSL to the server), the load-balancer would need to have a way of injecting (and sanitizing) HTTP headers to inform the member-server if the request came in over https, etc. But you do need to be careful that people can't get to the member-servers directly (they could inject their own headers).

For most enterprise-scale deployments, terminating the SSL on each of the member-servers is the normal thing. I don't have experience in scaling that out though.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.