Short answer
On F5 BIG-IP a Client SSL profile terminates TLS from the client (it holds the public certificate and its key as a cert-key object). A Server SSL profile controls TLS towards the backend. Attach only a Client SSL profile to your virtual server and the BIG-IP does offloading. Attach both and it does bridging (re-encryption). With no SSL profile at all it is pure passthrough.
The two profile types
| Profile | Direction | Contains |
|---|---|---|
| Client SSL | BIG-IP ← client | Server certificate + key (cert-key), chain, ciphers |
| Server SSL | BIG-IP → backend | Trust/validation of the backend, optional client certificate for mTLS |
The cert-key object
The certificate and its private key are imported as separate objects under the SSL Certificate List and then bound together in the Client SSL profile. Remember to import the full chain (intermediates) in the profile's Chain field, or the BIG-IP serves only the leaf certificate and non-browser clients fail with "unable to get local issuer certificate". With tmsh:
# Import key and certificate
tmsh install sys crypto key example.com.key from-local-file /var/tmp/privkey.pem
tmsh install sys crypto cert example.com.crt from-local-file /var/tmp/fullchain.pem
# Create a Client SSL profile binding cert + key + chain
tmsh create ltm profile client-ssl example_clientssl \
cert example.com.crt key example.com.key chain ca-bundle.crt \
ciphers "ECDHE+AES-GCM:ECDHE+CHACHA20" \
options { no-tlsv1 no-tlsv1.1 no-sslv3 }
Offloading vs bridging on BIG-IP
Which profiles you attach to the virtual server decides the architecture — exactly as described in offloading vs passthrough vs bridging:
- Offloading: a Client SSL profile only. The BIG-IP decrypts and sends cleartext to the backend.
- Bridging: both Client SSL and Server SSL. The BIG-IP decrypts, can run iRules/WAF, and re-encrypts towards the backend.
- Passthrough: no SSL profile. The encrypted stream passes untouched to the backend, which terminates itself.
# Bridging: attach BOTH client-ssl and server-ssl to the virtual server
tmsh modify ltm virtual vs_https \
profiles add { example_clientssl { context clientside } \
example_serverssl { context serverside } }
Server SSL and backend validation
With bridging, the Server SSL profile should actually validate the backend certificate (server-name and a CA bundle), not just encrypt blindly. Otherwise the backend leg is encrypted but not authenticated. The backend certificate is — as with Azure end-to-end TLS — the one most often forgotten, because it is not public.
mTLS and client certificates
If clients must present a certificate, you set Client Certificate: require and a trusted CA in the Client SSL profile. Conversely, if the BIG-IP must present a client certificate to the backend, it goes in the Server SSL profile. More on the pattern in mTLS in Kubernetes — the principle is the same.
How CertControl keeps track of your BIG-IP certificates
A BIG-IP quickly accumulates many Client SSL profiles, each with its own cert-key object and its own expiry date — plus the internal Server SSL/backend certificates on top. CertControl scans all the virtual servers from the outside, confirms the chain is served complete and the protocols are modern, and warns before any of the certificates expire. See also the ACME pillar on automating renewal and rotation without downtime when a new cert-key object goes into use.
Frequently asked questions
What is the difference between a Client SSL and a Server SSL profile?
The Client SSL profile terminates TLS from the client and holds your server certificate and key. The Server SSL profile controls TLS from the BIG-IP towards the backend. The two profiles are independent and attached separately to the virtual server.
How do I do offloading vs bridging on BIG-IP?
Offloading: attach only a Client SSL profile to the virtual server. Bridging: attach both a Client SSL and a Server SSL profile. No SSL profile at all gives pure passthrough.
What is a cert-key object?
The certificate and the private key are imported as separate objects on the BIG-IP and bound together in the Client SSL profile. Remember to also put intermediates in the profile's Chain field so the full chain is served.
Why doesn't my BIG-IP serve the full chain?
Because the intermediate certificates are not set in the Client SSL profile's Chain field. Without them the BIG-IP sends only the leaf certificate and non-browser clients fail. Add the chain in the profile.
Can BIG-IP handle mTLS?
Yes. Client mTLS is set in the Client SSL profile (Client Certificate: require + a trusted CA). If the BIG-IP itself must present a client certificate to the backend, it goes in the Server SSL profile.