Please fill out the fields below so we can help you better. Note: you must provide your domain name to get help. Domain names for issued certificates are all made public in Certificate Transparency logs (e.g. crt.sh | example.com), so withholding your domain name here does not increase secrecy, but only makes it harder for us to provide help.
It produced this output:
TSIG error with server: tsig indicates error
My web server is (include version):
none currently running https
The operating system my web server runs on is (include version):
NetBSD, variously 8.0 and 9.2
My hosting provider, if applicable, is:
I control our domains and servers
I can login to a root shell on my machine (yes or no, or I don't know):
yes
I'm using a control panel to manage my site (no, or provide the name and version of the control panel):
no
The version of my client is (e.g. output of certbot --version or certbot-auto --version if you're using Certbot):using acme.sh
I set up certificates in October 2019, and according to log files everything renewed automatically until mid-February this year. Because of pandemic-related issues we had not actally deployed the generated certificates, so did not notice what had happened.
Now when I try to generate a certificate using updatedns challenge, I get consistentlty the same debug output, where the DNS update appears successful but the readback reports a BADSIG error. Although I've been running our DNS servers for 30 years, I have little experience of DDNS, amd haven't been able to find a way in to resolving this problem.
You need to set the A record for viking.prd.co.uk both in
the prd.co.uk zone (your dns server); and in
the co.uk zone (glue record in the .uk registry dns server)
Currently, they are different (103.117.56.14 and 193.117.56.14). I don't know which one is the right one, but you shall set the same address in both records. -- Ok, 0, 9, this is a case of fat fingers.
(since the 103 server isn't responding, I'd say the right one is the 193 one.)
Well I changed it, but it will take time to propagate. I think the fat fingers were not mine - I don't recall ever having access to that control page before.
What bugs me is that this setup worked consistently for nearly 2.5 years. I work mostly in a CLI environment BTW,, but I'll take a look at acme-dns. I don't even quite get where the bad signature comes from
I didnt' change anthing after 2019 - don't know why the prd.co.uk requests started.
Thanks for the suggestion - suspect the 2nd one will be less relevant
Are you sure they are fresh? The crt.sh does not yet show a new cert. There are delays posting to ct logs but nearly a day is unusual.
The non-wildcard cert renews within a day of your wildcard. If it is not you renewing it that is a big problem Did you test a new method or command options in Aug2020 when that started and left it active? Maybe try acme.sh --list to check it.
They relate to Feb 10 and Feb 11, but had disappeared from my acme.sh
directory structure. Because of a small disaster during an OS upgrade
in early March, the crontab file that managed renewals etc. has been
lost, so I don't properly remember how it was all set up.
The current certificates expire next week. Any advice on how best to
configure things is more than welcome. I run numerous websites and
control the DNS for numerous domains, mostly low-intensity. I want to
keep certificate management as simple as possible, which is why I find
wildcard certs so attractive. I alone have root access to machines
in our network, but I also have a real life where I do substantive
work, so I'm trying to create a setup that takes care of itself as far
as possible.
I do now have one site functioning properly on port 443 and showing
up on browsers as secure, but most of my sites are dynamic
service-delivery portals, and I still have a lot of configuration to
do to make everything works it should.
Better and further particulars. After a lot of trawling through log files, BIND documentation and the like, it seems that indeed something is wrong with signature generation. First, I have successfully updated _acme-challenge.mydomain.tld manually using nsupdate -k /etc/namedb/keys/update.key, which keyfile is identical to its copy in my named.conf, and in my .acme.sh/keys directory.
The acme.sh.log runs up to Feb 15rh - I think the cron job tried to renew daily jus after midnight, but terminated on comparison with the 'not before' date in the certificate. But the fact that zerossl had become the default CA for acme.sh shows up. I was unaware of this, so when I tried a manual run last Friday it defaulted to zerossl, and I wonder if that is the cause of my misfortunes. Nonetheless all my recent attempts have been directed to letsencrypt.
Is it possible that here's a zerossl hash stored somewhere that's entering into the creation of the signasture?
Something I hadn't thought of, but not the answer. As it happens the ntpd process on the machine where I run acme.sh had fallen over, and the clock was 2 minutes slow. But that was easy to rectify.
I don't have any insight into the way the failing signature is generated and compared. My (possibly naive) assumption is that the letsencrypt server uses the key(s) in my .acme.sh/keys directory to generate a hash, asks my dns sexxer to do the same and the dns server decides whether or not to permit the update. If that's (approximately) right, how/where can I see what's going on?
Currently I'm stuck, with my certificate about to expire.
So I ran my named in the foreground with -debug 9 and captured the following:
06-May-2022 13:29:17.652 client 193.117.56.2#58953: UDP request
06-May-2022 13:29:17.652 client 193.117.56.2#58953: using view '_default'
06-May-2022 13:29:17.652 client 193.117.56.2#58953: request is not signed
06-May-2022 13:29:17.652 client 193.117.56.2#58953: recursion available
06-May-2022 13:29:17.652 client 193.117.56.2#58953: query
06-May-2022 13:29:17.652 client 193.117.56.2#58953 (_acme-challenge.prd.co.uk):
query '_acme-challenge.prd.co.uk/SOA/IN' approved
Is the "request is not signed" message relevant? The TSIG error messages occur later, and they speak of an invalid rather than absent signature, like this:
06-May-2022 13:29:17.651 tsig key 'update': signature failed to verify(1)
06-May-2022 13:29:17.651 client 193.117.56.2#58953: request has invalid signature: TSIG update: tsig verify failure (BADSIG)
Did you test a new method or command options in Aug2020 when that started and left it active? Maybe try