@Gertjan
Hmm. I desabled my "HTTP to HTTPS" NAT rule (created as in the video i posted), and it worked.

LE_Root_Cert Renewing certificate account: LE_Cert server: letsencrypt-staging-2 /usr/local/pkg/acme/acme.sh --issue -d '*.XXX.top' --dns 'dns_namesilo' --home '/tmp/acme/LE_Root_Cert/' --accountconf '/tmp/acme/LE_Root_Cert/accountconf.conf' --force --reloadCmd '/tmp/acme/LE_Root_Cert/reloadcmd.sh' --log-level 3 --log '/tmp/acme/LE_Root_Cert/acme_issuecert.log' Array ( [path] => /etc:/bin:/sbin:/usr/bin:/usr/sbin:/usr/local/bin/ [PATH] => /etc:/bin:/sbin:/usr/bin:/usr/sbin:/usr/local/bin/ [Namesilo_Key] => 74XXXX30 ) [Fri Jul 17 18:21:16 CEST 2020] Single domain='*.XXX.top' [Fri Jul 17 18:21:16 CEST 2020] Getting domain auth token for each domain [Fri Jul 17 18:21:18 CEST 2020] Getting webroot for domain='*.XXX.top' [Fri Jul 17 18:21:18 CEST 2020] Adding txt value: GXCXXXtQY for domain: _acme-challenge.XXX.top [Fri Jul 17 18:21:20 CEST 2020] Successfully added TXT record, ready for validation. [Fri Jul 17 18:21:20 CEST 2020] The txt record is added: Success. [Fri Jul 17 18:21:20 CEST 2020] Let's check each dns records now. Sleep 20 seconds first. [Fri Jul 17 18:21:40 CEST 2020] Checking XXX.top for _acme-challenge.XXX.top [Fri Jul 17 18:21:41 CEST 2020] Domain XXX.top '_acme-challenge.XXX.top' success. [Fri Jul 17 18:21:41 CEST 2020] All success, let's return [Fri Jul 17 18:21:41 CEST 2020] Verifying: *.XXX.top [Fri Jul 17 18:21:44 CEST 2020] Success [Fri Jul 17 18:21:44 CEST 2020] Removing DNS records. [Fri Jul 17 18:21:44 CEST 2020] Removing txt: GXXXXQY for domain: _acme-challenge.XXX.top [Fri Jul 17 18:21:46 CEST 2020] Successfully retrieved the record id for ACME challenge. [Fri Jul 17 18:21:47 CEST 2020] Successfully removed the TXT record. [Fri Jul 17 18:21:47 CEST 2020] Removed: Success [Fri Jul 17 18:21:47 CEST 2020] Verify finished, start to sign. [Fri Jul 17 18:21:47 CEST 2020] Lets finalize the order, Le_OrderFinalize: https://acme-staging-v02.api.letsencrypt.org/acme/finalize/14XXX77 [Fri Jul 17 18:21:48 CEST 2020] Download cert, Le_LinkCert: https://acme-staging-v02.api.letsencrypt.org/acme/cert/faXXXdc [Fri Jul 17 18:21:49 CEST 2020] Cert success. -----BEGIN CERTIFICATE----- MIIXXX XXXX XXXXM4s= -----END CERTIFICATE----- [Fri Jul 17 18:21:49 CEST 2020] Your cert is in /tmp/acme/LE_Root_Cert//*.XXX.top/*.XXX.top.cer [Fri Jul 17 18:21:49 CEST 2020] Your cert key is in /tmp/acme/LE_Root_Cert//*.XXX.top/*.XXX.top.key [Fri Jul 17 18:21:49 CEST 2020] The intermediate CA cert is in /tmp/acme/LE_Root_Cert//*.XXX.top/ca.cer [Fri Jul 17 18:21:49 CEST 2020] And the full chain certs is there: /tmp/acme/LE_Root_Cert//*.XXX.top/fullchain.cer [Fri Jul 17 18:21:49 CEST 2020] Run reload cmd: /tmp/acme/LE_Root_Cert/reloadcmd.sh IMPORT CERT LE_Root_Cert, /tmp/acme/LE_Root_Cert/*.XXX.top/*.XXX.top.key, /tmp/acme/LE_Root_Cert/*.XXX.top/*.XXX.top.cer update cert![Fri Jul 17 18:21:49 CEST 2020] Reload success

