Solved: A silly error on my part while creating certs in ACME. I deleted the unused ACME cert from within ACME and the issue was resolved.

@strongthany said in Not able to renew ACME certificate:

They looked to be the same.

Look again. The're not the same. The 'source' @github is more recent.

@strongthany said in Not able to renew ACME certificate:

while the ACME script on pfsense was using a TTL of 60

There is a explanation for this.
The typical default value is '60 seconds'.
But, this value can not be assumed as "ok".

IMHO : this is the story :

acme.sh - using a API script, signals the registrar, to add a ".well-known.acme-challenge" subdomain to your domain name - and a TXT record with a 'secret' value like "NYDVT9Yjt-dCW8dPQIaMW57sjRQqR7s-w-I7g2CDPh".
So far, so good.
No rocket science here, as we all added ones something like www. or mail. or pop. or smtp.
This time it's a script adding a sub domain.
The registrar will update the master domain name server.
And, as we all know, there are always at least TWO domain name servers, the master and one or more slave.
Typically, when the master gets updated, the master signals the slave(s) that an update is available.

And now the important part : the slave will contact the master back, to sync with it when it sees fit (the domain info XFER). Anything between 'right now' or "later" is possible.
Take note : the master domain server and the slave(s) probably do not only handle your domains, but also several (thousands of) other domain names.

Now you understand that, when you start to the acme.sh package, you need some time and play with the "dig" command ** to find the worst case scenario : the maximum DNS-sleep delay between the start, and when the (all the) slave(s) gets updated.

In the good old days, when Letenscrypt started, and automation tools like acme.sh showed up, the DNS-sleep time was less critical, because Letenscypt only verified the master domain server.
These days, it checks all listed domain server : the master and all the slaves.

Now you understand why the "DNS-sleep" value really matters.

** playing with dig : I didn't test all this, so see what follows as a guide line :

First, get a list off all your domain name servers.

dig test-domaine.fr NS +short ns2.test-domaine.fr. ns1.test-domaine.fr. ns3.test-domaine.fr.

Get the master domain server :

dig test-domaine.fr SOA +short ns1.test-domaine.fr. postmaster.test-domaine.fr. 2021032645 14400 7200 1209600 43200

So it's "ns1.test-domaine.fr".

Start the acme.sh cert renewal.

Spam :

dig @.well-known/acme-challenge .well-known/acme-challenge/test-domaine.fr TXT

As soon as you get a value back like

dig @ns1.test-domaine.fr .well-known.acme-challenge.test-domaine.fr TXT +short "NYDVT9Yjt-dCW8dPQIaMW57sjRQqR7s-w-I7g2CDPh"

You know that the API acme.sh part used worked : the registrar was contacted and updated the master DNS.

Now, start spamming :

dig @ns2.test-domaine.fr .well-known.acme-challenge.test-domaine.fr TXT +short dig @ns3.test-domaine.fr .well-known.acme-challenge.test-domaine.fr TXT +short

(remember : I have two DNS slave servers).
As soon as both return

"NYDVT9Yjt-dCW8dPQIaMW57sjRQqR7s-w-I7g2CDPh"

you can stop de clock : you have your "DNS-sleep".
Add some spare time, as no one can guarantee that you'll find the same value ?! ;)

Btw : I guess that you understood by now that when you want to use certificates, you need to know 'something' about what is called 'DNS' 😊

Also : The DNS-sleep values isn't really needed as some active polling could be used - the commands I executed above. "acme.sh" script would find the right moment to signal the 'Go check" to Letensrypt every time itself .....

@jhorne LetsEncrypt will sign multiple certificates for the same domain(s) within the published rate limits. This would be the easiest solution.

ref : https://letsencrypt.org/docs/rate-limits/

Currently trying the same and login succeeds... but it cannot determine the domain entry - and the complete _acme - txt entry is already in my plesk dns!

