Certificate Lifecycle Management for F5 BIG-IP

Certificate lifecycle management for F5 BIG-IP is the automated discovery, issuance, renewal and installation of the TLS certificates bound to your client-SSL profiles — without an engineer logging into the Configuration utility. PKI Insights runs this entirely inside your own network. It enumerates the SSL profiles on each BIG-IP, renews from the certificate authority you already use, and installs the result. Private keys are generated on the agent host and never leave it.

What happens on a BIG-IP when a certificate expires

Nothing. That is the problem.

A client-SSL profile presents the cert-key-chain it was configured with on the day it was built. BIG-IP does not watch the expiry date, request a replacement, or swap the chain. Until an engineer imports a new certificate and key, edits the profile and saves the configuration, every virtual server using that profile serves an expired certificate to every client that connects.

The procedure itself is not difficult. What changes is how often it has to run. Public TLS certificate lifetimes are contracting on a schedule set by the CA/Browser Forum, and each reduction multiplies renewal volume against an estate that keeps growing. Internal certificates issued by a private CA — usually the majority of what a BIG-IP estate actually serves — sit outside that schedule entirely, which tends to mean they are tracked even less carefully than the public ones.

Read the full analysis: The 100-day deadline lands March 2027

Either way it is the same operation, repeated across every profile in the estate, indefinitely. That is what automation is for — provided you know what is in the estate to begin with.

Start with what is actually there

Most F5 estates cannot produce an accurate list of the certificates they are serving. Profiles get built for a migration and never decommissioned. A wildcard is imported once and bound in four places. A virtual server nobody owns quietly terminates TLS for something that turned out to matter.

Automating renewal across an inventory you have not verified renews the certificates you happened to remember.

PKI Insights begins with discovery, not renewal. Network discovery scans a CIDR block or a list of endpoints across a port range, connects to everything presenting a certificate, and records the endpoint, port, certificate details, key information, purpose and days to expiry. Anything found that is not already under monitoring is flagged and exported as CSV, ready to import straight into monitoring or renewal.

Run it against the segments your BIG-IPs front before you configure a single renewal. The gap between what discovery returns and what your inventory says is the real measure of exposure.

How PKI Insights reaches the BIG-IP

A PKI Insights Agent is installed on a host inside your network with a route to the BIG-IP management address. The agent does the work: it generates the key pair, builds the CSR, obtains the certificate, and installs it on the appliance. There is no software to install on the BIG-IP itself.

A renewal scan target for F5 is configured with the BIG-IP base URL and the credentials the agent will use to reach it over iControl REST. Fetch SSL Client Profiles then queries the appliance and returns the client-SSL profiles it is running. You select the profiles that come under automated renewal and leave the rest alone.

That last step is the difference worth understanding. Competing products require an operator to map each virtual server to its client-SSL profile by hand, as a prerequisite, before automation can begin — a task that is both laborious and the single most common source of a certificate landing on the wrong profile. PKI Insights reads the profile list off the appliance. The mapping is not something you maintain in a spreadsheet and transcribe into a console; it is fetched from the device that holds the truth.

On renewal, the agent uploads the new certificate and key and replaces the cert-key-chain on the existing client-SSL profile in place. The profile object itself does not change; its contents do. Every virtual server already bound to that profile serves the new certificate from that moment — no rebinding, no new profile to attach, no service restart, no dropped connections.

The account itself does not need to be a full administrator. The credentials the agent uses require only enough privilege to upload certificate and key objects and to update the client-SSL profiles under management. Scope a dedicated automation account to those permissions rather than reusing an existing administrative login, and the renewal path has no ability to change anything else on the appliance.

Appliance connectivity can be held in two places. Configure it as a connector in PKI Insights and reference it from any scan target that needs it. Or hold it on the agent and use Fetch Remote Device Connectors From Agent to pull the connector definitions in, so the appliance credentials never reside in the management platform at all. The second option exists for security teams who will not permit BIG-IP credentials to be stored anywhere outside the network segment the appliance sits in.

Where the keys are, at every step

The private key is generated on the agent host and never leaves it. Key, CSR and the assembled PEM or PKCS#12 are written to a fixed path under the agent’s own installation directory, one folder per scan target and one per renewal event, so nothing collides and every event is traceable:

<agent installation folder>/clm/<scan target name>/secrets-<cert common name>-<date-time>

