How to Install an ACME SSL Certificate on pfSense

pfSense issues and renews its own TLS certificates through the ACME package, a graphical front end to the acme.sh client that Netgate maintains. It handles commercial certificate authorities properly, including External Account Binding, so there is no need for an external machine in the normal case. What trips people up is that a commercial CA has to be registered in one place before it becomes selectable in another, and that step is easy to miss.

Automation is no longer optional here. Under CA/Browser Forum ballot SC-081v3, publicly trusted TLS certificates have been capped at 200 days since March 15, 2026, dropping to 100 days on March 15, 2027 and to 47 days on March 15, 2029. The good news, covered at the end, is that the pfSense package’s renewal timing is expressed as a fraction of the certificate’s lifetime, so it adapts to those changes on its own.

Before you start

• A current pfSense release. The ACME package is available on both editions: pfSense CE is at 2.8.1 and pfSense Plus at 26.07. Anything materially older should be updated first, both for the package’s EAB support and because CE 2.8.0 pulled in a number of features that were previously exclusive to Plus.
• Admin access to the web interface. Everything below is done there.
• Your CA’s ACME directory URL, EAB Key ID and EAB HMAC Key, generated in your CA account portal.
• A domain name that resolves to the firewall’s WAN address if you plan to validate over HTTP. For DNS validation the address does not matter.
• One reachable validation path, either inbound TCP port 80 from the internet or an API credential for your DNS provider. Step 4 covers the choice, and on pfSense the port 80 question has a wrinkle worth reading before you pick.

Step 1: Install the ACME package

1. Go to System > Package Manager > Available Packages.
2. Search for acme.
3. Click Install next to the ACME package and confirm.

When it finishes, a new entry appears at Services > Acme Certificates with three tabs: General Settings, Certificates and Account Keys. The order you use them in is not the order they appear in, which is the first thing to know.

Step 2: Add your CA under General Settings

This is the step that is missing from most pfSense ACME walkthroughs, and skipping it stops you dead in the next one. The account key form does not have a field where you can paste a directory URL. It offers a dropdown of known ACME servers and rejects anything that is not in it. A commercial CA has to be added to that list first.

1. Go to Services > Acme Certificates > General Settings.
2. Tick Cron Entry to enable scheduled ACME certificate renewal. This is the scheduled job that both renews certificates and runs the post-renew actions from Step 6, so nothing is automatic without it.
3. In the Custom ACME Servers section, click Add ACME Server, give it a name you will recognise in a dropdown, and paste your CA’s directory URL.
4. Save.

There is also a Write Certificates option here that writes issued certificates to /conf/acme/. It is not needed for anything in this guide, but it is convenient if you want other scripts on the firewall to read the files.

Step 3: Create and register the account key

Go to Services > Acme Certificates > Account Keys and click Add.

• Name: something identifiable, such as the CA’s name.
• Description: optional.
• ACME Server: pick the custom server you added in Step 2 from the dropdown.
• E-Mail Address: the contact address registered with the CA.
• EAB Key ID and EAB HMAC Key: paste the two values from your CA. Note that the HMAC field is a text area rather than a single line, so a long value is expected.

Then use Create new account key to generate the key material, and Register ACME account key to register it with the CA. Registration is a separate action from saving, and nothing will issue until it succeeds.

Two corrections to advice you may have read elsewhere. The EAB fields are always present on this form; they do not appear or disappear depending on which CA you selected. The package describes them as optional and tells you to leave them blank unless the CA requires them, which is a different thing from hiding them. And if a CA does require EAB, there is no “register normally and sort it out later” path: registration without the credentials is refused by the CA.

Step 4: Add the certificate and choose a validation method

Go to the Certificates tab and click Add. Give it a name, set Status to active, and select your account key under ACME Account Key, which also fixes which CA this certificate comes from.

In the SAN list, add a row per host name. Each row has three columns: Status, SAN and Validation Method. There is no separate challenge-type selector anywhere on this page; the validation method on each row is the whole of that choice, and different names on one certificate can use different methods.

The package offers 165 validation methods. Four are not DNS based:

• Standalone HTTP server runs a temporary listener on the firewall for the challenge. Its own help is specific: the port must be 80, or port 80 on WAN must be forwarded to whichever port you set, and firewall rules have to let the traffic reach it.
• Standalone TLS-ALPN server does the same thing over TLS, which suits a site where port 443 is open and port 80 is not.
• Webroot local folder writes the challenge file into a folder you nominate, for example when a package on the firewall already serves that path.
• Webroot FTP writes it to a remote server over FTPS or SFTP.

The remaining 161 are DNS providers, from Cloudflare and Route 53 through to niche registrars, plus DNS-Manual and DNS-NSupdate / RFC 2136. Use one of these when the firewall is not reachable on port 80, when it sits behind CGNAT, or when you need a wildcard, which no CA will validate over HTTP. Avoid DNS-Manual for anything you intend to leave running, because it requires a person to publish a TXT record at every renewal.

Step 5: Clear the way for HTTP validation

Skip this if you chose a DNS method. If you chose one of the standalone servers, there is a pfSense-specific obstacle worth naming, because “something else is using port 80” on a firewall usually means the firewall itself.

