SSL Certificate on Load balancer or server

10,611

Solution 1

A very common practice (I wouldn't say standard) is to place/configure the certificate in the load balancer, not in the backend servers. Why? This enables the load balancer to handle the TLS handshake/termination overhead (i.e. memory/CPU for TLS messages), rather than having the backend application servers use their CPUs for that encryption, in addition to providing the application behavior. Thus it's usually a "pro" of having the TLS termination be in front of your application servers.

This also allows for TLS session caching on the single route to your servers (i.e. through the load balancer), which means greater chances of using a cached TLS session. If, on the other hand, you configured the certificate on each of the backend servers, then those servers would (presumably) have their own separate TLS session caches; a client may (nor may not) be directed, by the load balancer, to the backend server with its TLS session cached.

So the short version is: configuring the certificate in the load balancer is the generally recommended approach.

Hope this helps!

Solution 2

If you don't load the certificate onto the loadbalancer you can only load balance TCP/IP connections, as the traffic itself is encrypted.

By loading the certificate on your loadbalancer you get the ability to do all kinds of more interesting things there, depending on the abilities of your loadbalancer:

  • Create session persistence/sticky sessions, such that subsequents requests from a specific user will always get routed to the same back-end server (e.g. based on a session cookie) which is much more reliable than using the source IP-address as the basis for affinity, which is the only option when you don't have the certificate on the LB.
  • Route different URL's to different pools of back-end servers, i.e. direct example.com/app-1 to different application servers than those used for example.com/app-2
  • etc.

Quite often you'll terminate the TLS/SSL connection on the LB and have unencrypted traffic between LB and the back-end servers, but nothing prevents you from establishing a second TLS/SSL connection there if your security requirements are such.

Solution 3

As TJ mentioned, install SSL CERTS on the load balancer, this can handle the work and offload users into the backend servers.

There is a great example/tutorial of this over at Digital Ocean installing Lets Encrypt certs on a CentOS 7 HA Proxy server 😃

Share:
10,611

Related videos on Youtube

David Garcia
Author by

David Garcia

Updated on September 18, 2022

Comments

  • David Garcia
    David Garcia over 1 year

    I have a load balancer distributing traffic between two servers, the public facing urls are all https prefixed.

    I want to generate a wildcard ssl certificate but I am not sure if is better to place it in the load balancer or in the two servers? whats the recommendation? what are the benefits and differences.

    Thanks

  • Prashant
    Prashant almost 6 years
    I am having load balancer and applications in couple of vms. i acquired a wild card certificate for subdomain. Is this solution applicable in my case?
  • jumping_monkey
    jumping_monkey about 4 years
    Hi @Castaglia, if you configure the cert in the LB, the LB will offload the TLS traffic as HTTP to the AS. If my AS is expecting TLS traffic, how would it know that it needs to treat the incoming HTTP traffic as if it was TLS? Meaning how would it know that the original traffic is TLS and thus it can continue to process the incoming req.?
  • jumping_monkey
    jumping_monkey about 4 years
    Hi @HBruijn, if you configure the cert in the LB, the LB will offload the TLS traffic as HTTP to the AS. If my AS is expecting TLS traffic, how would it know that it needs to treat the incoming HTTP traffic as if it was TLS? Meaning how would it know that the original traffic is TLS and thus it can continue to process the incoming req.?
  • Castaglia
    Castaglia about 4 years
    @jumping_monkey many load balancers provide the X-Forwarded-Proto HTTP header for that purpose -- to signal to the backend servers that the original connection used HTTPS.