@costanzo FYI - It's showing the correct version this morning. Just needed to wait.

Made further changes and now getting: head: illegal byte count -- -2 [Fri Apr 24 15:43:46 ADT 2020] Multi domain='DNS:protector.accra.ca,DNS:geneabujold.accra.ca,DNS:remotehelp.accra.ca' [Fri Apr 24 15:43:46 ADT 2020] Getting domain auth token for each domain [Fri Apr 24 15:43:48 ADT 2020] Getting webroot for domain='protector.accra.ca' [Fri Apr 24 15:43:48 ADT 2020] Getting webroot for domain='geneabujold.accra.ca' [Fri Apr 24 15:43:48 ADT 2020] Getting webroot for domain='remotehelp.accra.ca' [Fri Apr 24 15:43:48 ADT 2020] Adding txt value: 9yxloPu3sHM1YzQRJicL-EUeYdXRZQ2CsMZeJic80Mk for domain: _acme-challenge.protector.accra.ca head: illegal byte count -- -2 [Fri Apr 24 15:43:49 ADT 2020] invalid domain [Fri Apr 24 15:43:49 ADT 2020] Error add txt for domain:_acme-challenge.protector.accra.ca [Fri Apr 24 15:43:49 ADT 2020] Please check log file for more details: /tmp/acme/accra/acme_issuecert.log

Using the latest. acme and PFsense. Updated this morning acme to 0.6.7. and will try to update again. With regards to your question is they do offer nsupdate, the issue is that it needs that all records have to be sent. we have over 250 records in our DNS and they are the primary. Concerned about something going wrong and affecting something else Before we upgraded to 2.4.5 and 0.6.6, the api to DNSmadeEasy was working for the past 3 years without a hitch. They are confirming the issue I see that the plugin is not negotiating the authentication properly "the API is saying that it is unable to verify the HMAC"

Then I'd check that. It doesn't look like it's doing what you think it should be doing.

@Gertjan I confirmed that the last solution works for me too (unbound, Restart Local Service).

@Risfold said in DoH Verification Method: I have just started having the same issue, and came across this thread in researching it. I hope to revive the discussion. I also use the above referenced DoT/DoH blocking list. I block the the domains and IPs via pfblocker for LAN clients to stop any circumvention of DNS or hard coded DNS in clients. I alternatively use DoT from unbound in pfsense. The acme.sh discussion of this addition appears to be here, added mid-February 2020. It is discussed as "support" for DoH, but it appears to be implemented more as a change rather than an option. I fully support the addition of DoH in acme.sh, even as a default, but is there a way to turn off the use of acme.sh's use of DoH, and return to using the firewall for DNS? I could temporarily disable my blocking of DoH but that would defeat the purpose of automated certificates. Work around noted here. add dnssleep time of 180

Logs ? Open a console, SSH, or better SFTP and look in /tmp/acme/your-domain.tld - there is a dot log file. This one : [image: 1585292053347-112f5526-6111-4ba0-ad23-9802642eac83-image.png] Also : If I visit : [image: 1585291896208-2ea7a531-3b5f-4933-9840-3c6459963808-image.png] I have a TLS error - as acme has : [image: 1585291928953-d44fcbf1-8c98-4ae5-a1e8-5114913e991d-image.png] because the cert is expired since March 6. So, when the Letenscypt hits that site, it will bail out. I'm not using HAProxy myself, neither the acme webroot method. What about : pfsense haproxy acme ,

@Blfrg Thanks, that worked perfectly. Your last fix also works with the GUI of PFSense when added from hand. After merge all should be fine again. Thanks for your patch!

@Wasca Thank you for reporting the issue! A pull request has been created here Please watch for that pull request to be merged and the fix should be available in the next acme.sh release (>2.8.6)

Also noteworthy that I am still occasionally seeing account registration/verification failures over IPv6 even when attempting renewals. If you get a cURL error (like error 35) when attempting to renew, set the firewall to prefer IPv4: System > Advanced, Networking tab, check Prefer to use IPv4 even if IPv6 is available. Then try the ACME renew again.

The resulat (green text) said already to you : [image: 1582800205180-d643c3b0-666f-4b89-b9a5-843a3984ed7a-image.png] But this could be an important indication : [image: 1582800187207-bc053a13-aa12-496d-92a6-bf53421a2632-image.png] Let me rephrase that message : the acme.sh couldn't add the "_acme-challenge.............." to your domain. A problem with the domain ? An API error ? The registrar that hosts the API has problems ? Can't tell much more.

@PiBa I use the 'simple' haproxy package. I am not blocking anything special. pfSense and all packages are on newest versions. I also disabled snort, pfblocker and everything else during debugging. As i said, it worked before moving from bhyve to proxmox. Or probably what counts more is before backup up and restoring on a clean install. But nevermind, i got it working now by using the haproxy chroot'ed webroot instead of standalone http server. After hours or fiddeling i have up on the other solution and switched all my certs to webroot. This is even faster as the script does not have to spin up an extra http server ... But thank you for taking the time to reply ;-)

I would not consider TFTP safe by any means. It's unencrypted and unauthenticated. So you can't verify that the client is pulling the certificate from the proper source or ensure that it has not been interfered with along the way. On a local network that may not appear like a huge concern, but it's best not to get complacent or make assumptions when dealing with security. If you are only transferring the certificate and not private key data then the unencrypted part isn't as large of a concern. Some people write the certs to a central location and copy them around with scp, which is better. Though it sounds like you're using the ACME package for a role it really was not intended to fill. You might be better suited using a dedicated ACME setup on a local system (small VM, Pi, etc) which can securely deploy the certificates in a manner better suited for your needs.

Before posting : [image: 1581971270021-7f2dd95b-5c4d-4013-820c-42ca9263efa6-image.png] Right after manual cert renewal : [image: 1581971821052-86f8b0a5-1058-43d1-844a-2c70ee1ac91c-image.png] You saw the date/time change ? The concerned <cert> .... <crt> ........</crt> ..... </cert> in the config.xml showed me the cert was changed thus saved to config.xml How could pfSense otherwise use the new certificate dater a reboot ? Because it's in the config.xml .... (and no where else). Btw : [image: 1581972096485-a397d082-d42c-478b-b7fc-0eae9ab12b7b-image.png] edit : I tend to say : read the log from /tmp/acme/<your domain>/acme_issuecert.log and you have your answer why it was not renewed and thus why it wasn't written to config.xml and why it didn't doesn't show in System > Certificate Manager > Certificates Edit : See the official video : https://www.netgate.com/resources/videos/lets-encrypt-on-pfsense.html => 49 minutes and 30 seconds ;)

It is fixed: https://github.com/acmesh-official/acme.sh/commit/4f303de00c8d640351db5fb065bf0861786fab18 We need to wait for offical release (2.8.6). Or you can copy acme.sh from master branch it will work as well.

Looks like the error is being sent back from api.dnsmadeeasy.com -- so I'd check your account settings there and the credentials. Maybe they have some limit you're exceeding, or something else wrong.

One of these should work: Method = Restart Local Service, Command = ipsec (This may be enough to refresh the IPsec config, but it's not a full restart) Method = PHP Command, Command = ipsec_configure(true) (This may fail since it may not have the right required libraries) Method = Shell Command, Command = /usr/local/sbin/pfSsh.php playback restartipsec (This may fail since the ACME script which starts the command is PHP, and launching pfSsh.php from within PHP doesn't always work) Method = PHP Command, Command = file_get_contents("/etc/phpshellsessions/restartipsec") (If the shell command fails, this should work instead)