Once a certificate is signed, load-balancer automation deploys it to every virtual server that needs it — and rolls back automatically if verification fails. It removes the human step between “certificate renewed” and “traffic served on the new certificate.”
Load Balancer Automation

​
What it is

You register your load balancers as targets in TigerTrust, and deployment subscriptions make the connection between a specific certificate and the virtual servers that should use it. On every successful renewal, TigerTrust pushes the new certificate to all subscribed load-balancer targets and verifies the TLS handshake before marking the deployment complete.

​
When to use it

  • Automatically deploy renewed Let’s Encrypt certificates to F5 BIG-IP virtual servers without an operator.
  • Keep an AWS ALB listener current after each renewal without an ACM import step.
  • Detect load balancers that have drifted from the certificate TigerTrust believes should be installed and re-deploy automatically.

​
Supported target types

TypeAuth
F5 BIG-IPUsername/password or API token
NGINX PlusToken
HAProxyBasic auth or token via dataplane API
AWS ALBIAM role or access key
Azure Application GatewayManaged identity or service principal
Citrix ADCSession cookie
Kubernetes Ingress (NGINX)Kubeconfig

​
Set it up

1

Register a load balancer

Go to Infrastructure > Load balancers and click Add load balancer. Enter the type, host/endpoint, port, and credentials. Click Save.
2

Sync the load balancer

Click Sync on the load balancer row. TigerTrust connects to the load balancer, discovers its virtual servers and currently-installed certificates, and records them. This establishes the baseline.
3

Create a deployment subscription

Open the certificate you want to auto-deploy and go to its Deployment tab. Click Add target, select the load balancer, choose the virtual server, and toggle Auto-deploy on renewal. TigerTrust will push the certificate to this virtual server on every subsequent renewal.
4

Deploy immediately

Click Deploy now to push the certificate to the target right away. TigerTrust uploads the certificate bundle, binds it to the virtual server, and opens a TLS handshake to verify the new fingerprint is being served.

​
What you’ll see

Infrastructure > Load balancers shows each registered load balancer with last-sync timestamp and health status. Click a load balancer to see its virtual servers and the certificate currently installed on each one. Deployment history shows a timeline of every deployment attempt with per-VIP status and logs.

​
Periodic drift detection

TigerTrust checks every registered load balancer on a 10-minute cycle. If a virtual server is serving a certificate that differs from what TigerTrust expects (for example, due to an out-of-band change), a re-deployment is queued automatically. This catches half-applied rollouts and manual overrides.

​
Rollback

Every deployment records the previous certificate before overwriting it. If more than a configurable percentage of virtual servers fail their TLS handshake verification, TigerTrust re-uploads the previous certificate to all affected targets and marks the batch as rolled_back.
Rolling back to an expired certificate is not possible. If the previous certificate is already outside its validity window, TigerTrust leaves the failed targets on the new certificate and raises a critical alert instead.
Credentials for load balancers are stored encrypted. The plaintext is only held in memory for the duration of a single deployment operation.

Renewal automation

Where deployment jobs originate after a successful renewal.

Alerts

Configure alerts on deployment.failed events.

Workflows

Add pre- and post-deploy hooks — drain, deploy, health-check.