Certificate Automation for BIG-IP using CyberArk Certificate Manager, Self-Hosted

The issue of reduced lifetimes of TLS certificates is top of mind today.  This topic touches upon reducing the risks associated with human day-to-day management tasks for such critical components of secure enterprise communications.   Allowing a TLS certificate to expire, by simple operator error often, can preclude the bulk of human or automated transactions from ever completing.  In the context of e-commerce, as only one single example, such an outage could be financially devastating.

Questions abound: why are certificate lifetimes being lowered; how imminent is this change; will it affect all certificates? 

An industry association composed of interested parties, including many certificate authority (CA) operators, is the CA/Browser Forum.   In a 29-0 vote in 2025, it was agreed public TLS certificates should rapidly evolve from the current 398 day de-facto lifetime standard to a phased arrival at a 47 day limit by March 2029.   An ancillary requirement, demonstrating the domain is properly owned, known as Domain Control Validation (DCV) will drop to ten days.

Although the governance of certificate lifecycles overtly pertains to public certificates, the reality is enterprise-managed, so called private CAs, likely need to fall in lock step with these requirements.   Pervasive client-side software elements, such as Google Chrome, are used transparently by users with certificates that may be public or enterprise issued, and having a single set of criteria for accepting or rejecting a certificate is reasonable. 

 

Why Automated Certificate Management on BIG-IP, Now More than Ever?

 

A principal driver for shortening certificate (cert) lifetimes; the first phase will reduce public certs to 200-day durations this coming March 15, 2026, is simply to lessen the exposure window should the cert be compromised and mis-used by an adversary.

Certificates, and their corresponding private keys, can be manually maintained using human-touch.  The BIG-IP TMUI interface has a click-ops path for tying certificates and keys to SSL profiles, for virtual servers that project HTTPS web sites and services to consumers.   However, this requires something valuable, head count, and diligence to ensure a certificate is refreshed, perhaps through an enterprise CA solution like Microsoft Certificate Authority.  It is critical this is done, always and without fail, well in advance of expiry.   An automated solution that can take a “set it and forget it” approach to maintain both initial certificate deployment and the critical task of timely renewals is now more beneficial than ever.

 

Lab Testing to Validate BIG-IP with CyberArk Trusted Protection Platform (TPP)

 

A test bed was created that involved, at first, a BIG-IP in front of an HTTP/HTTPS server fleet, a Windows 2019 domain controller and a Windows 10 client to test BIG-IP virtual servers with.   Microsoft Certificate Authority was installed on the server to allow for the issuance of enterprise certs for any of the HTTPS virtual servers created on the BIG-IP.

Here is the lab layout, where virtual machines were leveraged to create the elements, including BIG-IP virtual edition (VE).

The lab is straight forward; upon the Windows 2019 domain controller the Microsoft Certificate Authority component was installed.   Microsoft SQL server 2019 was also installed, along with SQL Management Studio.   In an enterprise production environment, these components would likely never share the domain controller host platform but are fine for this lab setup.

Without an offering to shield the complexity and various manual processes of key and cert management, an operator will need to be well-versed with an enterprise CA solution like Microsoft’s.  A typical launching sequence from Server Manager is shown below, with the sample lab CA and a representative list of issued certificates with various end dates.

Unequipped with a solution like that from CyberArk, a typical workflow might be to install the web interface, in addition to the Microsoft CA and generate web server certificates for each virtual server (also frequently called “each application”) configured on the BIG-IP.   A frequent approach is to create a unique web server template in Microsoft CA, with all certificates generated manually following the fixed, user specified certificate lifetime.

As seen below, we are not installing anything but the core server role of Certificate Authority, the web interface for requesting certificates is not required and is not installed as a role.

 

CyberArk Certificate Manager, Self-Hosted  – Three High-Value Use Cases

 

The self-hosted certificate and key management solution from CyberArk is a mature, tested offering having gained a significant user base and still may be known by previous names such as Venafi TLS Protect, or Venafi Trust Protection Platform (TPP).  CyberArk acquired Venafi in 2024.
Three objectives were sought in the course of the succinct proof-of-concept lab exercise that represented expected use cases:

1.    Discover all existing BIG-IP virtual server TLS certificates
2.    Renew certificates and change self-signed instances to enterprise PKI-issued certificates
3.    Create completely new certificates and private keys and assign to BIG-IP new virtual servers 

 

The following diagram reflects the addition of CyberArk Certificate Manager, or Venafi TPP if you have long-term experience with the solution,  to the Windows Server 2019 instance.

 

Use Case One – Discover all BIG-IP Existing Certificates Already Deployed

 

In our lab solution, to re-iterate the pivotal role of CyberArk Certificate Manager (Venafi TPP) in certificate issuance, we have created a “PolicyTree” policy called “TestingCertificates”.  This will be where we will discover all of our BIG-IP virtual servers and their corresponding SSL Client and SSL server profiles.   An SSL Client profile, for example, dictates how TLS will behave when a client first attempts a secure connection, including the certificate, potentially a certificate chain if signage was performed with an intermediate CA, and protocol specific features like support for TLS 1.3 and PQC NIST FIPS 203 support.

