SSL automation

ACME on appliances: native or proxy

Q: Do I need to open DNS API access to my DNS provider?

No. That is the whole point of FairSSL Auto DNS . You create a permanent CNAME once, and FairSSL handles every ACME DNS-01 challenge. No DNS API keys, no firewall openings towards the DNS server.

Firewalls, load balancers, mail gateways and monitoring servers typically cannot run an ACME client internally. We have done the setup on FortiGate, FortiMail, FortiWeb, NetScaler, F5 BIG-IP, KEMP and Kubernetes many times, and there are only two patterns you need to pick from.

The two patterns

Native ACME

The appliance runs the ACME client itself

The appliance talks directly to the FairSSL ACME server, fetches the certificate and installs it in its own configuration. Shortest possible chain, fewest moving parts.

Supported today:

FortiGate from FortiOS 7.6.3
Kubernetes via cert-manager

Proxy + push

External host issues, deploy-hook pushes

A small Linux or Windows host runs Lego or simple-acme. It issues the certificate via FairSSL Auto DNS, and a deploy-hook uploads it to the appliance via its API.

Used for:

FortiGate older than 7.6.3, FortiMail, FortiWeb
NetScaler / Citrix ADC
F5 BIG-IP, KEMP LoadMaster
Palo Alto, pfSense, OPNsense, Ubiquiti

Appliances with ready-made guides

FortiGate

Native

7.6.3+ with native ACME, older versions via proxy

Native ACME client from FortiOS 7.6.3 with HTTP-01 validation on an arbitrary port. Older FortiGate versions get the certificate pushed in from a Linux or Windows host.

FortiMail / FortiWeb

Proxy

Proxy + REST API

A Lego or simple-acme host issues the certificate and pushes it in via the FortiMail or FortiWeb REST API. We have ready-made script templates for both.

Citrix NetScaler / ADC

Proxy

Proxy + NITRO API

simple-acme on a Windows host issues the certificate and deploys it to NetScaler via the NITRO REST API. Updates both the SSL certificate object and the bound virtual servers.

F5 BIG-IP

Proxy

Proxy + iControl REST

Lego on a Linux host issues the certificate and uploads it to F5 via iControl REST. Replaces the Client SSL profile certificate and key without manual binding.

KEMP LoadMaster

Proxy

Proxy + KEMP API

The built-in Let's Encrypt integration cannot point at FairSSL. We use an external host with Auto DNS validation and KEMP's API to import and bind the certificate to virtual services.

Kubernetes

Native

Native ACME via cert-manager

cert-manager runs as an ACME client inside the cluster, creates a ClusterIssuer against FairSSL and issues TLS Secrets automatically. No proxy required.

How proxy + push works in practice

1

Pick a host

An existing Linux or Windows server. It only needs outbound internet access and network access to the appliance management port.
2

Create one CNAME for ACME validation

FairSSL Auto DNS uses a permanent _acme-challenge.<your-domain> CNAME pointing to our DNS server. One-time setup. No DNS API keys required.
3

Run Lego or simple-acme with EAB keys

The client registers the account against the FairSSL ACME server, issues the certificate and stores it locally.
4

Deploy-hook pushes the certificate to the appliance

A bash or PowerShell script calls the appliance API (iControl, NITRO, FortiOS REST, KEMP API) and updates the certificate on the relevant virtual services.
5

Schedule the client daily

cron or Task Scheduler runs the client once a day. ARI controls when the actual renewal happens, and the deploy-hook fires only on an actual renewal.

Ready-made example scripts live inside each appliance guide above. Missing your appliance from the list? Email info@fairssl.dk and ask, we have done it before.

Frequently asked questions

Find answers to the most common questions about SSL certificates and FairSSL.

Which appliances can run ACME natively?

Only a few. FortiGate has a built-in ACME client from FortiOS 7.6.3. cert-manager for Kubernetes is a native ACME client running inside the cluster. Everything else (NetScaler, F5, KEMP, FortiMail, FortiWeb, PRTG, Palo Alto, pfSense, OPNsense) needs an external host that issues the certificate and pushes it in via API or SSH.

What is the proxy approach?

You run an ACME client such as Lego or simple-acme on an existing Linux or Windows server. The client issues the certificate via FairSSL Auto DNS validation, and a deploy-hook or post-renewal script uploads it to the appliance via its API. The appliance never sees the ACME challenge.

How does it work with KEMP LoadMaster?

KEMP has a built-in "Let's Encrypt" integration that is hard-pointed at Let's Encrypt's production server and cannot be redirected to the FairSSL ACME server. We recommend the proxy approach: issue the certificate on a Linux or Windows host using Auto DNS validation, then use KEMP's API to import the certificate and update the virtual services.

Do I need to open DNS API access to my DNS provider?

No. That is the whole point of FairSSL Auto DNS. You create a permanent CNAME once, and FairSSL handles every ACME DNS-01 challenge. No DNS API keys, no firewall openings towards the DNS server.

Is ARI supported on appliances?

Yes, through the external ACME client. ARI (RFC 9773) is a property of the client, not the appliance. Both Lego (v5+) and simple-acme support ARI, and the FairSSL ACME server exposes ARI endpoints. If FairSSL needs to re-issue the certificate, your client renews it automatically within the window ARI indicates.

Can you help with the setup?

Yes. Order installation service from the control panel and a FairSSL technician will help get the proxy script in place. We have done the setup on FortiGate, FortiMail, NetScaler, F5, KEMP and many other appliances before.

Ready to automate certificates on your appliances?

Create a free account and issue your first certificate in under 10 minutes.

Create free account Compare certificates