[Fri Jul 2 09:15:24 CEST 2021] Checking if '_acme-challenge.gitlab.lab.MYDOMAIN' is managed by the Plesk server... [Fri Jul 2 09:15:24 CEST 2021] No match, trying next parent up... [Fri Jul 2 09:15:24 CEST 2021] Checking if 'gitlab.lab.MYDOMAIN' is managed by the Plesk server... [Fri Jul 2 09:15:24 CEST 2021] No match, trying next parent up... [Fri Jul 2 09:15:24 CEST 2021] Checking if 'lab.MYDOMAIN' is managed by the Plesk server... [Fri Jul 2 09:15:24 CEST 2021] No match, trying next parent up... [Fri Jul 2 09:15:24 CEST 2021] Checking if 'MYDOMAIN' is managed by the Plesk server... [Fri Jul 2 09:15:24 CEST 2021] No match, and next parent would be a TLD... [Fri Jul 2 09:15:24 CEST 2021] Cannot find '_acme-challenge.gitlab.lab.MYDOMAIN' or any parent domain of it, in Plesk. [Fri Jul 2 09:15:24 CEST 2021] Are you sure that this domain is managed by this Plesk server? [Fri Jul 2 09:15:24 CEST 2021] Error add txt for domain:_acme-challenge.gitlab.lab.MYDOMAIN [Fri Jul 2 09:15:24 CEST 2021] _on_issue_err

I've replaced the domain by MYDOMAIN in the above output.
Any idea or update on this post?

@aramakrishnan said in Lets Encrypt Pfsense package Cert failed to renew automatically using digital ocean API:

is there any fix available?

Nothing has been changed for the last 12 months, upstream.

If there was an error, you were told to look at the log file if you want to know the 'why' part.
/tmp/acme/[acme account name]/acme_issuecert.log
What is the issue ?

@gertjan
Hi gertjan, thanks for the info now i am able to create CERT.

I have one more question, i have HA setup of Primary and secondary node pfsense.
What is the best way to configure ACME CERT sync with Primary to secondary. Both nodes have acme and HAProxy package installed when i see on secondary node in Acme certificates - CA i found CA not listed not sync.
But when i go to secondary node, System - Cert Manager - Certificates i found certificate synced here.

Do we really need to install ACME package on secondary node? Sync is working fine with other things but only ACME cert sync has problem.

I would like a setup when one node fail, second carry on everthing.

Thanks in advance.

[SOLVED]

Problem fixed.

It was due to an issue with DNS propagation on the domain name provider (OVH) side which also handles DNS service for the affected domain.

See: https://translate.google.com/translate?sl=auto&tl=en&u=http://travaux.ovh.net/?do%3Ddetails%26id%3D51225%26

@sshami

@sshami said in Pfsesne Let’s Encrypt error issuing Certificate:

What would be posible cause

You have to own = rent "name.domainname".
You have a A record setup that point to an IP.
On this IP you should have a web server, that should answer, at least, '80' (http).

@jackus Ok solved it my self.
It seems that you cannot use 127.0.0.1 anymore for the acme backend.
I change the backend to LAN IP address and al worked again.

@lifeboy said in Cannot reach api server from pfsense:

acme doesn't read the TXT record and then creates a new TXT to add

Letenscrypt generates a random 'code' - this will become the content of the TXT record, hand over this content to the acme.sh script - as it asks for it. acme.sh knows how to set it up, as, for example, a DNS TXT record : you have to choose the 'method'. When done - a time wait can be needed know, as DNS slaves have to sync with the DNS master server you changed, it signals Letsencryt that's it's done.
Now, Letenscrypts test the presence of this of this TXT record on any (or all now ?) of your domain's name servers .
If the test == proof that you control the domain name, succeeds, Letsencrypt will cache the result for a week or so : renew you cert the next day, and you'll see there is no DNS TXT hassle any more.
Also : at the end of the acme.sh script, with a positive result, or not, acme.sh will remove the added TXT record, thus leaving no trace in the zone / DNS structure.

@sdowling said in Cannot Renew LetsEncrypt Cert:

Wait a bit of time (5 mins), then hit the 'Renew' button and

