How Versus discovers, inventories, and operates F5 BIG-IP client-ssl and server-ssl profiles — the cert, key, and chain bindings behind every HTTPS virtual server — and how certificate renewals reach them by overwriting a bound cert object or minting a new one and rebinding the profile.
On an F5 BIG-IP, a virtual server doesn't hold a certificate directly — it references an SSL profile, and the profile is what binds a certificate, private key, and chain. Versus imports these profiles as first-class inventory objects so you can see which certificate every HTTPS virtual server actually presents, what references each profile, and — when a certificate renews — push the new material to exactly the right place without hand-editing the box.
BIG-IP has two profile sides, and Versus models both:
Each profile Versus imports is a TLSProfile record scoped to a single device. It carries only what's needed to reason about the TLS binding — not the profile's full cipher configuration:
| Field | Meaning |
|---|---|
device | The BIG-IP this profile lives on |
name | Profile name (leaf, e.g. app_https_clientssl) |
partition | F5 partition, default Common |
side | client (client-ssl) or server (server-ssl) |
cert | The cert object the profile is bound to |
key | The key object the profile is bound to |
chain | The chain/bundle object, if any |
A profile is unique per (device, partition, side, name). Versus deliberately keeps this record lighter than the virtual server's full profile list — it's the only source that carries the cert/key/chain references cleanly, which is what certificate lifecycle needs.
Profiles are populated during F5 import. Versus reads the two LTM profile collections directly off the BIG-IP iControl REST API:
GET /mgmt/tm/ltm/profile/client-ssl
GET /mgmt/tm/ltm/profile/server-ssl
For each side, it upserts a TLSProfile from the returned name, partition, cert, key, and chain, then removes any local profile that no longer exists on the device. Import is read-only and reconciling: what's on the box is the source of truth, and a re-import brings the inventory back in line — including deletions.
Import runs through the same outbound-only collector path as the rest of F5 discovery, so Versus never needs an inbound route to your BIG-IP. See F5 BIG-IP Integration and Collector Security.
Imported profiles are available in the ADC workspace and over the API. The collection is read-only:
GET /api/tls-profiles/
GET /api/tls-profiles/?device=42&side=client
GET /api/tls-profiles/?partition=Common&search=app_https
You can filter by device, partition, and side, and search by name or cert. Each profile in the response is annotated with two computed fields:
referenced_by — the virtual servers that actually use this profile. Because BIG-IP stores no back-reference, Versus re-derives it the way the box does at config-apply time: it scans each virtual server's imported profile list for an entry matching this profile's name in the matching context (clientside for client-ssl, serverside for server-ssl). This tells you, at a glance, whether a profile is live or orphaned.is_builtin — whether this is an F5 system default (/Common/clientssl, /Common/serverssl, /Common/clientssl-insecure-compatible, and the other shipped profiles), so stock objects aren't mistaken for something you configured.The reverse view is available from a certificate: a discovered device certificate lists the TLS profiles on the same device whose cert or chain names it — so you can see every profile a given certificate feeds before you touch it.
The reason Versus tracks these bindings is certificate lifecycle. When a managed certificate renews, the new key material has to land on the BIG-IP and the right profile has to point at it. Versus does both, and it picks the targets for you.
Given a renewed certificate, Versus matches its CN and SANs against every discovered F5 device certificate, then finds the client-ssl / server-ssl profiles bound to those certs. The result is a precise target list — device, profile, and the exact cert object the profile currently serves — so a deploy touches only the profiles already serving that certificate, and nothing else.
[
{
"device_id": 42,
"device": "bigip-dc1-a",
"profile_name": "/Common/app_https_clientssl",
"cert_object_name": "app.example.com",
"side": "client"
}
]
Each F5 target is pushed in one of two modes, chosen per certificate (or overridden at deploy time):
| Mode | What happens on the BIG-IP |
|---|---|
overwrite | The bound cert object is replaced in place — the leaf+chain bundle is uploaded to /sys/file/ssl-cert and the key to /sys/file/ssl-key under the existing name. The profile is untouched because it already points at that object. |
rename_update | A new cert object is created (default name <cert>_<year>), then the client-ssl profile is patched to bind the new cert and key. This keeps a dated history of cert objects on the device — the Venafi-style pattern. |
On F5, the leaf and chain are always uploaded as a single bundled cert file, since BIG-IP presents the full chain from one object. The profile rebind in rename_update is a targeted PATCH to the client-ssl profile that sets its cert and key references to the new object:
PATCH /mgmt/tm/ltm/profile/client-ssl/~Common~app_https_clientssl
{ "cert": "/Common/app.example.com_2026", "key": "/Common/app.example.com_2026" }
Deploys run collector-aware: for a site-bound BIG-IP on a private LAN, the write routes through the collector tunnel; for a directly reachable device, it's a direct REST call. Either way the certificate and key never leave your network — they're resolved from the Versus Vault at deploy time.
Certificate deployment isn't a one-off button — it's the Deploy Managed Certificate workflow, which pushes an issued certificate to every managed device/SSL profile that serves it (overwrite in place, or new-name + rebind) with an approval gate, post-deploy TLS verification, and back-out. Each push is recorded as a certificate-deployment record against the device and profile, capturing the exact cert object written, the status, who ran it, and any error. See Certificate Management and Running Workflows via the API.
The same deploy dispatcher also serves NetScaler, Avi, A10, KEMP, and the cloud WAF/CDN providers — F5 is one target vendor among several, so a single renewal can fan out across a mixed estate.
Because Versus knows what each profile binds and what references it, it can flag problems that are easy to miss on a large BIG-IP:
referenced_by isn't attached to any virtual server. Versus's unused-object analysis flags client-ssl / server-ssl profiles (and the certs and keys they'd otherwise pin) that no virtual server uses, while skipping the F5 system defaults so stock objects aren't reported as dead.common.secureHandshakes, summed across profiles) and charts the secure-handshake rate, so a profile's real traffic is visible next to its configuration.Versus models the TLS binding — cert, key, chain, side, and references — not the profile's full cipher and options config. It won't invent a profile's cipher string or protocol settings from partial data; it operates on what the device reports. Creating brand-new virtual servers with their SSL profiles from scratch is handled through the AS3 and site-build paths (where an HTTPS service is generated with a serverTLS binding), covered in AS3 Deployments — this page is about discovering and operating the profiles that already exist and keeping their certificates current.