Software load balancer with TLS re-encryption

Automate certificates on both sides of a software load balancer while keeping client-to-backend traffic encrypted.

In this architecture, the software load balancer terminates the user-facing TLS connection, then establishes a separate encrypted TLS connection to the backend web servers. As a result, both the load balancer and each backend server require their own certificates. DigiCert Trust Lifecycle Manager (TLM) centralizes certificate lifecycle management, while DigiCert agents perform certificate operations locally on supported server applications.

Software load balancer with TLS re-encryption diagram

High-level deployment concept: user traffic remains separate from certificate-management traffic. Agents initiate outbound management connections to DigiCert ONE / TLM. No inbound management session from TLM is required.

Why this scenario matters

TLS re-encryption creates two certificate-dependent connections: one between the client and the load balancer, and another between the load balancer and the backend web servers. If a certificate expires or is deployed incorrectly on either side, application traffic can be disrupted even if the other certificate remains valid.

As public TLS certificate lifetimes get shorter, renewals happen more often, making manual renewal, installation, and service reload processes harder to sustain. The operational challenge goes beyond certificate issuance, as every renewed certificate must be installed in the right location, loaded by the application, and monitored after deployment to ensure traffic continues uninterrupted.

How DigiCert fits

Centralized lifecycle management — use TLM to manage certificate inventory, policy, automation status, ownership, and lifecycle visibility across the environment.
Agent-based server automation — DigiCert agents run on the systems that host managed certificates and initiate outbound HTTPS connectivity to DigiCert TLM.
Two certificate layers — manage the load balancer certificate and the certificates on supported backend web servers as distinct deployment targets.
Flexible integration model — use managed automation for supported server applications. Other software load balancers may require a custom-server workflow, post-script, or third-party ACME client; verify the current integration guidance.

At a glance

Environment: a Linux-based software load balancer that terminates user TLS and re-encrypts traffic to backend web servers. Both layers use certificates.
DigiCert deployment model: DigiCert agent on the load balancer host when the application is supported. DigiCert agent on each supported backend web-server host. Other software load balancers may use a custom-server or third-party ACME workflow.
Management connectivity: agents initiate outbound HTTPS (TCP 443) to the required DigiCert ONE / TLM and automation service endpoints, directly or through a supported proxy configuration.
Typical validation approach: DNS-based DCV is often a strong fit because it avoids opening inbound HTTP solely for certificate validation. HTTP-01 may be used when the application and network design support it.
What to verify before deployment: supported OS and application versions, certificate locations, DNS/DCV requirements, proxy rules, certificate profiles, reload/restart behavior, and trust requirements for the backend TLS connection.

Technical implementation details

DigiCert provides agent-based managed automation support for Apache HTTP Server, Apache Tomcat, IBM HTTP Server, NGINX, and Microsoft IIS deployments. Software load balancers such as HAProxy, Traefik, Seesaw, Neutrino, or other platforms may require a custom-server workflow, post-script, verified integration, or third-party ACME client. Confirm the current integration method and supported version before deployment.

For the load balancer host, the certificate must be installed where the load balancer expects it, and the running process must load the new certificate. Depending on the software, this may require a graceful reload, service restart, configuration reload, or custom post-install action. Test this behavior rather than assuming a successful certificate renewal automatically changes the certificate being served.

For backend TLS, the load balancer acts as a TLS client to the backend servers. Verify how it validates backend server certificates, including trust anchors, server-name validation, SNI, certificate names, and any private-CA requirements. These settings are part of the application architecture, not TLM-specific behavior.

DigiCert agents, proxy settings, supported operating systems, application versions, DNS integration requirements, and automation procedures can change. Use the current DigiCert documentation when planning firewall rules and implementation steps.

Managed automation solution — learn how to set up and manage automated certificate lifecycle operations, such as issuance, renewal, and installation across enterprise networks.
Integration guides for Trust Lifecycle Manager — check the integration methods DigiCert documents for NGINX, custom server applications, HAProxy, and other platforms.
Supported systems — verify out-of-the-box supported operating systems and web-server versions for agent-based managed automation. DigiCert has the ability to customize other integrations.
Agent system and network requirements — review outbound HTTPS, proxy, DNS, local-host, and installation requirements for DigiCert agents.
Managed automation workflow — understand how agents, certificate profiles, DNS integrations, and managed endpoints fit together.
ACME automation service — evaluate third-party ACME for software load balancers that are not a native managed-automation target.
DNS integrations — review DNS integration options for automated domain control validation.
Deploy certificates for custom applications — example scripts for popular systems including HAProxy.

Frequently asked questions

Does TLS terminate at the software load balancer in this scenario?

Yes, the client TLS session terminates at the load balancer. The load balancer then establishes a separate TLS session to the backend web server. This is called TLS re-encryption or TLS bridging. It is not TLS passthrough.

Do the backend web servers need their own certificates?

Yes, because the load-balancer-to-backend connection is encrypted in this scenario, each backend server must present a certificate that the load balancer is configured to accept and trust.

Does every backend server need a DigiCert agent?

For DigiCert agent-based managed automation, the agent runs on the server system that hosts the certificates being managed. A separate agent is therefore expected on each backend host that is managed this way. Agents can connect directly to DigiCert TLM or use a supported proxy configuration.

Does TLM require inbound management access to the load balancer or backend servers?

The DigiCert agent requires outbound HTTPS connectivity to DigiCert TLM and related services. TLM does not require an internet-initiated inbound management session to the agent. Refer to the current network requirements for exact endpoints and proxy options.

Can DigiCert automate any Linux software load balancer?

It depends on the software load balancer, operating system, and version. DigiCert provides managed agent-based automation for specific supported server applications and versions, including supported versions of NGINX on Linux. For other Linux-based software load balancers or custom server applications, DigiCert supports additional automation approaches. Trust Lifecycle Manager can use DigiCert Agent automated delivery with custom post-delivery scripts, or organizations can use ACME where appropriate.

Ready to evaluate your environment?

See how DigiCert Trust Lifecycle Manager can support certificate lifecycle automation across your enterprise.

Explore DigiCert Trust Lifecycle Manager Talk to DigiCert