A BIG-IP virtual server can do something a plain router cannot: terminate a TLS connection, look inside the cleartext, and open a fresh TLS connection to the backend. Two different profile types govern the two halves of that picture, and they play opposite roles.

Client SSL: the BIG-IP is the server

A client-ssl profile faces the client. With it attached, the BIG-IP acts as the TLS server: it presents a certificate, completes the handshake the browser started, and decrypts the client's traffic. This is the profile that holds your public-facing certificate and private key. Everything the client sees about your site's TLS (the certificate, the negotiated version, the cipher) comes from here.

Server SSL: the BIG-IP is the client

A server-ssl profile faces the pool member. With it attached, the BIG-IP acts as the TLS client toward the backend: it opens a new TLS connection to the server and, if configured, validates the server's certificate against a trusted (certificate authority). The backend sees the BIG-IP as just another TLS client.

Three common shapes

These two profiles combine into the patterns you will actually deploy:

  • SSL offload: a client-ssl profile only. The BIG-IP terminates client TLS and talks cleartext to the pool. Simplest and fastest, but the server leg is unencrypted, so it is only safe on a trusted internal segment.
  • SSL bridging (re-encryption): both a client-ssl and a server-ssl profile. The BIG-IP decrypts from the client, can inspect or modify the traffic, then re-encrypts to the pool. This is what you need when policy or compliance requires encryption end to end while still allowing layer 7 processing.
  • SSL pass-through: neither profile. The BIG-IP forwards the encrypted bytes untouched. No certificate, no inspection, no layer 7 features.

Why the distinction matters

A surprising number of TLS tickets come down to attaching the wrong profile to the wrong side, or expecting the backend to be validated when only a client-ssl profile is present. Validation of the backend server certificate is a server-ssl concern (peer-cert-mode plus ca-file); validation of a client certificate is a client-ssl concern. When you read a profile, the first question to settle is always: which side does this one own?

Paste either profile into the SSL profile explainer and it will tell you its role, the protocol versions it permits, and what each setting does.

This series, in order

This article opens the series BIG-IP SSL profiles and ciphers. It settles which profile is the server to the client and which the client to the pool; the parts then configure a profile from the outside in: its certificate and chain, the versions it offers, the cipher configuration read as a grammar, a rule set and an order, the secrecy and safety that follow from it, the client certificate, the newest key exchange and the certificate automation, and the product built to decrypt once and inspect many times.

  1. Certificates, Keys, and Chain Building in an SSL Profile. The certificate, its key and the chain bundle that lets a client reach a trusted root, and one profile serving several certificates.
  2. Enabling and Disabling TLS Versions with the options Field. The options field works by subtraction: a version is offered unless a no- flag removes it.
  3. Reading an F5 Cipher String. Colon-separated sets, keywords joined by plus, and the operators that exclude, delete or demote.
  4. F5 Cipher Rules, Cipher Groups, and Why Expansion Is Version-Specific. Rules that hold strings and groups that allow, restrict and exclude them, and why expansion depends on the version.
  5. Cipher Ordering and Negotiation on BIG-IP. With server preference, the first cipher in the BIG-IP's own list that the client supports wins.
  6. The two TLS cipher generations on BIG-IP. One generation bundles key exchange, authentication and cipher; the newest names only the cipher and hash.
  7. Enforcing Forward Secrecy on F5 BIG-IP. Not a checkbox but a consequence of the cipher configuration: ephemeral key exchange or none.
  8. Renegotiation, Secure Renegotiation, and OCSP Stapling. Whether a connection may renegotiate, the secure renegotiation that protects it, and stapling the Online Certificate Status Protocol () answer to the handshake.
  9. Mutual TLS with peer-cert-mode. peer-cert-mode and a trusted CA bundle, and the gap between requesting a client certificate and requiring one.
  10. Post-quantum TLS on BIG-IP: the ML-KEM hybrids. The hybrid key exchange lineage on BIG-IP, from the first hybrid to the full curve family.
  11. ACME on BIG-IP: from DevCentral scripts to a native client. From community scripts to a native client: issuance, renewal and deployment for any ACME authority.
  12. F5 SSL Orchestrator: Forward and Reverse Proxy Topologies. Decrypt once and steer through a chain of security devices: the forward and reverse proxy topologies.