SSL/TLS Offload and Certificate Management
Offload models
SSL/TLS offload terminates client TLS on the ADC, then forwards plaintext or re-encrypts to the server. Client-side SSL is configured on the virtual server port through a client SSL template; server-side SSL is configured on the service group or real server through a server SSL template. Re-encryption requires both.
Certificates
A working configuration needs a certificate, its matching private key, and usually the intermediate chain. Chain order matters: leaf certificate first, then intermediates; the root is normally omitted because clients already trust it. Import via GUI or CLI, and create a CSR on the device or externally when the key must not leave its source. Bind certificate and key to the template, and choose TLS versions and cipher sets deliberately rather than leaving legacy protocols enabled.
Traps
Common failures are a missing intermediate (browsers report an incomplete chain), a certificate and key that do not match, an expired certificate, or a template created but never bound to the VIP port. Another trap is enabling server-side SSL without a trusted CA bundle on the ADC, causing verification failures. SNI matters when one VIP serves multiple hostnames.
Rule of thumb
Test the chain from an external client, not just from the ADC. Worked example: a VIP serves two domains; add both certificates to the client SSL template and enable SNI so each client receives the correct leaf and chain, then verify with a TLS inspection tool that the chain is complete and the protocol version is acceptable.