Keys are pruned on a retention schedule (clm_keys_retention_days, default 180 days), so material does not accumulate on the host indefinitely.

What crosses the network is the CSR going out and the issued certificate coming back. Both are public objects. The key itself is never transmitted to PKI Insights, never transmitted to a vendor cloud, and never leaves the segment the agent sits in.

Which component talks to your CA depends on the CA:

For ADCS, PKI Insights communicates with the CA directly from a domain-joined server; no agent is involved in issuance. For every other authority the agent holds the credentials and makes the call.

Deployment prerequisite for ADCS: the PKI Insights server must be domain-joined, have a network path to the issuing CA, and hold enrolment rights on the template you intend to use. In a segmented estate that makes placement a design decision — the platform inside the domain, agents out in the DMZ and appliance segments.

Bring the certificate authority you already have

Most CLM platforms are built around a preferred authority, and the further you move from it the more the automation degrades. Sectigo’s product exists alongside Sectigo’s certificates. DigiCert’s exists alongside DigiCert’s. Several competing integrations steer new deployments toward a free public CA because that is the path their automation handles best.

A real F5 estate does not look like that. Internet-facing virtual servers need publicly trusted certificates from the CA you hold a contract with. Internal virtual servers, management interfaces and service-to-service TLS behind the perimeter are issued from your own PKI — usually Microsoft ADCS — where public trust is irrelevant and a public CA cannot issue at all.

PKI Insights treats the CA as an interchangeable component. Public certificates from DigiCert or Sectigo on the edge, internal certificates from ADCS, EJBCA or HashiCorp Vault behind it, both in one inventory with one renewal engine and one set of expiry dates.

That last point matters more than it sounds. When the public certificates renew on one system and the internal ones renew on another, the gap between the two inventories is where outages live.

Automating F5 renewal from Microsoft ADCS

ADCS has no native ACME responder. Every CLM platform built on ACME therefore has one of three answers when your F5 certificates come from an internal Microsoft CA: stand up an ACME front-end for ADCS, fall back to NDES and SCEP, or move the certificates to a public CA instead. The first is a project, the second carries its own security baggage, and the third is not available for internal names at all.

PKI Insights issues from ADCS using certutil against the CA directly, with the certificate template named in the scan target. No ACME layer, no protocol gateway, no change to the CA.

For most enterprises the majority of certificates on a BIG-IP estate — internal virtual servers, management access, everything that never faces the internet — are ADCS-issued. That is the volume. It should not be the part your automation cannot reach.

Configuring a renewal scan target

The scan target defines what gets renewed, when, from which CA and in what form.

Scheduling. Set Auto-Renew (Days before Expiry) to the lead time you want, and the daily time the check runs. PKI Insights raises CERT_ABOUT_TO_RENEW and notifies the certificate owner one day before the renewal executes, so the change is never a surprise.

Identity. Provide the SAN values explicitly, in DNS:, IP: or Email: form, and the subject DN. Subject elements supported include CN, O, OU, C, L, ST, S, P, SERIALNUMBER, UID, E and business category.

Cryptography. Key type RSA or ECDSA, with curve and size, and the hash algorithm used for the CSR.

Chain packaging. Choose whether the delivered certificate is the leaf alone, the full chain excluding the root, or the full chain including the root — a decision that matters on a BIG-IP, where an incomplete chain produces intermittent client failures rather than an obvious outage.

Certificate authority. Select the CA connector that will issue. Where the CA requires it — ADCS in particular — name the template.

Zero-touch, or staged for a change window

Apply Certificate Automatically is a toggle, and it is worth knowing it exists before you assume it has to be on.

Left enabled, the renewal runs end to end without intervention: issued, delivered, installed.

Turned off, PKI Insights renews the certificate and holds it. The new certificate appears in the Certificates section and an administrator applies it when they choose — inside an approved change window, after a CAB, or alongside the rest of a scheduled maintenance slot.

Most of this market sells zero-touch as the only mode. For a regulated environment where a change to a production load balancer requires an approved window regardless of how safe the change is, that is not a feature, it is an obstacle. Being able to separate issuance from application means the renewal is prepared automatically and applied under whatever governance your organisation actually operates.

Verification, alerting and audit

An automated renewal that reports success has told you the script finished. It has not told you what the virtual server is serving.

