HTTPS Load Balancing Configuration

*Certificates on Web Servers*

The first way is to create a key and certificate for the NLB domain name and then install it on both IIS servers.

https://support.microsoft.com/kb/313299

In this way, the load balancer simply forward HTTPS traffic to web servers. SSL encryption and decryption is done on the web servers and both servers have certificates.

*Certificate on Load Balancer*

The second way is to install the key and certificate on the load balancer, so it performs encryption and decryption instead of web servers. Traffic forwarded to web servers are HTTP only, so there is no need to enable SSL on the servers or install keys and certificates there.

According to a public deployment guide from F5, a famous load balancer vendor, its load balancers support the second approach, which can improve performance.

https://www.f5.com/pdf/deployment-guides/https-lb-compression-dg.pdf

If your load balancer also supports such a feature, you may consider whether to turn it on and enjoy the show.

*Consideration on Certificate Renewal*

As certificates will expire after its life time, sooner or later you need to renew them.

It is relatively easy to renew certificates on IIS servers, as you can remove one server off from NLB, renew the certificate on it, and then put it back. This change only has a small impact on the whole NLB system.

But what about renewing the certificate on load balancers? The F5 document above does not contain such information. If it is possible to renew the certificate on it without interrupting its service, then it’s nice and perfect.