pfSense adds a redirect rule on port 80 by default so that the web interface stays reachable there whatever port it actually listens on. The switch is at System > Advanced > Admin Access, called WebGUI redirect, whose checkbox reads Disable webConfigurator redirect rule. Left unchecked, which is the default, the firewall answers on port 80 and the ACME standalone server has nowhere to bind.

You have three ways out, in rough order of preference:

• Use a DNS validation method instead and stop worrying about ports at all.
• Give the standalone server a different port and forward WAN port 80 to it with a port forward rule, which is the arrangement the package’s own help describes.
• Disable the webConfigurator redirect rule, accepting that the interface is then reachable only on its real port.

Whichever you choose, the CA has to reach the firewall from the internet on port 80, so a firewall rule must permit it and the domain must resolve to the WAN address. A redirect from HTTP to HTTPS elsewhere in the path is acceptable, because the CA follows redirects, but a device that drops port 80 outright is not.

Step 6: Add a post-renew action

Still in the certificate you are editing, find the Post-Renew Actions section. The package describes these as actions it runs after issuing or renewing a certificate, for example to restart a service so it uses the new one. Renewal replaces the files; it does not tell a running daemon to re-read them.

Each row has a method and a command. The package’s own examples are the ones most installations need:

• To restart the web interface, choose Shell Command and enter /etc/rc.restart_webgui.
• To restart HAProxy, choose Shell Command and enter /usr/local/etc/rc.d/haproxy.sh restart.
• To restart a captive portal zone, choose Restart Local Service and enter captiveportal followed by the zone name.
• To restart the web interface on an HA peer, choose Restart Remote Service and enter webgui, which uses the system’s existing HA sync settings.

Add one row per service that needs it. These only run when the scheduled cron entry from Step 2 renews the certificate, which is the other half of why that checkbox matters.

Step 7: Issue the certificate and put it to work

Save the certificate, then use the Issue/Renew button on its row. The page streams the log as it runs, so you can watch account verification, domain validation and issuance in turn, and read the CA’s own message if any of them fails. On success the certificate appears under System > Certificates alongside everything else on the firewall.

To use it for the web interface, go to System > Advanced > Admin Access and select it in the SSL/TLS Certificate dropdown, then save. If the certificate you just issued is not in that list, pfSense has filtered it out: the field excludes certificates it considers incompatible with HTTPS, such as ones using unsupported ECDSA curves or weak digest algorithms, so check the key type you requested rather than assuming issuance failed.

OpenVPN, IPsec and packages such as HAProxy each select the certificate in their own configuration. Those selections survive renewals, because renewal updates the existing certificate entry rather than creating a new one, which is why the post-renew action only has to restart the service and not re-point it.

Confirm what the firewall actually serves, from another machine on the network:

openssl s_client -connect fw.example.com:443 -servername fw.example.com </dev/null 2>/dev/null | openssl x509 -noout -subject -issuer -dates

For a check from outside your network, including whether the intermediate is being served with the leaf, use the SSL Checker.

Step 8: Understand the renewal threshold

The certificate form has a Renewal Threshold field, and its behaviour is better than the usual description of it suggests.

The value is the number of days of remaining lifetime at which the package renews, not a number of days after issuance. Left empty it defaults to two thirds of the certificate’s total lifetime, falling back to 30 days only when the lifetime cannot be read. So a 200-day certificate is renewed once about 134 days remain, which is roughly two months after it was issued, and a 90-day certificate is renewed at 60 days remaining. A value longer than the certificate’s own lifetime is ignored rather than obeyed.

Because the default is a proportion rather than a fixed number of days, it keeps working as certificate lifetimes fall to 100 and then 47 days without anyone adjusting it. That is a good reason to leave the field empty unless you have a specific requirement, and a good reason not to copy a fixed value from a guide written for 90-day certificates.

If the package cannot reach your CA

You can issue the certificate on another machine with acme.sh and import it by hand. Treat this as a genuine last resort rather than an equivalent option, for a reason worth stating plainly: acme.sh has no pfSense deployment hook, so nothing pushes the renewed files back into the firewall for you. Everything the package gives you, the scheduled renewal, the post-renew actions and the in-place certificate update that keeps existing service bindings valid, becomes yours to rebuild.

curl https://get.acme.sh | sh -s [email protected]
source ~/.bashrc

acme.sh --register-account \
  --server https://acme.yourca.example/v2/DV \
  --eab-kid "YOUR_EAB_KEY_ID" \
  --eab-hmac-key "YOUR_EAB_HMAC_KEY" \
  --accountemail "[email protected]"

export CF_Token="your_cloudflare_api_token"
acme.sh --issue --dns dns_cf \
  -d fw.example.com \
  --server https://acme.yourca.example/v2/DV

The files land in ~/.acme.sh/fw.example.com/. In pfSense, go to System > Certificates, add an entry with the import method, and paste the contents of fullchain.cer into the certificate field and fw.example.com.key into the private key field. Then assign it exactly as in Step 7, and set yourself a reminder well inside the certificate’s lifetime, because this arrangement will not renew itself.

Frequently Asked Questions

For more on the protocol behind all of this, see what the ACME protocol is and our ACME SSL certificates page. The equivalent setup on the other BSD firewall is covered in our guide to installing an ACME SSL certificate on OPNsense, and for a manual certificate see installing an SSL certificate on pfSense.