Automating Certificate Management on F5 BIG-IP

The Certificate Lifespan Revolution

Welcome to part one of our two-part series on certificate automation for the BIG-IP platform.

Certificate lifecycle management is undergoing a seismic shift that will fundamentally change how organizations handle SSL/TLS certificates. The era of comfortable 12-13 month certificate lifespans is rapidly ending. Major Certificate Authorities and browser vendors are pushing aggressively toward 90-day or even 47-day certificates, and some are proposing even shorter durations.

This transformation represents more than a simple policy change. It's a complete paradigm shift that renders traditional certificate management approaches obsolete. The familiar rhythm of annual renewals, managed through spreadsheets and calendar reminders, becomes not just inefficient but operationally impossible when certificates expire every three months or 47 days.

 

The Challenge: Why Manual Processes Are Doomed

Organizations worldwide are recognizing the writing on the wall. Large PKI environments that once managed hundreds or thousands of certificates annually now face the prospect of managing them on a quarterly basis. The mathematical reality is stark: a 75% reduction in certificate lifespan translates to a 400% increase in the frequency of renewals.

At F5, we hear you, we understand the anxiety this creates. We hear from customers daily who are grappling with this operational challenge.

 

The F5 Solution: ACME Protocol Implementation

While third-party vendors like Venafi and DigiCert offer comprehensive certificate automation platforms, this guide focuses on F5 solutions that leverage your existing BIG-IP infrastructure. Our approach is based on the ACME (Automatic Certificate Management Environment) protocol. This is the same technology that powers Let’s Encrypt and other modern certificate authorities.

The solution uses a specialized ACME implementation called "dehydrated," adapted for BIG-IP by F5's own Kevin Stewart, with Python code inspired by Jason Rahm. You can read Kevin's DevCentral article here.

 

Getting Started: Prerequisites and Setup

Before diving into the implementation, ensure you have:

  • Active BIG-IP with the LTM module and basic networking configured
  • Registered domain with DNS management access for A record modifications (if setting up a new domain for testing purposes)
  • Internet connectivity for downloading the ACME script and communicating with certificate authorities

This solution is straightforward to configure and deploy. Follow along below.

 

Step 1: Download and Explore

Connect to your BIG-IP shell via SSH and download the script:

curl -s https://raw.githubusercontent.com/f5devcentral/kojot-acme/main/install.sh | bash

Navigate to the installation directory and explore the config file. This is where you can customize key size, contact information, OCSP stapling and more.

cd /shared/acme

The script adds a few new shiny toys to your BIG-IP. You will find two new data groups and a new iRule.

 

The data group dg_acme_config houses the subject and CA or your certificate. We will need to modify this data group before we run the script; more on this in a moment. The dg_acme_challenge holds the challenge tokens and is ephemeral, cleaning up when the process completes.

 

 

The iRule handles the HTTP-01 challenge. You need this iRule applied to the port 80 VIP when you run the script. At a high level, the iRule intercepts the challenge request from the ACME server and responds with an appropriate challenge response. In scenarios without a proxy, such as the BIG-IP, the web server handles this. Alternatively, you can use a DNS challenge by adding a TXT record at your registrar. The HTTP method is much simpler, so that’s what we will use here.

 

Step 2: Configure Your Virtual IP

Create an HTTP Virtual IP (VIP) to handle the ACME challenges. Production environments usually need both HTTP (port 80) and HTTPS (port 443) VIPs. Our demonstration uses a simple HTTP-only setup. 

 

Critical requirement: The ACME iRule must be applied to your port 80 VIP to enable HTTP-01 challenge processing.

 

 

Step 3: Configure the Data Group - dg_acme_config

We need to add our domain and CA information at a minimum. 

Add your domain to the string field and your CA information to the value field. See the documentation for more examples.

 

 

Step 4: Configure DNS

If you already have a domain configured pointing to your HTTP VIP, then skip this step. However, if you are setting up a new domain, please make sure that DNS is pointing to your VIP IP address or A record. For this demo, I purchased a low-cost domain and configured the A record to point to my AWS Elastic IP, which is attached to my private IP in my VPC.

 

Step 5: Run the script

Ok, you have DNS configured, VIP configured, and the data group modified with your domain and CA information. You are ready to roll. Go to the directory and run the script.

cd /shared/acme
./f5acmehandler.sh -verbose

The verbose flag provides real-time feedback on the ACME communication process, invaluable for troubleshooting and understanding the workflow.

 

Success?

If you are successful, you should see output similar to the screenshot below.  If not, then the details of the script workflow should clue you into the problem. The GitHub repo also offers some troubleshooting advice.

Also, let's see if we got a brand new shiny certificate. Yep.

 

What's Next?

While this created a cert and key, it didn't place them into an SSL profile. This is possible by modifying the config file. Scheduling checks could also be on your list. Kevin's article highlights this and provides an example. This will run the script every Monday at 4 am.

./f5acmehandler.sh --schedule "00 04 * * 1"

There are other advanced capabilities that I did not configure or explain in this article.  I encourage you to visit the DevCentral repo for more information. 

A key consideration for Federal agencies is the ability to support air-gapped or closed networks. However, requirements and compliance hurdles will need to be examined further.

In the following article, we will cover the Certificate Order capability built into the BIG-IP. Until next time.

 

Published Jun 23, 2025
Version 1.0

2 Comments

  • Hi! 

    Very nice article! As I'm not a fan of running the ACME client on the BIG-IPs themself, I wrote a plugin ready to use for certbot: https://gitlab.com/emalzer/certbot-f5bigip

    You can run certbot then on a VM or in a container and centralise the configuration for different domains and different BIG-IP clusters here in one single place. Or authenticate with one cluster and install on another cluster.

    And I built another repo to maintain then this certbot commands and configurations - definitely worth taking a look: https://gitlab.com/emalzer/certbot-ansible 

    Feel free to use them for your automation! I will build another plugin for XC and NEXT in the near future.

  • This is a great piece of work, thank you. When there are multiple partitions, this work is done on the common partition. partition: common partition1: apart partition2:bpart When this happens, how do we do it? I would like to thank those who will provide support in this matter in advance.