Certificates and TLS
Backend TLS
If your application listens on https rather than plain http, turn on TLS for the pool. Two further settings decide whether that connection is actually protecting anything.
The settings that matter
| Setting | What it does | Position |
|---|---|---|
| Use TLS | Speak https to the backends rather than http. | On when the backend needs it. |
| Verify the certificate | Check the backend is who it says it is. | On. This is the whole point. |
| Authority file | Which certificate authority to trust for backends. | Your company's authority file, if you issue your own. |
| Server name | The name to ask for in the handshake, when it differs from the address. | Set it when you connect by IP. |
The trap
A pool that fails the moment you turn on TLS
This is nearly always the certificate check. Prove it by turning the check off. Then put it back on and fix it properly with the authority file. Leaving the check off works, and it gives up most of the point of using https at all: an unverified TLS connection protects against passive listening and not against somebody in the middle.
When switching the check off is reasonable
One case, and it is narrow: a backend on the same machine, reached over the loopback address, using a certificate it made for itself. The traffic never leaves the box, so there is nobody to be in the middle. The management screen behind a name is exactly this case, which is why the guide for it says to turn verification off for that one pool.
Using your own certificate authority
If your organization issues its own certificates, put the authority file on the load balancers and point the pool at it. Then verification stays on and works, which is a much better answer than turning it off across the estate because one backend was awkward.
What it costs
A TLS handshake per backend connection, which is why connection reuse matters more here than anywhere else. With keep alive on, the handshake happens once per pooled connection rather than once per request, and the cost effectively disappears.
The other option
If the hop from the load balancer to the backend is inside a network you fully control, plain http on that hop plus a backend trust token is a reasonable arrangement and simpler to run. If that hop crosses anything you do not control, use TLS and verify it.
Common questions
Does the health checker use TLS too?
Yes, and it uses the same verification settings, so a check will fail for the same reason traffic would. That is deliberate: a check that succeeds where real traffic fails is worse than no check.
Can different members of one pool use different settings?
No. TLS settings belong to the pool. Members that genuinely differ belong in different pools.
What about mutual TLS to the backend?
A client certificate for the proxy connection can be configured through the raw config on the site, if your backend requires one.
Step by step instructions
The how to section has searchable, task shaped answers. Search it for backend tls.
Related features
Backend pools
The list of servers behind a site, and how traffic is shared.
Read moreBackend trust tokens
Prove to your own servers that a request came from the fleet.
Read moreActive health checks
Probe every backend on a schedule and pull the dead ones out.
Read moreThe tunnel
Reach a backend that has no public address at all.
Read more