@tinfoilmatt Thanks. With your Selecting any 'sleep' time value will disable the local TXT query/'poll' completely. I dived into acme.sh to understand what it was doing if DNS Sleep is set to zero. If DNS Sleep is set to zero ... then there will be a 20 seconds delay. After that, acme.sh does the checking itself. See _check_dns_entries(). Here is the acme.sh DNS Check Wiki page. The acme.sh will use DOH** and picks DOH CLOUDFLARE, DOH_GOOGLE, or DOH_ALI. From here, it starts looping around up until the moment all DNS NS server reproduce the same correct result = a TXT record with the correct name and correct content. This DNS test run can last for 1200 seconds or 10 minutes max. As soon as a total match is found : good TXT value and good TXT content, then the process continues : the actual certificate renewal. Humm. This is actually a smarter way of doing things ** but : If you've blocked DOH with for example pfBlockerng, or blocked Google and or Cloudflare DNS IPS, then you've reached the typical 'shoot in the foot' situation. I do block all DOH with pfBLockerng, so that explains for me why : [image: 1775630503531-5f5f3b1b-cb1d-433e-b1d1-607df0468a4c-image.png] never worked for me. The default behavior is to automatically poll public DNS servers for records until ACME finds them, rather than waiting a set amount of time. The reality : The default behavior is to automatically poll public DOH DNS servers for records until ACME finds them, rather than waiting a set amount of time. Furthermore, the public DOH DNS servers, and ordinary DNS servers are known and listed. If pfBlocker blocks these, then DNS Sleep = 0 will probably fail. Thanks, @tinfoilmatt , I now (better) understand what DNS Sleep '0' does. edit Further investigation : we can't set up our own DOH server to be used by acme.sh. acme.sh has 4 build in (hardcoded) DOH servers, and you have to pick one and if you don't, Cloudflare is used by default. The "DNS Sleep" setting is "0" by default, and for good reasons it is exposed in the pfSense GUI. Read for example this acme.sh 'issue', and everything is now clear. I could activate DOH on my own DNS domain name servers, but that means I have to patch acme.sh. My own DOH wouldn't be blacklisted (DNSBL) by pfBlockerng ^^ I do understand why acmes.sh default to use DOH : the challenge code, created by Letsencrypt, and put in place at the DNS master domain name server by acme.sh, has to be protected 'at all costs'. After all, the one who possesses (intercepts) this challenge code could obtain a certificate for that (your) domain name. That would be a huge disaster.

@jimp Up to now I install the certificates on the (web/mail/sftp)server(s) them selves. However since that is becoming more and more complex and certificate lifetimes as becoming shorter and shorter. I do seriously consider to use LetsEncrypt certificates generated on pfSense. And preferable without the help of additional systems. Note however that I am using HA-proxy. So I am trying two routes: completely on pfSense on pfSense with the help of a dedicated webserver on a VM, handling all LetsEncrypt requests. Routed via HA-proxy based on ^path starts /.well-known/acme-challenge/^ For method 1) I implemented the ^acme-http01-webroot.lua^ option I did not yet implement method 2) Of course I do not want to expose the pfSense GUI to the internet. I changed the GUI port number and do not allow access to pfSense from the internet at all (at least I home so) Also have a look at my other thread 'Do not manage to generate Certificate (using ^Webroot local folder^)' My intention is of course that the token is stored and read on pfSense itself without using the GUI webserver / the possibility to access the GUI.

