Following up on the F5 post from a month ago. Quick update for anyone tracking it.

Website: https://certctl.io

Every commercial CLM platform ships a control plane that natively integrates with maybe 60% of what the customer actually runs. The other 40%, the load balancers, the app servers, the in-house systems, the regional CAs, the niche issuance protocols, gets bridged via custom plugin frameworks. Those plugins exist *because the platforms didn't ship native connectors*. They get written by professional-services architects on the vendor's payroll, billed back to the customer at $250–$400/hr, hundreds of hours in year one alone, on top of a six-to-seven-figure license. The job titles vary by vendor. Solutions Architect, Implementation Architect, Accelerator Architect, Digital Trust Architect, but the work is identical: write the integration the platform should have shipped with.

What's shipped end to end for F5

The F5 BIG-IP connector is live. Proxy agent in your management network polls the control plane for jobs, runs the iControl REST flow, F5 credentials never leave that zone. The actual flow is transactional: opens a /mgmt/tm/transaction, installs the cert and key as separate sys/crypto/* objects, repoints the client-ssl profile, commits atomically.

Either everything applies or nothing does. Token auth via X-F5-Auth-Token, partition aware (defaults to Common, custom partitions supported), cleanup pass deletes superseded cert and key objects after a successful renewal so you don't get garbage buildup.

We also ship a Go based F5 iControl REST mock server in CI so the connector is exercised on every commit without needing live hardware.

Why this matters

F5 is one of fifteen target connectors that all ship native, no plugins, no scripts, no professional services engagement.

NGINX, Apache, HAProxy, Caddy, Traefik, Envoy, IIS, Windows Cert Store, Java keystore, K8s Secrets, AWS ACM, Azure Key Vault, SSH, Postfix, all in the same binary.

Same story on the issuer side: EJBCA, Vault PKI, AWS ACM PCA, Google CAS, DigiCert, Sectigo, GlobalSign, Entrust, OpenSSL, step ca, plus a built in ACME server (RFC 8555 + RFC 9773 ARI), SCEP server (RFC 8894 with Intune challenge dispatch), and EST server (RFC 7030).

ADCS is supported via Sub-CA mode, where the local issuer loads an ADCS-signed CA cert and key and operates as a subordinate inside your existing trust hierarchy.

The whole thing runs as docker compose up. BSL 1.1 license, free for self hosting forever, no paid tier. The future revenue path is hosted control plane operational convenience, not feature gating.

What's coming

Same proxy agent pattern is the architectural prereq for the rest of the network appliance set: Palo Alto via PAN-OS XML, FortiGate via FortiOS REST, Citrix ADC via NITRO. All on the roadmap as free V2 work under BSL.

Important: please test in lab or dev only, not production

The F5 connector is new. It is exercised on every commit against a Go based iControl REST mock server in CI, but real BIG-IP behavior has surface area that no mock can fully model (firmware variants, license tier differences, vCMP guests, route domains, custom monitors, edge cases around object naming and partition isolation). Treat this as alpha for production purposes.

What we are asking for is lab or dev environment testing. Spin certctl up against a non-production BIG-IP, run an issuance and a renewal through the connector, and file a GitHub issue with anything that looks off. Production-critical environments deserve real world feedback shaping the connector before it gets pointed at them, and that feedback can only come from F5 admins willing to break things in a safe environment first.

Issues, suggestions, and "this iControl REST endpoint behaves differently on our box" reports all welcome at the repo.