..... wrong ^^

Why passively wait ?
Make it an active wait.

You add the TXT record with the google domain record GUI.

Now, start polling it : have pfSense ask for that TXT record :

dig @127.0.0.1 _acme-challenge.your-domain.tld TXT

and repeat this until you get your -correct - TXT record back.
Now you know the TXT is valid for you, and also for Letsenscrypt.
This is the moment you can proceed.

Btw : the DNS propagation time is somewhat random.
Do the check yourself :
As for all the DNS name servers of your domain :

dig @127.0.0.1 your-domain.tld NS

You get a list back with all the DNS servers for your domain.

dig @ns1.your-domain.tld _acme-challenge.your-domain.tld TXT dig @ns2.your-domain.tld _acme-challenge.your-domain.tld TXT dig @ns3.your-domain.tld _acme-challenge.your-domain.tld TXT

etc. (there should be at least two NS servers)
They all have to return the valid TXT record.

Btw : the acme DNSAPI automates this adding (and deleting !) of these records. Authentication will be needed of course, as you have to ID yourself to get access to the GUI to modify a DNS record yourself, and when that's done, it's a pretty straightforward process.

👍 @regexaurus

Alternative ways to kill the duck-bug :

Instead of the always needed SSH - so ok to have it set up ones : use the classic console access, as this should work to.

Or : install the System_Patches pfSense package, which exists for doing just that.
Now, if we can get our hand on raw the diff file (and get the paths correctly) its just a question of copying the commit ID URL and two more clicks (patching without a keyboard).

@lftiv Thanks so much for that! I had renamed the keys at some point since last renewal and was at my wits end why it wasn't working.
So sad that this is still a problem!

@jimp Thanks for the suggestion. I do get the following error on reboot with filesystem check, even after uninstalling the haproxy package in the GUI.

11:24:34 PHP ERROR: Type: 64, File: Standard input code, Line: 4, Message: require_once(): Failed opening required 'haproxy/haproxy.inc' (include_path='.:/etc/inc:/etc/inc/web:/usr/local/www:/usr/local/captiveportal:/usr/local/pkg:/usr/local/www/classes:/usr/local/www/classes/Form:/usr/local/share/pear:/usr/local/share/openssl_x509_crl/')

I just updated from 2.4.5 to 21.02 with an image from Netgate. I will try reinstalling it.

@appollonius333 said in Using ACME with Bind9 package and Cloudflare:

You think it will do any harm to use a public domain for my private network?

As long as the you own (= rented) the domain name : you have no choice.
You can only asks for certs for domain names for which you can prove that you control.

@appollonius333 said in Using ACME with Bind9 package and Cloudflare:

I hear people saying yes because it increases your attack surface but others also say no because they do not know where the 'domain' is aiming to. Also nobody knows the domain exempt me.

Yeah, there are also people that want phones without numbers.
An cars without licence plates.
Etc.
If you want to use a public 'thing', you have to conform to the usage rules of the public thing.
IP addresses and host names can't really be hidden.

Asking a cert from Letsencrypt for a domain name doesn't make that domain name publicly known, although it will figure on yet another (huge !) list ^^

Your domain name doesn't have to point to the IP of your WAN, or something like that.
But that's what I'm doing :
I have this my-domaine.net that I'm actually using just for my LAN, like pfSense, my NASes, printers and such. I'm not really using this domain name on the net. I have acme.sh asking for a wild car cert, so I can create host names with a cert like
pfsense.my-domaine.net, nas .my-domaine.net, printer1.my-domaine.net, printer2.my-domaine.net, airco.my-domaine.net etc. Now all these devices have https access.

I did create a sub domain like home.my-domaine.net on the name server (my own 'bind' based name servers) on the internet, have this sub domain pointing to my WAN IP (using DDNS if it's not static) so I can access my pfsense from else here, using OpenVPN. this is what I'm doing (and not related to acme).

Btw : lab.nl is a domain that is owned (rented) by some one. You can't use it.