Point Network Monitor at the published virtual server and PKI Insights connects to the live endpoint and grades what it finds: expiry, weak key or signing algorithm, certificate lifetime against CA/Browser Forum guidance, RFC 5280 and CA/B linting, TLS protocol and cipher suite conformance from SSLv2 through TLS 1.3, and post-quantum readiness of the handshake. Endpoints are graded A+ through F, with X where no certificate was found at all. Each endpoint carries a certificate history showing every certificate that has been served at that address over time.

The renewal path raises its own alerts — CERT_ABOUT_TO_RENEW, CERT_ISSUED, CERT_RENEWED, CERT_RENEWAL_FAILED — with the failing CSR available against the alert for diagnosis. Daily renewal summaries and per-owner certificate reports go out by email, and operator logs record who changed which scan target, when, and what the previous value was.

Between the renewal record and the endpoint grade you have both halves of the evidence an auditor asks for: that the certificate was renewed, and that the renewed certificate is the one in production.

When there is no native connector

F5 is a supported appliance type with a built-in integration. Not everything in an estate is.

For systems PKI Insights does not natively connect to — a bespoke application storing its certificate somewhere proprietary, an appliance reachable only through a jump host, a platform your organisation runs and nobody else does — the CLM module is extensible with scripts, in PowerShell or bash, configured inside the same scan target as everything else.

The platform still performs every security-sensitive step. Discovery, key generation, CSR creation, CA communication, format conversion and renewal scheduling all remain with PKI Insights and the agent. Only the final handover is delegated.

Scripts receive their input as base64-encoded JSON in the PKI_INSIGHTS_SCRIPT_DATA environment variable — never on the command line, which keeps operator-supplied arguments out of process listings and shell history. Up to fifteen arguments are stored encrypted, so credentials and tokens are safe to pass. Delivered files are named explicitly (certFile, keyFile, chainFile, pfxFile) rather than left to be identified by array position or file extension.

Four phases run, each with its own editable timeout: discovery, pre-installation, certificate delivery and post-installation. A script that returns non-zero is reported as a failing script, distinctly from an agent fault — so an operator is never told the agent is unreachable when their script simply exited.

A scripted endpoint appears in the same console, with the same expiry countdown and the same renewal history, as a natively integrated one. Support for a new platform does not require waiting for a release.

Why not run ACME on the BIG-IP?

Answering ACME challenges from the appliance itself looks simpler than it is.

HTTP-01 means maintaining a responder or iRule for the challenge path on every virtual server that terminates a domain you need to validate — configuration that has to be correct on the day of renewal, on every virtual server, indefinitely.

DNS-01 means placing DNS provider credentials on the device that terminates TLS for your applications. A BIG-IP is already one of the highest-value targets in the estate. Adding the ability to create arbitrary DNS records to its credential set is a privilege escalation waiting for the right attacker.

Both options also assume the appliance can reach a public CA, which rules out every internal virtual server and every segmented network — precisely where most of the certificates are.

Scripting it yourself has its own sharp edges: API automation against the management interface, credential handling, chain assembly, keeping the renewal working after the next BIG-IP upgrade, and the ownership question that surfaces the day the engineer who wrote it changes role.

PKI Insights keeps the key generation, the CA communication and the installation inside one audited, monitored path, with no ACME client, no DNS credentials and no scheduled task on the appliance.

F5 BIG-IP is one part of the estate

The same agent, the same inventory and the same renewal engine cover the rest of what terminates TLS in your environment: Citrix NetScaler, FortiWeb and HAProxy at the edge; IIS, NGINX, Apache Tomcat and Oracle WebLogic behind it; Microsoft SQL Server, PostgreSQL and MySQL in the data tier; ADFS, Exchange and RDP across Microsoft infrastructure; Citrix StoreFront and RabbitMQ alongside.

See all supported platforms

Certificate lifecycle management is only half the problem

Automating renewal on a PKI you have not assessed propagates misconfiguration faster than it fixes it. Weak templates, excessive enrolment permissions, improper key usage and the ADCS ESC escalation paths are not corrected by automation — they are renewed on schedule, four times a year, with less human review at each step.

Automation keeps certificates alive. Posture keeps trust intact.

PKI Insights combines certificate lifecycle management with continuous PKI posture assessment across ADCS, EJBCA, Microsoft Cloud PKI and HashiCorp Vault, HSM monitoring, and post-quantum readiness across certificates, endpoints and issuing infrastructure.

What should enterprises prioritise first: PKI CLM or PKI Posture?