SSL Certificate on Load balancer or server

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!

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.