Here are the original contents of the TestingCertificates folder, before running an updated discovery, notice how both F5 virtual servers (VS) are listed and the certificates used by a given VS.  This is an example of the traditional CyberArk GUI look and feel.

A simple workflow exists within the CyberArk platform to visually set up a virtual server and certificate discovery job, it can be run manually once, when needed, or set to operate on a regular schedule.   This screenshot shows the fields required for the discovery job, and also provides an example of the evolved, streamlined approach to the user interface, referred to as the newer “Aperture” style view.

Besides the enormous time savings of the first-time discovery of BIG-IP virtual servers, and certificates and keys they use in the form of SSL profiles, we can also look for new applications stood up on the BIG-IP through on-going CyberArk discovery runs.

In the above example, we see a new web service implemented at the FQDN of www.twotitans.com has just been discovered.   Clicking the certificate, one thing to note is the certificate is self-signed.   In real enterprise environments, there may be a need to re-issue such a certificate with the enterprise CA, as part of a solid security posture.   Another, even more impactful use case is when all enterprise certificates need to be easily and quickly switched from a legacy CA to a new CA the enterprise wants to move to quickly and painlessly.

We see with one click on a certificate discovered that some key information is imparted.  On this one screen, an operator might note that this particular certificate may warrant some improvements.   It is seen that only 2048 bits are used in the certificate; the key is not making use of advanced storage and on, such as a NetHSM, and the certificate itself has not been built to support revocation mechanisms such as Content Revocation Lists (CRLs) or Online Certificate Status Protocol (OCSP).

 

Use Case Two - Renew Certificates and Change Self-signed Instance to Enterprise PKI-Issued Certificates

 

The automated approach of a solution like CyberArk’s likely means manual interactive certificate renewal is not going to be prevalent.   However, for the purpose of our demonstration, we can examine a current certificate, alive and active on a BIG-IP supporting the application, s3.example.com.  This is the “before” situation (double-click image for higher resolution).

The result upon clicking the “Renew Now” button is a new policy-specific updated 12-month lifetime will be applied to a newly minted certificate.   As seen in the following diagram, the certificate and its corresponding private key are automatically installed on the SSL Client Profile on the BIG-IP that houses the certificate.  The s3.example.com application seamlessly continues to operate, albeit with a refreshed certificate.

A tactical usage of this automatic certificate renewal and touchless installation is grabbing any virtual servers running with self-signed certificates and updating these certificates to be signed by the enterprise PKI CA or intermediate CA.   Another toolkit feature now available is to switch out the entire enterprise PKI from one CA to another CA, quickly.

In our lab setup, we have a Microsoft CA configured; it is named “vlab-SERVERDC1-ca”.   The following certificate, ingested through discovery by CyberArk from the BIG-IP, is self-signed.  Such certificates can be created directly within the BIG-IP TMUI GUI, although frequently they are quickly generated with the OpenSSL utility.

Being self-signed, traffic through into this virtual will typically cause browser security risk pop-ups. They may be clicked through by users in many cases, or the certificate may even be downloaded from the browser and installed in the client’s certificate store to get around a perceived annoyance.

This, however, can be troublesome in more locked-down enterprise environments where an Active Directory group policy object (GPO) can be pushed to domain clients, precluding any self-signed certificates being resolved with a few clicks around a pop-up.   It is more secure and more robust to have authorized web services, vetted, and then incorporated into the enterprise PKI environment.   This is the net result of using CyberArk Certificate Manager, coupled with something like the Microsoft enterprise CA, to re-issue the certificate (double-click).

 

Use Case Three - Create Completely New Certificates and Private Keys and Assign to BIG-IP New Virtual Servers 

 

Through the CyberArk GUI, the workflows to create new certificates are intuitive.   Per the following image, right-click on a policy and follow the “+Add” menu.   We will add a server certificate and store it on the BIG-IP certificate and key list for future usage.

A basic set of steps that were followed:

• Through the BIG-IP GUI, setup the application on the BIG-IP as per a normal configuration, including the origin pool, the client SSL profile, and a virtual server on port 443 that ties these elements together.
  
  
• Create, on CyberArk, the server certificate with the details congruent with the virtual server, such as common name, subject alternate name list, key length desired.
  
  
• On CyberArk, create a virtual server entry that binds the certificate just created to the values defined on the BIG-IP.

The last step will look like this.

Once the certificate is selected for “Renewal” the necessary elements will automatically be downloaded to the BIG-IP.   As seen, the client’s SSL profile has now been updated with the new certificate and key signed by the enterprise CA.

 

Summary

 

This article demonstrated an approach to TLS certificate and key management for applications of all types, which harnesses the F5 BIG-IP for both secure and scalable delivery.   With the rise in the number of applications that require TLS security, including advanced features enabled by BIG-IP, like TLS1.3 and PQC, coupled with the industry’s movement towards very short certificate lifecycle, the automation discussed will become indispensable to many organizations.

The ability to both discover existing applications, switch out entire enterprise PKI offerings smoothly, and to agilely create new BIG-IP centered applications was touched upon.