SSL/TLS and Certificate Management
Concepts
TLS on the BIG-IP is built from three objects: a certificate (public key plus identity), a private key, and an SSL profile referencing them. The client SSL profile terminates inbound TLS; the server SSL profile initiates outbound TLS to pool members. Certificates can be created from a CSR, imported as PEM/DER/PKCS12, or self-signed for labs. Certificate and key must match, and the chain bundle should contain the leaf plus intermediates - never the root.
Device certificates (used by TMM for SSL profiles) and management certificates (used by the GUI and device trust) are separate objects; importing into the wrong type is a classic error. Profile settings that matter in questions: minimum and maximum TLS version, cipher string, renegotiation, SNI, OCSP stapling, and client certificate authentication.
Traps
- Importing a leaf without its intermediates: clients fail even though
opensslon the box succeeds. - Forgetting the key on import, or pairing a certificate with the wrong key.
- Editing the default
clientsslprofile; its cipher and version settings apply everywhere. - Leaving TLS 1.0/1.1 enabled when the scenario demands TLS 1.2 or higher.
- SNI scenarios with many certificates on one virtual server - the default profile cannot select per-name certificates without SNI enabled and a matching key pair per name.
- Certificate expiry silently breaking a service that nobody monitors.
Worked example
Terminate TLS with a purchased certificate:
- Generate a CSR on the BIG-IP and have the CA sign it.
- Import the signed leaf and intermediates together as one PEM, with the key.
- Create a child profile with parent
/Common/clientssl, select certificate and key, set the minimum TLS version, attach it to the virtual server.
Rule of thumb: leaf plus intermediates in one bundle, root omitted, custom profile always, and verify from outside with openssl s_client -connect vip:443 -showcerts.