Create a HTTPS load balancer
It's possible to use a SSL certificate with the load balancer, terminating SSL at the load balancer.
In this section, we'll continue with the same load balancer as in Create a simple HTTP load balancer using the control panel, but add a new listener. This listener will listen on port 443 for HTTPS traffic. You will also add a certificate to the listener.
The first step is to upload an SSL certificate to the load balancer. Currently, there is no support for renewing Let's Encrypt certificates directly in the load balancer. However, you can issue a Let's Encrypt certificate yourself and renew it manually. It's also possible to automate the process using the API endpoints loadbalancer/addcertificate, loadbalancer/listcertificate, and loadbalancer/removecertificate. Another alternative is to purchase a certificate with a longer expiration date.
Keep in mind that you need to point an FQDN (Fully Qualified Domain Name) to the load balancer for the certificate to appear valid in a web browser. If you're using Glesys DNS, you can easily create an A record for the IPv4 address and an AAAA record for the IPv6 address.
Once you have a valid certificate, upload it to the load balancer by pasting it. Click the Upload Certificate button for the load balancer.
In the dialog box that opens, paste the certificate along with all the intermediate CA certificates provided. This is typically referred to as a CA bundle or chain.pem. Sometimes, you may receive both the certificate and the CA bundle in a single file, which is often named full-chain.pem or something similar. You also need to paste the certificate's private key in the same dialog box. The key is typically named privkey.pem or something similar. The order should be as follows:
The certificate
The CA bundle / chain
The key
Everything must be in PEM format. See the guide "Convert an SSL certificate from CRT to PEM format" for instructions on how to convert a certificate.
You also need to name the certificate so it can be selected later for the listener. Here, we name it my-test-lb.
Now, create a new listener by clicking the Add Listener button just below the first listener you created earlier.
However, instead of port 80, choose port 443 for the listener this time. Select HTTP mode as before. Also, select the certificate you just uploaded from the Certificate dropdown menu. Click Save when everything looks good.
Now, add the targets—web servers—by clicking Add Target. Click Add Target multiple times to add several servers. Click Save to save all the targets.
Currently, it is not possible to use HTTPS for the targets due to how SSL verification works.
Redirect HTTP to HTTPS with Apache using X-Forwarded-Proto
The load balancer adds two HTTP headers, X-Forwarded-Proto and X-Forwarded-For. The latter, X-Forwarded-For, can be used to obtain the visitor's IP address. The former, X-Forwarded-Proto, can be used for redirect rules in, for example, Apache.
It is common to use RewriteCond %{HTTPS} off with Apache; however, this creates problems when, for example, a load balancer’s backend points to port 80. In that case, the request will always arrive on port 80, so the logic will always match, resulting in a redirect loop.
When a redirect loop occurs, the flow looks like this:
The request arrives on port 443, for example, at the load balancer, which terminates SSL.
It is forwarded to Apache on port 80.
Apache sees the request came in on port 80 and redirects the request back to the load balancer on port 443.
Back to step 1. This loop becomes endless.
This is where X‑Forwarded‑Proto comes in. This is a new header. When traffic originates from the load balancer with SSL enabled, X‑Forwarded‑Proto is set to https. Therefore, you need to rewrite the rule to make an exception when the header includes X‑Forwarded‑Proto: https and allow the traffic, so that only clients that originally accessed port 80 are redirected to HTTPS (port 443).
This is an example of how you can use X-Forwarded-Proto to write a redirect rule in Apache:
Last updated
Was this helpful?