# Ensure Load Balancer Enforces HTTPS/TLS Termination

- Source: https://support.icompaas.com/support/solutions/articles/ensure-load-balancer-enforces-https-tls-termination
- Section: [Solutions](https://support.icompaas.com/support/solutions) › [DigitalOcean Cloud](https://support.icompaas.com/support/solutions/c_do_cloud) › [DigitalOcean Rules](https://support.icompaas.com/support/solutions/folders/digitalocean-rules)
- Last updated: 2026-08-13
- Publisher: iCompaas, Inc. (https://www.icompaas.com)

## Description

This rule verifies that every DigitalOcean Load Balancer terminates TLS and enforces HTTPS for client-facing traffic instead of accepting or forwarding plaintext HTTP. On a DigitalOcean Load Balancer, HTTPS enforcement is expressed through the forwarding rules: an entry rule with an entry\_protocol of https, http2, or http3 on port 443 must be bound to a TLS certificate (certificate\_id) or configured for TLS passthrough, and the load balancer's redirect\_http\_to\_https setting must be enabled so that any request arriving on HTTP port 80 is redirected to the encrypted listener.

The rule inspects each load balancer's forwarding\_rules and redirect\_http\_to\_https flag. It flags load balancers that expose an http entry rule with no corresponding https/http2/http3 rule, and load balancers that accept HTTP on port 80 without redirect\_http\_to\_https enabled, so that plaintext requests are served rather than upgraded to TLS.

Remediation is to add an HTTPS (or HTTP/2 / HTTP/3) entry rule bound to a valid certificate, enable Force HTTPS (redirect\_http\_to\_https) so the port-80 listener 307-redirects to 443, and remove any standalone HTTP entry rule that no legacy client depends on.

-   Load balancers with an HTTP (port 80) forwarding rule and no HTTPS/HTTP2/HTTP3 rule.
    
-   Load balancers serving HTTP on port 80 with redirect\_http\_to\_https disabled (no Force HTTPS).
    
-   HTTPS entry rules with no certificate\_id and tls\_passthrough not set.
    

## Rationale

Traffic that reaches the load balancer over plain HTTP travels unencrypted across the network segment between the client and the load balancer, where it can be read or modified by anyone in the path. Enforcing TLS termination at the load balancer ensures credentials, session cookies, and payloads are confidential and integrity-protected end to the load balancer, and redirecting HTTP to HTTPS closes the window in which a client might otherwise transmit sensitive data in cleartext before being upgraded.

Serving both HTTP and HTTPS without a redirect leaves a downgrade path that attackers can exploit (for example, stripping the connection back to HTTP). A single enforced HTTPS entry point removes that ambiguity and is a baseline expectation of most compliance frameworks.

-   Protects data in transit against interception and tampering on the client-to-load-balancer hop.
    
-   Removes HTTP downgrade / SSL-stripping opportunities.
    
-   Aligns with PCI DSS, SOC 2, and GDPR expectations for encrypting data in transit.
    

## Impact

Pros:

-   All client traffic is encrypted or automatically upgraded to an encrypted listener.
    
-   Eliminates plaintext listeners that can leak credentials and session data.
    
-   Consistent, auditable HTTPS-only posture across the fleet.
    

Cons:

-   Requires a valid certificate provisioned and bound to the load balancer.
    
-   Legacy clients or health probes hard-coded to HTTP port 80 may need updating.
    
-   TLS termination adds a small amount of processing on the load balancer.
    

## Default Value

New DigitalOcean Load Balancers do not redirect HTTP to HTTPS by default (redirect\_http\_to\_https defaults to false), and forwarding rules are whatever you define at creation, so HTTPS enforcement is not on unless you configure it.

## Pre-Requisite

-   A DigitalOcean account role that can view and edit Load Balancers (for example Owner or a member with modify access to Networking).
    
-   A doctl instance authenticated with a DigitalOcean API token, or the token exported as $DIGITALOCEAN\_TOKEN, with read/write scope.
    
-   A TLS certificate available in the account (Let's Encrypt managed or a custom uploaded certificate) for the load balancer's domain.
    

## Remediation

### Test Plan

Using the DigitalOcean Control Panel:

1.  Sign in to the DigitalOcean Control Panel at cloud.digitalocean.com.
    
2.  In the left menu, go to Networking, then open the Load Balancers tab.
    
3.  Select the load balancer you want to inspect.
    
4.  Open the Settings tab and review the Forwarding Rules: confirm at least one rule uses HTTPS (or HTTP/2 / HTTP/3) on entry port 443 with a certificate selected.
    
5.  Confirm the 'Redirect HTTP to HTTPS' (Force HTTPS) option is enabled.
    
6.  Check whether a standalone HTTP entry rule on port 80 exists that is not covered by the redirect.
    
7.  Pass: An HTTPS/HTTP2/HTTP3 entry rule with a valid certificate exists and Redirect HTTP to HTTPS is enabled (or no HTTP listener exists at all).
    
8.  Fail: The load balancer exposes an HTTP port-80 rule with no HTTPS rule, or Redirect HTTP to HTTPS is disabled while HTTP is still accepted.
    

Using doctl or the API:

List load balancers and inspect each one's forwarding\_rules and redirect\_http\_to\_https flag.

doctl compute load-balancer list --format ID,Name,RedirectHttpToHttps,ForwardingRules

doctl compute load-balancer get <load-balancer-id> --format ForwardingRules,RedirectHttpToHttps

curl -s -X GET "https://api.digitalocean.com/v2/load\_balancers" -H "Authorization: Bearer $DIGITALOCEAN\_TOKEN" | jq '.load\_balancers\[\] | {id, name, redirect\_http\_to\_https, forwarding\_rules}'

Pass: for each load balancer, redirect\_http\_to\_https is true and forwarding\_rules includes an entry\_protocol of https/http2/http3 with a certificate\_id set (or tls\_passthrough true). Fail: forwarding\_rules contains an http entry rule with no https/http2/http3 counterpart, or redirect\_http\_to\_https is false while an http rule is present.

### Implementation Steps

Using the DigitalOcean Control Panel:

1.  In the Control Panel, go to Networking, then Load Balancers, and select the load balancer.
    
2.  Open the Settings tab and locate Forwarding Rules.
    
3.  Add or edit a rule so entry protocol is HTTPS (or HTTP/2 / HTTP/3) on port 443, and select a certificate (Let's Encrypt or a custom certificate) for TLS termination.
    
4.  Enable the 'Redirect HTTP to HTTPS' option so port-80 requests are redirected to 443.
    
5.  Remove any remaining HTTP-only forwarding rule that no client legitimately requires.
    
6.  Save the changes and confirm the forwarding rules reflect the new HTTPS-only posture.
    

Using doctl or the API:

Update the load balancer's forwarding rules and enable redirect\_http\_to\_https via doctl or the API.

doctl compute load-balancer update <load-balancer-id> --redirect-http-to-https --forwarding-rules "entry\_protocol:https,entry\_port:443,target\_protocol:http,target\_port:80,certificate\_id:<certificate-id>"

curl -s -X PUT "https://api.digitalocean.com/v2/load\_balancers/<load-balancer-id>" -H "Authorization: Bearer $DIGITALOCEAN\_TOKEN" -H "Content-Type: application/json" -d '{"redirect\_http\_to\_https": true, "forwarding\_rules": \[{"entry\_protocol":"https","entry\_port":443,"target\_protocol":"http","target\_port":80,"certificate\_id":"<certificate-id>"}\]}'

### Backout Plan:

1.  Record the current forwarding\_rules and redirect\_http\_to\_https value before changing them (doctl compute load-balancer get <id>).
    
2.  If the HTTPS change breaks a client, re-run the update with the previous forwarding\_rules JSON to restore the earlier configuration.
    
3.  Set redirect\_http\_to\_https back to false only if the redirect itself is the cause, and re-add the prior HTTP rule if it was required.
    
4.  Verify the restored load balancer serves traffic as before.
    

## References:

1.  [DigitalOcean Load Balancers — Features (SSL termination, Force HTTPS)](https://docs.digitalocean.com/products/networking/load-balancers/details/features/)
    
2.  [DigitalOcean Load Balancers API reference](https://docs.digitalocean.com/reference/api/reference/load-balancers/)
    
3.  [How to Manage Regional Load Balancers](https://docs.digitalocean.com/products/networking/load-balancers/how-to/manage/)
    
4.  [doctl compute load-balancer update](https://docs.digitalocean.com/reference/doctl/reference/compute/load-balancer/update/)

## Related compliance guidance

- [SOC 2 compliance: a practical implementation guide for cloud-native SaaS teams](https://support.icompaas.com/compliance/soc-2-trust-services-criteria): Configuration checks like this one are the technical half of a SOC 2 / ISO 27001 programme — the guide shows where they fit, what else an auditor expects, and how to evidence them.
- [ISO/IEC 27001:2022 compliance: a practical implementation guide](https://support.icompaas.com/compliance/iso-27001-2022): ISO 27001 Annex A.8 (technological controls) is where cloud hardening evidence lands; the guide shows how to run the ISMS around it.