ACME pkg v1.3

jimp

ACME pkg v1.3 is out now for pfSense Plus software version 26.03.1 and CE 2.8.1

Bug Fixes:

Fixed a stored XSS in pfSense ACME package via Account Key name event handlers
https://redmine.pfsense.org/issues/16974
Fixed Let's Encrypt fullchain file truncated in /conf/acme
https://redmine.pfsense.org/issues/16894
ACME cannot validate multiple domains which use different authorization methods
https://redmine.pfsense.org/issues/8560

Original PR by KonradLanz @ GitHub
ACME-EAB credentials not available during certificate issuance
https://redmine.pfsense.org/issues/16862

Original PR by TGX03 @ GitHub - Committed with some small changes

Upstream changes:

Synchronized acme.sh with upstream version 3.1.5
acme.sh has added DNS-Persist handling but it is not planned to be added to this package until some time after Let's Encrypt activates it for production use.

Existing ACME Provider changes:

The old "DNS-Hetzner" entry was removed (Deprecated upstream. See https://github.com/acmesh-official/acme.sh/issues/6990#issuecomment-4576551997 ) -- Manually migrate to DNS-Hetzer Cloud DNS entry instead
DNSExit removed username and password authentication (Deprecated upstream. See https://github.com/acmesh-official/acme.sh/issues/6914 ) -- Use API key instead
DNSimple added an optional account ID for tokens which can access multiple accounts.
Huawei Cloud added a Region option
Knot API changed the Key option to be key data instead of a file path and added a Zone option
Selfhost added an API URL option
Simply removed API Endpoint URL option
Zonomi added API Endpoint URL option

New ACME Providers:

ArubaBusiness
Baidu Cloud BCD DNS
bHosted.nl DNS API
Calrissia.be DNS API
cdmon
comlaude.com
cPanel UAPI
creoline
EuroDNS
Firestorm.ch
Glesys
GNAME
Hostinger
IP-Projects DNS
LaoDC DNS API Server
Level27
muumuu-domain.com
Poweradmin API
SiteHost
Volcano Engine DNS API
WEDOS.com

ACME pkg 1.3.1

Fixed two bugs:

Added a debug option (defaults to off) in ACME General Settings so it doesn't output or log potentially sensitive information on issue/renew unless told to do so. #12670
Added basic successs/fail detection to the output box in the GUI so it gets an appropriate color based on the result #9348

ACME pkg v1.3.2

Fixed a few more bugs:

Fix output coloring with mixed success/failure. Fixes #9348
Honor "Write Certifictes" option value. Fixes #16999
Fix SAN validation to allow IPv6 address SANs. Fixes #17000
Fix acme.sh to listen on IPv4+IPv6 in standalone mode. Fixes #17000

johnpoz

@jimp Just updated to 1.3, and did a manual renew my wildcard cert using the DNS-Cloudflare method.

Fri, 31 Jul 2026 13:47:28 -0500
Issued Certificate Dates:
Valid From: Fri, 31 Jul 2026 12:48:55 -0500
Valid Until: Thu, 29 Oct 2026 12:48:54 -0500

Seemed quicker than before, pretty sure lot of people be happy about, there were quite a few posts about this

Fixed Let's Encrypt fullchain file truncated in /conf/acme

I never ran into - when tested certs with ssl tester before, it never mentioned anything about the chain being off. But I just use the cert in haproxy for ssl offload.

pfpv

Can anyone correct the description of the Renewal Threshold? In v1.3 it still states: "Days of remaining lifetime at which ACME will renew the certificate. Defaults to 2/3 the lifetime or 30 days if the lifetime cannot be determined. ACME ignores this value if it is longer than the certificate lifetime."

The bold are contradicting. Because 2/3 of 90 is 60. It won't be renewed 60 days before the expiration for Let's Encrypt, for example. It will be renewed 30 days before the expiration. Or will it renew 60 days before the expiration?

Also, see this: https://forum.netgate.com/topic/200587/sneaky-change-in-the-renewal-threshold-box-interpretation

Gertjan

@pfpv said in ACME pkg v1.3:

an anyone correct the description of the Renewal Threshold ?

@pfpv said in ACME pkg v1.3:

Days of remaining lifetime at which ACME will renew the certificate

Enter :

and it will be renew after 60 days.

@pfpv said in ACME pkg v1.3:

Defaults to 2/3 the lifetime

Enter :

and it will default to 2/3 of 90 60 days is days days.
Implicit condition : 2/3 of the (end date) - (start date), that's normally 90 days, but this will/can/shall change in the future.

@pfpv said in ACME pkg v1.3:

30 days if the lifetime cannot be determined.

If for some reason the "end date" can't be determined from the certificate ( seems strange but why not ?), and you gave no duration, 30 days will be used.

@pfpv said in ACME pkg v1.3:

ACME ignores this value if it is longer than the certificate lifetime.

If the known certificate end date is (example) :

and I set :

then my "365" will be ignored.
I presume (check with the acme.sh script yourself ?! ^^) the "2/3 rule" will be used (I presume).

edit : This might be important : I'm Dutch, living in France for the last 35+ years, reading and expressing myself in English. My interpretation might be wrong.
But I can fact check. The manual is here, it shows what it does ^^

pfpv

@Gertjan said in ACME pkg v1.3:

Enter :

and it will be renew after 60 days.

No. It will be renewed 60 days before expiration. I had 9 in this field, and my certificates were renewed 9 days before expiration, not after creation.

The meaning of this field changed in v1.2, and it was the point of my other thread I linked.

jimp

The description of that setting means what it says, though in the past that may not have been true, and it did change out of necessity because of upstream changes in Let's Encrypt.

Let's Encrypt recommends renewing at 2/3 the lifetime remaining (e.g. 60 days remaining out of 90), not 2/3 expired (30 days left).

The lifetime of LE certs can now vary wildly depending on the profile you specify, and can be as low as 6 days for shortlived certs. Future default lifetimes are going to be 45 days instead of 90, too.

I had to "future-proof" the GUI option as that lowers so someone's hardcoded number wouldn't break the logic as LE updates their lifetimes automatically as time goes on. If someone hardcoded 60 in there and the cert lifetime lowered to 45, this avoids the user getting a rude awakening when it never renews.

So now you set the number of days remaining in the lifetime at which the certificate gets renewed, if you care to set a manual value at all. If you want it to renew when it has 30 days of lifetime left, enter 30.

See also: https://redmine.pfsense.org/issues/16603

This also aligns it with the expiration notification behavior: https://redmine.pfsense.org/issues/16605

pfpv

@jimp said in ACME pkg v1.3:

The description of that setting means what it says, though in the past that may not have been true, and it did change out of necessity because of upstream changes in Let's Encrypt.

Not only the description but also the calculations based on that field changed. As I mentioned in the thread I linked, I had 80 in that field and my certificates renewed automatically 10 days before expiration. Then, without any warning, the interpretation of that field changed to days remaining, together with the description. I still had 80 in that field after the package update.

Let's Encrypt recommends renewing at 2/3 the lifetime remaining (e.g. 60 days remaining out of 90), not 2/3 expired (30 days left).

I never thought it was the case. And the previous default in pfSense was to renew certificates at a 60-day lifetime or 30 days before expiration when nothing was entered in that field. And that's how it was for a long time.

Let's Encrypt says this: "today we expect renewal around day 60 (of a 90-day certificate)".
https://letsencrypt.org/2026/02/24/rate-limits-45-day-certs

That's probably where the confusion about the current description of the field came from.

pfpv

Just discovered there is v1.3.1. What's changed? Judging by the version number, are there some fixes?

johnpoz

@pfpv he edit his first post to include fixes in 1.3.1

ACME pkg 1.3.1

Fixed two bugs:

    Added a debug option (defaults to off) in ACME General Settings so it doesn't output or log potentially sensitive information on issue/renew unless told to do so. #12670
    Added basic successs/fail detection to the output box in the GUI so it gets an appropriate color based on the result #9348

jimp

I found a couple more bugs I needed to fix, so now there's ACME pkg v1.3.2 as well.

One thing to note is that the Write Certificates option wasn't honored properly before. It was always writing the certificates, not only when checked. So there is a chance someone out there is relying on the certs being in /conf/acme but they never checked the option. So if your certs in /conf/acme are mysteriously out of date, check the Write Certificates box under General Settings and reissue a certificate.

RKiFkRyCevGvpLeXMove

This post is deleted!

RKiFkRyCevGvpLeXMove

@jimp said in ACME pkg v1.3:

I found a couple more bugs I needed to fix, so now there's ACME pkg v1.3.2 as well.

One thing to note is that the Write Certificates option wasn't honored properly before. It was always writing the certificates, not only when checked. So there is a chance someone out there is relying on the certs being in /conf/acme but they never checked the option. So if your certs in /conf/acme are mysteriously out of date, check the Write Certificates box under General Settings and reissue a certificate.

There's a really, really good chance. Yep, that was me. It took me a while to figure out that solution. I came here to post it, but you already had. I appreciate your great work, thank you.

One note: I didn't need to re-issue anything — my certs had already been renewed earlier tonight. I just checked "Write Certificates" in General Settings and hit Save, and it immediately wrote the current certs to /cf/conf/acme/. So for anyone else recovering from this: check the box and Save is enough, no reissue required.