Historically, ACME was heavily associated with free, public Domain-Validated (DV) certificates from Let’s Encrypt; a great low-cost approach to a “good enough” certificate strategy. You typically get what you pay for, as you remember the old adage saying, and basic things like notification emails indicating imminent Let’s Encrypt certificate expiry were dropped some time back. Many IT groups are practically buried alive under an avalanche of tracking spreadsheets, desperately trying to keep up with the relentless, fast-fading lifespans of their certificates. Like that other old adage, friends don’t let friends renew certificates by hand.
The current market movements around security are changing the playing field, an often-discussed aspect is the march towards public certificates requiring 47-day re-issuance and domain validation even more frequently, every 10 days. Traditionally private certificates will need to adjust in lock step, things like unmanaged browsers will not play well from deviating from the ground rules spelled out, the nitty gritty can be found here.
Even with the increased workload to reach these goals of rapid certificate re-issuance, why is BIG-IP now in a position where IT users are asking for native, GUI-driven ACME? Haven’t there been a tier of CA and certificate brokers that have for years offered certificate automation through the BIG-IP iControl REST API interface?
What has changed is the maturation in the enterprise certificate lifecycle management (CLM) offerings.
- Commercial CA Adoption: Major enterprise Certificate Authorities, such as Sectigo, offer native ACME endpoints. This allows IT teams to use the standardized ACME protocol to maintain certificates such as those used by BIG-IP virtual server TLS profiles, as well as differentiation from best effort solutions like Let’s Encrypt. This means a path to Organization-Validated (OV) certificates exists. And, of course, keeping their dedicated account support.
- Internal CA “Front Door”: Security groups are increasingly deploying ACME servers inside their private corporate networks. Opensource solutions, such as Smallstep, can interwork with BIG-IP however a uniform strategy around an enterprise-grade solution like Sectigo can lead to uniformity, established workflows and lower bar for rapid support engagement.
Since ACME is itself an open standard, codified in RFC 8555, adopting it now mitigates any fear of vendor lock-in: your IT group now has a pathway to different certificate authorities in the future. This article documents a simple working configuration using public DNS and public certificates provided by Sectigo to secure applications exposed by BIG-IP.
Your Certificates Called. They Want Automation.
For a good, visual walk through of GUI-based BIG-IP configuration of ACME, including support for Let’s Encrypt, please see this recent article. This feature was introduced in 2026 in BIG-IP release 21.1.0. In the case of our article, the goal is to provide a quick enterprise class provider dev setup walkthrough, using the Sectigo offering which has multiple ACME solutions accessible through their flagship Sectigo Certificate Manager (SCM). This can be consumed as a SaaS offering.
The particular offering explored was Sectigo’ s Universal ACME which enables organizations to automate the issuance, renewal, and installation of SSL/TLS certificates across their entire infrastructure. This includes the BIG-IP load balancer and its configured virtual servers.
In our test setup, strictly for demonstration purposes, we have registered a domain “bluesealab.net”, and keeping with the seafaring theme, we secure an https virtual server for “safeharbor.bluesealab.net”. Think of this as the “go to” web destination for ship captains seeking current port conditions.
As new servers are introduced, we can create additional certificates or, more conveniently, use one certificate with a SAN list for each added host. Here is a high-level diagram, keeping in mind that the internal web server is normally a pool of many identical servers for redundancy and scale-out performance.
The ACME solution requires two validations that we do in fact actually own and manage the domain “bluesealab.net”, a longer-term validation performed within the Sectigo Certificate Manager (SCM) console, and then dynamic, frequent validations use ACME http-01 automated exchanges for hosts, like “safeharbor”.
The long-term domain validation involves creating a DNS resource record, typically of type “TXT” or “CNAME” with a value Sectigo provides in their SaaS GUI. This is the net result within SCM of the entire domain having been validated successfully.
To facilitate ACME delivery, only two further attributes need to be set in SCM. A certificate profile, which governs both if public certs will be issued and the name of the CA, is required next. This is found by following the Enrollment → Certificate Profiles menu path, and as seen the ACME solution will support 30 days certificate lifecycles in our demo.
Fields also exist to lock down the public key algorithms and key strengths that can be used in the certificates generated, make sure there is a reasonable set of choices enabled. Finally, a “Requires Approval” option may be invoked to pause certificate issuance until a human-in-the-loop reviews the request within the SCM portal.
Lastly, the actual ACME endpoint and the user account is displayed, along with a unique key value and associated derived hash value. This pair of numbers is the external account binding (EAB) which is analogous to a user id and password. The BIG-IP will need to provide these values to partake in ACME, however the authenticity of the request will use additional, on-the-fly, dynamic exchanges that prove out that we have control of the traffic terminating at our FQDN safeharbor.bluesealab.com. The dynamic validation is a critical feature for high scalability and an evolution from earlier certificate issuance protocols like Simple Certificate Enrollment Protocol (SCEP). SCEP, first introduced by Cisco in the late 1990s largely authenticates based upon knowledge of user ID and password only.
Setting the Stage: How BIG-IP Answers the ACME Challenge (Literally)
Thinking back to our topology diagram, we have the BIG-IP located in an AWS VPC, it terminates inbound traffic on a public IP address, the same address mapped to safeharbor.bluesealab.net. We need to make use of a publicly trusted certificate for users engaging with this website. The basics of the dynamic http domain validation, usually referred to by those in the know as “http-01” validation, are encapsulated in the following infographic.
The good news is the steps to implement the above are brief and quite logically ordered. First, we need to create a counterpart virtual server, at the same address IP address to support not TCP port 443 traffic but rather port 80. This is the port ACME uses and we will demonstrate our control of it by responding at a specific URL on port 80 with a Sectigo ACME provided token. Note the addresses for ports 443 and 80 match, these being the private IP addresses used by our AWS BIG-IP, mapped from the public address. To reiterate, ACME simply uses port 80.
To support ACME responses, the extent of our work is literally enabling one new option in our Virtual Server configuration, as depicted below. Easy stuff.
Okay, so what if port 80 is actually already in use, perhaps there is a redirect for users inadvertently using port 80 instead of 443 to reach the web service we are supporting? In such cases, we simply add one iRule to the existing http Virtual Server, thereby directing ACME challenges only to the required challenge endpoint:
when HTTP_REQUEST {
if { !([HTTP::uri] starts_with “/.well-known/acme-challenge”) } {
HTTP::redirect https://[getfield [HTTP::host] “:” 1][HTTP::uri]
}
}
Making the Call: BIG-IP Phones Home for a Certificate
At this point, the only item remaining is to connect to the Sectigo ACME endpoint, provide our credentials, and ensure the BIG-IP recognizes Sectigo as a valid ACME provider.
By choosing System → Certificate Management → Traffic Certificate Management → ACME Provider List we can click the “Create” button to form our required association between BIG-IP and Sectigo. Some items to keep in mind, an internal proxy on BIG-IP will be created within the click through process, to allow BIG-IP to reach out and resolve and connect to the Sectigo ACME endpoint.
The requirements on our part are to provide a self-signed certificate and the EAB key and hash values previously gathered in the Sectigo console. The EAB portion proves that, organizationally, we are entitled to service. Our BIG-IP ACME client generates an account key pair, from which it then creates and signs a self-signed certificate using the private key. By sending this certificate, the client is providing future-ready proof it possesses the corresponding private key to sign the JSON web tokens (JWT) sent to the server.
The yellow highlighted fields in the ACME provider setup raise to the top the values we are responsible for setting. In keeping with all other objects in BIG-IP, the ACME provider will require an instance name, in this case “Sectigo2026” was used.
The three red arrows are the indicators of a successful outcome, that our BIG-IP has a working account with Sectigo. One, we see the “Valid” account status and valid is never a bad thing, while two and three are fields provided to us. The third field in particular is interesting as it will show specific URL endpoints for specific ACME operations, such as “NewOrder”, “RenewalInfo”, or “RevokeCert”.
A named, new certificate is keyed into the BIG-IP GUI, when created this will provide all of the required details that the subsequent ACME certificate signing request (CSR) will leverage. Notice that rather than self-signed we are indicating we desire a Certificate Authority issued certificate for the common name “safeharbor.bluesealab.net”, with the ACME provider (Sectigo, under the name “Sectigo2026”) invoked. Double-click to enlarge.
The actual ACME request is not issued upon clicking “Finished”, but rather you move to the key tab and click on the “Update” button as called out. This sends the CSR to Sectigo. Note, the key and the certificate as is traditional with BIG-IP share the same name, “safeharbor” in our case. You will note we have previously entered our FQDN in both the common name and SAN fields. It is actually the entries of the SAN field that will be utilized in the ACME request.
Click on “Update” to see the status, ACME will take a few seconds as domain validation is happening, right now, and the status of “Processing” will be seen. Our BIG-IP virtual server on port 80 is currently providing Sectigo over port 80 the ACME token to prove our ownership of the domain name safeharbor.bluesealab.org. It’s elegant and simple and works.
Within a few seconds our new 30-day publicly trusted certificate is issued and found in our SSL certificate list.
The highlighted sections of interest include the fact that our new certificate, as well as intermediate Sectigo certificates, are all fully listed and available for inspection. The expiry date for our new virtual server certificate, safeharbor.bluesealab.net is clearly seen as August 28th, thirty days from the issuance.
To utilize this certificate, a standard SSL client profile is created and referenced by our virtual server. This is nothing new, and that is the part of the gracefulness of adding ACME to the equation, very little changes in a BIG-IP setup.
Our web server is now fully secured and seamlessly accessed; often otherwise ornery browsers will play nice and get out of the way when receiving a public TLS certificate.
Summary
And there you have it, you’ve made it through! While the world of certificate acronyms and automation protocols can seem dense, integrating your F5 BIG-IP with an enterprise ACME provider like Sectigo is simpler than you might have thought. The process is less about arcane command-line magic and more about a logical series of clicks through a familiar GUI. The days of dreading certificate expiration emails and emergency renewals are numbered.
By leveraging an enterprise provider like Sectigo, you gain the benefits of a standardized protocol without sacrificing the support and certificate validation your organization requires. The entire setup, from domain validation in the Sectigo portal to requesting the certificate on the BIG-IP, is a straightforward, GUI-driven process that demystifies certificate issuance. For those currently stuck with ad hock workflows, now might be the time to explore a newfound freedom from manual certificate management. Your future self will thank you.