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.
F5 BIGIP & XC certbot plugin
Hi! As I maintain the certbot-f5bigip plugin to enable the certbot as ACME client to validate and install certificates, I now published the certbot-f5xc plugin! Currently only DNS validation with the DNS01 challenge is supported, so if you use F5 XC for DNS, you can use this plugin to verify domains for your certificates and use the certificate then for other infrastructure beside XC HTTP LBs (which can do auto-cert provisioning already). I will add an installer next, so certificates can be uploaded / installed to XC and re-used with HTTP LBs, so stay tuned! Here are the links to the repositories on gitlab.com: https://gitlab.com/emalzer/certbot-f5bigip https://gitlab.com/emalzer/certbot-f5xc https://gitlab.com/emalzer/certbot-ansible
F5 Device Certificate renewal process on Active and Standby devices
Hi Team, The SSL certificates on the load balancers we manage (both Active and Passive) are set to expire in July. Could you please share the recommended steps to renew them correctly and ensure a smooth implementation without any service impact? Certificate Expiry Details Active Load Balancer: Expires on July 26th, 2025 Passive Load Balancer: Expires on July 27th, 2025 Please note that in our case, both load balancers are using different certificates.self-directed requests fail because of no certificate
Is there a way to whitelist a server so it can make requests from itself without needing to have a certificate? I use the F5 to provided CAC authentication for my site. It's a PHP server. During the setup process for the web application software we run on the server, the setup process needs to learn, test and record it's own URL and the URL of other web applications installed on the same server. These URLs are used later when generating HTML with absolute URL links in it. When the user types a URL in and submits it, the server will then make a request from that URL (where an API is waiting) to make sure it get's a valid response--verifying the URL is correct. This process fails, I'm assuming, because any requests of the server require you to have a CAC/Certificate. As such our software is unable to validate URLs. What can be done about this to allow it to work? Ideally it would be nice if the server was somehow whitelisted so it could make a self-directed request, but is there any other options?
Redirect https to https virtual server Certificate question
Hi, i have to redirect a https request to a https virtual server , i have in mind to use an irule as follows: when HTTP_REQUEST { set url [HTTP::uri] if {[regexp {"STRING"} $url]} { virtual /Common/MyVirtual } } To do so , i have to set the HTTP profile (client) to http to be able to assing the corresponding Irule to the VS, but requests doesnt work as i have to select the SSL Profile , here the problem. i created a new SSL client profile and tried to set the Certificate Key chain, but doesnt work ( i think i did it wrong) The source https request is using a certificate, that i can see already stored at the F5 , inside file ca-bundle.crt , also from the source server i was able to get the certificate and tried to create a new certificate , but doesnt work , i think i'm missing the key or something. When creating the certificate it's mandatory to generate it as Certificate Authority? or it can be self? Note: i'm not very good at certificates with F5 , i know how to create irules, manage the F5 and so on .. but i'm lost with the certificates part. Thanks in advance.
Question regarding the SSL/TLS cipher and Certificate
Hi Folks, I have two question regarding SSL/TLS cipher and Certificate. We used the same ssl profile with same cipher suite on two different F5 VSs, and we tested SSL/TLS by Qualys SSL Labs. But we saw the different report. One of the website got the A grade, but the other website got the B grade, because the webpage didn't use the forward secrecy cipher suite. Why do we get the discrepancy report ? The other question: There were several WAF or Load balancer on the same network chain to handle the same traffic for the same website. It was like there is a user send the HTTPS request through the several proxy device and final reach the website. Why the user got the certificate problem If one of the proxy which wasn't placed on the first gave the wrong ssl certificate ? Wouldn't the first proxy unit handling client side ssl handshake? Regards, Ding
