# F5 SSL profile explainer > Paste a tmsh client-ssl or server-ssl profile and get its role, the TLS protocol matrix, and a security read covering chain, renegotiation, SNI, OCSP, and mutual TLS — all in your browser. - Tool: https://ronutz.com/en/tools/f5-ssl-profile-explainer - Family: TLS & transport --- ## What it does Paste a tmsh `client-ssl` or `server-ssl` profile and the tool explains it: the profile's role, the matrix of TLS protocol versions it enables and disables, and a security read covering the certificate chain, renegotiation, SNI, OCSP stapling, and mutual TLS. It parses the profile entirely in your browser and never contacts a device. ## Client-side and server-side profiles On a BIG-IP, SSL is handled by two kinds of profile, and the first thing the tool tells you is which one this is. A **client-ssl** profile terminates TLS coming from the client: the BIG-IP presents a certificate and decrypts the traffic. A **server-ssl** profile does the opposite: it initiates TLS toward the pool member, re-encrypting on the way out. A full-proxy TLS deployment uses both, decrypting from the client so it can inspect or steer the traffic, then re-encrypting to the server. Knowing the role frames everything else in the profile. ## The protocol matrix Which TLS versions a profile allows is set by its `options` field, which enables or disables specific versions. The tool renders this as a clear matrix so you can see at a glance whether, for example, TLS 1.0 and 1.1, deprecated by RFC 8996, are still enabled, or whether TLS 1.3 is on. This is often the single most important thing to check on an SSL profile, and it is easy to misread in the raw `options` bitmask. ## The security read Beyond protocols, the tool assesses the parts of the profile that decide how safe the TLS actually is: - the **certificate, key, and chain**, including whether the chain is complete; - **renegotiation**, and whether secure renegotiation (RFC 5746) is required; - **SNI** (RFC 6066), for serving the right certificate when several names share the profile; - **OCSP stapling** (the `status_request` extension, RFC 6066), which lets the server supply its own revocation proof; and - **peer certificate validation**, which is how mutual TLS is configured, where the BIG-IP requires and checks a client certificate. Each is rated so the risky settings stand out from the sound ones. ## Using it Paste a `client-ssl` or `server-ssl` profile block and read its role, its protocol matrix, and the security assessment of its chain, renegotiation, SNI, OCSP, and mutual-TLS settings. The analysis is deterministic and local. ## Standards and references - [F5 tmsh — ltm profile client-ssl reference](https://clouddocs.f5.com/api/icontrol-rest/APIRef_tm_ltm_profile_client-ssl.html) - client-ssl profile fields - [F5 tmsh — ltm profile server-ssl reference](https://clouddocs.f5.com/api/icontrol-rest/APIRef_tm_ltm_profile_server-ssl.html) - server-ssl profile fields - [RFC 5746 — TLS Renegotiation Indication Extension](https://www.rfc-editor.org/rfc/rfc5746) - secure renegotiation - [RFC 6066 — TLS Extensions: Server Name Indication and OCSP stapling](https://www.rfc-editor.org/rfc/rfc6066) - SNI, status_request (stapling) - [RFC 8996 — Deprecating TLS 1.0 and TLS 1.1](https://www.rfc-editor.org/rfc/rfc8996) - protocol deprecation ## Related reading - [Certificates, Keys, and Chain Building in an SSL Profile](https://ronutz.com/en/learn/f5-ssl-cert-key-chain.md): A client-ssl profile binds a server certificate to its private key and, crucially, to a chain bundle that lets clients build a path to a trusted root. The modern cert-key-chain construct also lets one profile serve several certificate types, picked per client — the foundation of RSA-plus-ECDSA and SNI deployments. - [Client SSL vs Server SSL Profiles on BIG-IP](https://ronutz.com/en/learn/f5-clientssl-vs-serverssl.md): A BIG-IP can sit in the middle of a TLS connection and decrypt it. A client-ssl profile makes the BIG-IP the TLS server to the client; a server-ssl profile makes it the TLS client to the pool. Knowing which side each profile owns is the key to offload, bridging, and re-encryption designs. - [Enabling and Disabling TLS Versions with the options Field](https://ronutz.com/en/learn/f5-ssl-profile-protocol-options.md): An SSL profile's options field is a list of flags, and the protocol flags work by SUBTRACTION: a TLS version is offered unless a matching no- flag disables it. That 'disable, not enable' logic is a frequent source of surprise, and it is where TLS 1.0/1.1 hygiene lives. - [Mutual TLS with peer-cert-mode](https://ronutz.com/en/learn/f5-ssl-client-auth-mtls.md): Most TLS proves the server to the client. Mutual TLS also proves the client to the server, and on a BIG-IP that is the job of peer-cert-mode plus a trusted-CA bundle. The gap to watch is the difference between requesting a client certificate and actually requiring and validating one. - [Post-Quantum TLS on BIG-IP: ML-KEM Hybrids From 17.5 to 21.1](https://ronutz.com/en/learn/bigip-post-quantum-tls.md): BIG-IP's post-quantum story is a lineage: X25519MLKEM768 hybrid key exchange arrived in the 17.5.0 era, and 21.1.0 completes the NIST curve family with SecP256r1MLKEM768 and SecP384r1MLKEM1024, on both client-side and server-side TLS, per FIPS 203. Around it, 21.1 makes the classical side faster and stricter: X25519 hardware acceleration via Intel QAT on by default, parent SSL profiles defaulting to TLS 1.3 and DTLS 1.2, an OCSP request nonce, and C3D enhancements. Here is what each piece means and how to roll it out without breaking a single legacy client. - [Renegotiation, Secure Renegotiation, and OCSP Stapling](https://ronutz.com/en/learn/f5-ssl-renegotiation-and-ocsp.md): Three SSL profile settings shape the handshake's safety after the first message: renegotiation decides whether a connection may renegotiate at all, secure-renegotiation enforces the RFC 5746 protection, and ocsp-stapling lets the BIG-IP attach a fresh revocation proof so clients need not phone the CA.