@talisker said in Renewed certificate was not imported into Cert Manager: One strange thing is that the certificate isn't removed from the /tmp. Nothing is removed from /tmp when exectuing "acme_command.sh importcert" - neither the sub folders and their content. The /tmp folder is only emptied when you reboot pfSense. The "acme_command.sh importcert CERTNAME DOMAIN KEY_PATH CERT_PATH CA_CERT_PATH CERT_FULLCHAIN_PATH" takes old the files created by the acme package (files are stored in /tmp/acme/domain/....) and imports them intp the pfSense "cert Manager". It doesn't wipe them - there is no need to do so. @talisker said in Renewed certificate was not imported into Cert Manager: The certificates from cloudflare (other domain) is removed Test for yourself : Wait a week or so. Now force renew all certs you have. You will find as many /tmp/acme/domain sub folders as you have certs requested. "domain' will be the base domain name; These "domain" folders will stay there. Until you reboot. If you don't reboot after 60 days or so, the content of the certs will get renewed and overwritten.

OK Realy stupid I have two ssh shortcuts to two pfsense servers and was looking at the wrong one. I owe you a beer for waisting your time.

@jimp thank you for your help, much appreciated. Regards, Mauro

That makes sense, since the firewall GUI wouldn't involve CloudFlare. The fact that you were seeing that means it must not have been resolving to something local. A DNS host override is the right thing to do there.

@gertjan thank you for your help. I will take a look very soon.

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.