Introduction

A load balancer can terminate TLS, pass TLS through, or re-encrypt traffic to the origin. Problems start when the origin expects one mode and receives another. For example, the balancer may speak plain HTTP to a port configured for HTTPS, or initiate HTTPS to an origin listener serving only HTTP. The fix is to trace the exact protocol used at each hop and make the listeners match.

Symptoms

  • Health checks fail only when SSL is enabled on the load balancer
  • Users see SSL handshake errors even though the certificate looks valid at the edge
  • The origin logs show malformed requests or unexpected protocol errors
  • The site works directly on origin but breaks when traffic goes through the load balancer
  • The issue started after changing listener ports, target groups, or TLS settings

Common Causes

  • The load balancer sends HTTP to an origin port that expects HTTPS
  • The load balancer re-encrypts with HTTPS, but the origin listener serves plain HTTP
  • Target group or backend service ports do not match the intended protocol mode
  • Certificates are configured correctly at the edge but not on the origin listener used for re-encryption
  • Redirect logic assumes TLS terminates in a different place than it actually does

Step-by-Step Fix

  1. Map the full request path and note exactly where TLS terminates, resumes, or passes through between client, load balancer, and origin.
  2. Confirm which port and protocol the load balancer uses when connecting to the origin target.
  3. Check the origin listener on that port and verify it is configured for the same protocol the load balancer is sending.
  4. Review health check settings separately, because they often use different ports or protocols from normal client traffic.
  5. If the load balancer re-encrypts to the origin, confirm the origin has a valid certificate and compatible TLS configuration on that listener.
  6. If TLS terminates only at the edge, ensure the origin listener expects plain HTTP and that application redirects honor forwarded protocol headers correctly.
  7. Retest both health checks and real requests after aligning the protocol mode and listener configuration.
  8. Verify there are no mixed assumptions left in redirects, application URL settings, or security policies about where HTTPS begins.
  9. Document the chosen termination model so future port or certificate changes do not recreate the mismatch.