However, I changed from staging to production, and it did not work. Same as before

Hetzner : it could be as easy as coping this file https://github.com/acmesh-official/acme.sh/blob/master/dnsapi/dns_hetzner.sh into /usr/local/pkg/acme/dnsapi/ , with all the other dns_ files.

Because you use Hetzner, you know all about how Hetzner works.
Something special can be seen at the top 4 lines of the file :

#!/usr/bin/env sh # #HETZNER_Token="sdfsdfsdfljlbjkljlkjsdfoiwje" #

This means : obtain the token from Hetzner, and place it in the file.
And you remove the leading '#'.

No complicated terms are needed.
Try this no-i p acme **

You find your answer on the very first link. The article is filled with the words 'purchase' here, 'purchase' there and you'll ask : where is the acme term. Knowing that a script called acme could be used to get certs from LetsenScrypt.

So, take the second link :Let’s Encrypt Certificate with DNS verification with No-IP and read on ... the answer is at the end. Remove "-ip" to leave you with "no".

Btw : if no-ip could be used with Letsenncrypt cert (renewal) they would have stated that as a huge advantage - right at the top of their support/faq/manual.

Nothing changed on their side.
Neither acme, recently.

Time to check the acme log, see if it really creates / updates the TXT record ?!

If you want to access via IP and not have your browser scream at you.. Just create your own certs using local CA you can create on pfsense. Then trust that..

That is what I do.. So I can access pfsense with its fqdn sg4860.local.lan or its IP.. or even the old name I use to use pfsense.local.lan

ownca.jpg

And since created before they started changing the max life, mine are good for 10 years ;)

@asche said in Unable To Renew Certs Since last ACME package Update:

NO, I do not use CARP nor sync nor HAProxy Sync (all are off / disabled)

If you dont sync to anywhere, then you probably don't have anything to restart 'remotely', so yes delete that action. You might want to restart the local haproxy service and webgui though. Use the example "shell command" options for that.

This :

8b9ee9dd-7485-4377-94cf-6d9dcf35c229-image.png

is the Let'senscrypt' intermediate certificat, not the certificate you received from Letsenscrypt.

When you inspect the sit's (pfSense) cert with a normal browser like FF, you'll see the 3 of them :

0ebbb6d7-b950-415a-9e97-965374ce960b-image.png

Yours is the most left one.
Like mine : 4096 ....
But hey, even 2048 will do for decades ...... although you have to trach it after 90 days max.

edit : also .... the details of the cert you showed last for some 15 months .... that's not the 90 days max duration Letsencrypt is advertising with ;)

@PiBa
I believe that the reference to the cert was valid. If memory serves me correctly, there were validation problems with the acme-challenge or missing txn parameters for acme's Domain SAN list / DNS-[provider] method. Perhaps that caused an empty cert file.

The ^M remains as before, and now Let's Encrypt successfully verifies the domain.

@jimp

Easy, thx!

Finally got time to go back to the certificates and I can confirm that the latest update has fixed my issue.

Thanks much appreciated.

If you are on 2.4.4-p3, then 0.6.5 is the latest version you can safely install. You must upgrade to 2.4.5 to get the latest packages.

Installing 2.4.5 packages on 2.4.4-p3 is dangerous.

The issue was definitely with ZoneEdit. I re-edited the nameservers in ZoneEdit, saved, and after a while Quad9 and Cloudflare DNS servers were serving up HE's nameservers.

@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