Not able to renew ACME certificate
I am trying to get ACME certs to renew on my firewall but get the following whenever I try to run this(changed url name for privacy)
myurlWildcard Renewing certificate account: myurl Wildcard Staging server: letsencrypt-staging-2 /usr/local/pkg/acme/acme.sh --issue --domain 'myurl.cc' --domain-alias 'myurl.cc' --dns 'dns_desec' --domain '*.myurl.cc' --challenge-alias 'myurl.cc' --dns 'dns_desec' --home '/tmp/acme/myurlWildcard/' --accountconf '/tmp/acme/myurlWildcard/accountconf.conf' --force --reloadCmd '/tmp/acme/myurlWildcard/reloadcmd.sh' --log-level 3 --log '/tmp/acme/myurlWildcard/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/ [DEDYN_TOKEN] => _Rv728509LQmnfhJ4Ze4zUOFv4cc [DEDYN_NAME] => email@example.com ) [Tue Jul 6 08:45:57 CDT 2021] Using CA: https://acme-staging-v02.api.letsencrypt.org/directory [Tue Jul 6 08:45:57 CDT 2021] Multi domain='DNS:myurl.cc,DNS:*.myurl.cc' [Tue Jul 6 08:45:57 CDT 2021] Getting domain auth token for each domain [Tue Jul 6 08:46:00 CDT 2021] Getting webroot for domain='myurl.cc' [Tue Jul 6 08:46:00 CDT 2021] Getting webroot for domain='*.myurl.cc' [Tue Jul 6 08:46:00 CDT 2021] Adding txt value: NYDVT9Yjt-dCW8dPQIaMW57sjRQqR7s-w-I7g2CDPhY for domain: myurl.cc [Tue Jul 6 08:46:00 CDT 2021] Using desec.io api [Tue Jul 6 08:46:00 CDT 2021] invalid domain [Tue Jul 6 08:46:00 CDT 2021] Error add txt for domain:myurl.cc [Tue Jul 6 08:46:00 CDT 2021] Please check log file for more details: /tmp/acme/myurlWildcard/acme_issuecert.log
It looks to be similar to this issue but no answers there.
I had made a CNAME record for my domain on deSEC but I don't think that helped.
Wanting to know if there is anything I missed or should check. Thank you!
Gertjan last edited by Gertjan
The on-screen log told you :
acme.sh works, as it does for millions right now.
Check the detailed log for more info.
The issue is probably : the "interface", the API script, that interfaces with acme.sh and your registrar.
The file is called dns_desec.sh
Check with the source - https://github.com/acmesh-official/acme.sh/blob/master/dnsapi/dns_desec.sh with what you have ( here /usr/local/pkg/acme/dnsapi/) and you'll find out that you do not use the latest version.
Copy paste it and try the more recent version ?!
( to got back : re install the acme package - or keep a local copy of the .sh file)
edit : there is no difference between asking an first certificate, and renewing it. "renewing" doesn't exist : go get a new certificate, so the procedure that worked ones is used again.
The renewing procedure, a cron task that executes ones a day and test if the cert is xx days old, does work.
I tried comparing the script on my firewall with the one on the github. They looked to be the same. I had recently updated the plugin but reinstalled it per your suggestion, though I am still having issues after that.
I don't mean to say that the plugin is working, as I'm sure it's working for plenty of people. What I need assistance with is getting it to work in conjunction with desec. I previously had been using it with the digital ocean plugin and that worked. But since migrating my DNS over to desec, I have not been able to issue/renew certificates due to unknown reasons.
Do you know what I need to change in my configuration in the acme plugin?
Domainnamespot is for my domain, spelled out in the format of
- The token is the API token generated from DeSec
- The Name field is the email address I use to log into DeSec
Solution has been found. The TTL for desec has a minimum of 3600, while the ACME script on pfsense was using a TTL of 60. The normal ACME script can be found here. I'll make a pull request on the plugin's github page to fix this issue.
If you, random internet person who looked up those log lines have this problem, you need to get into the cli for your firewall(ssh or otherwise) and edit the desec script to have the higher ttl.
Gertjan last edited by
They looked to be the same.
Look again. The're not the same. The 'source' @github is more recent.
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.
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
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 .....