@louis2 said in Do not manage to generate Certificate (using ^Webroot local folder^): put token at: /usr/local/www/.well-known/acme-challenge//<token> Exact. This : https://forum.netgate.com/topic/90643/let-s-encypt-support/31?_gl=1nky1q2_gcl_auMTc4MjAwMjExMS4xNzY0Njc1Mzk3_gaNTE5MDMxNzA4LjE3NjQ2NzUzOTc._ga_TM99KBGXCB*czE3NzE0MTc4MTIkbzQ0JGcxJHQxNzcxNDE4NDIxJGoyNCRsMCRoMTIwNjE4Nzg is that "token" file name - and it's content. Generated by Letsencrypt, give by Letsencryped to "acme;sh" who creates the token file here /usr/local/www/.acme-challenge/TOKEN with the given content. Then Letsencrypt accesses this file http://sftp.famvanbreda.nl/.well-known/acme-challenge/TOKEN which has to exist, and the content has to match. This is, in short, the test where you prove you are the owner of "sftp.famvanbreda.nl" because only you (as the owner admin of the domain name) can make this work. @louis2 said in Do not manage to generate Certificate (using ^Webroot local folder^): haproxy ... adds another layer of complexity ^^ [image: 1771430516395-79afc7a3-4ddb-4254-9ed5-3a47d561c6fa-image.png] doesn't seem correct to me. That path is not valid. acme.sh is a shell script, and has no notion of 'web root', so I really presume it has to be the rezal local filesysem path = /usr/local/www/.well-known-challenge/. But take my words as a 'thought' because I never used the 'http' method.

Saw 1.1_1 and installed it. Case closed

https://forum.netgate.com/topic/200015/acme-pkg-v1.1

At some point after that version there were changes made to Font Awesome which required adjustments to the format used to display icons like that. It's possible your system has a package that is using the new format which the base OS isn't compatible with. Updating to a current supported version would almost certainly fix it.

It's not really a bug, but a missing feature. The ACME package itself has no support for EAB registration, though some of the CAs now require it or offer it as an option. https://redmine.pfsense.org/issues/16623

Likely the same root issue as https://redmine.pfsense.org/issues/16030. Update to the latest pfSense version and it should work if so.

https://github.com/pfsense/FreeBSD-ports/commit/5ee0e4d0d57f67684563c485d1b5a6e9198fe9af It's in the latest version of the ACME package, which should be up now for Plus 25.07.1 and CE 2.8.1, Plus 25.11 should be up shortly but there's some work that needs to be done on 25.11 package builds which should be resolved before long. (Ignore the "1.1" bit in the commit message, it should be 1.0.3 for Plus 25.07.1 and CE 2.8.1, and1.0.6 for Plus 25.11)

@techpro2004 See here (2020 so yeah, old) : Acme Package with No-IP. As said, this is probably old info now. maybe no-ip is supported, but if you chose them, you have to support them : with your wallet (!) but check first if no-ip can be used with acme.sh. If you want to have a registrar or DDNS supported, add requests here : the source : https://github.com/acmesh-official/acme.sh/pulls as pfSense pulls in the latest acme.sh from there.

@agitelzon I have no issue connecting to LE servers from pf shell. The issue is cloudflare security setting is configured as a whitelist for api zone record changes. The whitelist includes my ipv4 address only, as a /32. As I mentioned, I could add the ipv6 prefix as a /64. Given that pf is configured to prefer ipv4, I thought that would carry over to acme as well.

@acaronmd Updating tends to solve issues. A more recent pfSense version gives you also a newer acme version.

Hi, Please help to forward / report the bugs in ACME 1.0 package. Thanks.

@Gertjan well..... finally i created a new user for inwx and just gave him dns_management role only AND without 2FA. So now all is fine, my PFSense has the LE Cert as it should be. Thanks and kr Mike

Hello, I am also trying to use DNS-NSupdate / RFC 2136 with dynv6.com. I have used all the information in this and the other related thread, but acme.sh blocks when trying to read the key from the disk. The logs show that the key file is expected in /tmp/acme/home-mydomain-tld-test-dynv6/home.mydomain.tldnsupdatealias-mydomain-tld.dynv6.net.key but is actually in /tmp/acme/home-mydomain-tld-test-dynv6/home.mydomain.tldnsupdate_acme-challenge.alias-mydomain-tld.dynv6.net.key Did I mess up the parameters or is there a bug in the call to acme.sh? Thanks for your help, Atanis