SSL, mTLS, and Load Balancers: The Basics

SSL becomes confusing once load balancers enter the picture. Most confusion comes from mixing up internal platform security with external client access.

This article explains how SSL and mTLS work in Clockspring, how load balancers change external access, and why certificates are always required, even when users never connect directly over HTTPS.

The One Rule to Understand First

Clockspring always uses TLS internally.

This includes:

• mTLS between cluster nodes

• mTLS between Clockspring and the Registry

Because of this:

• Clockspring always requires a keystore and truststore

• Certificates are not optional

• This requirement exists regardless of load balancers

Load balancers only affect how external clients connect, not whether TLS exists at all.

Two Separate TLS Concerns (Do Not Mix These Up)

1. Internal Clockspring Security (Always On)

This is platform-level security and cannot be disabled.

It covers:

• node-to-node communication

• Registry communication

Characteristics:

• always encrypted

• always authenticated with certificates

• uses mTLS

• independent of UI or API access

These certificates exist even in environments where:

• users connect over HTTP behind a load balancer

• TLS terminates before traffic reaches Clockspring

2. External Client Access (Topology Dependent)

This covers:

• UI access

• API access from users or external systems

This is where load balancers matter.

The question here is not “do we need certificates,” but: where does client-facing TLS terminate?

Common SSL Patterns with Load Balancers

Pattern 1: SSL Termination at the Load Balancer

What happens

• Clients connect to the load balancer over HTTPS

• TLS terminates at the load balancer

• Traffic from the load balancer to Clockspring is HTTP

Certificates

• Load balancer has the public-facing certificate

• Clockspring still has certificates for internal mTLS

• Client-facing certs are not used by Clockspring

Key point
TLS still exists inside Clockspring. It just isn’t used for client traffic.

Pattern 2: SSL Passthrough

What happens

• Clients connect over HTTPS

• Load balancer forwards encrypted traffic

• TLS terminates at Clockspring

Certificates

• Clockspring uses certificates for both:

  • internal mTLS

  • client-facing HTTPS

Key point
Same platform certs may be used for multiple purposes, but the internal TLS requirement already existed.

Pattern 3: SSL Re-Encryption (Double TLS)

What happens

• Client → load balancer uses HTTPS

• Load balancer → Clockspring also uses HTTPS

• Two separate TLS connections

Certificates

• Load balancer has its own cert

• Clockspring has its own cert

• Trust must be established in both directions

Key point
This is the most secure and the most complex model.

Keystore vs Truststore (In Plain Terms)

Keystore

Used to prove who Clockspring is.

Required for:

• internal mTLS

• accepting TLS connections

• mutual authentication

Clockspring always has a keystore because it always participates in TLS internally.

Truststore

Used to define who Clockspring trusts.

Required when:

• trusting other cluster nodes

• trusting the Registry

• calling external HTTPS services

• accepting TLS from a load balancer or client

Truststores are about incoming and outgoing trust, not identity.

Why Load Balancers Increase SSL Confusion

Load balancers introduce:

• multiple TLS termination points

• multiple certificate chains

• hidden trust boundaries

That’s why people see issues like:

• certificates working in dev but failing in prod

• Strict SSL Validation errors

• confusion over which cert goes where

The fix is always answering:

• which component is acting as the TLS server

• which certificates are for internal mTLS vs client access

Public vs Internal Certificates

Another common misunderstanding.

• Public certificates are for browsers and external clients

• Internal certificates are often issued by private CAs

• Internal CAs must be trusted explicitly

If a load balancer re-encrypts traffic using an internal CA, Clockspring must trust that CA.

What This Article Is Not

This article intentionally does not cover:

• how to generate certificates

• how to configure keystores or truststores

• load balancer–specific steps

Those belong in targeted, procedural how-tos.

Summary

Clockspring always uses TLS internally through mTLS.  That requirement does not change with load balancers. Load balancers only affect external client TLS, not internal security.

If you understand:

• where TLS terminates

• who is acting as the TLS server

• who needs to trust whom

Then SSL configuration stops being mysterious and becomes predictable.