Bad signature error on dns challenge

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. |, so withholding your domain name here does not increase secrecy, but only makes it harder for us to provide help.

My domain is:
I ran this command:

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):
I'm using a control panel to manage my site (no, or provide the name and version of the control panel):
The version of my client is (e.g. output of certbot --version or certbot-auto --version if you're using Certbot):using

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.

Thou shall update your glue records: | DNSViz

1 Like

And, if using HTTP challenge, add an A or AAAA record as appropriate for that domain name

It would be helpful to see the command you are trying


too enigmatic - what needs changing and why?

bash --issue --dns dns_nsupdate --test --debug -d '*'

1 Like

You need to set the A record for both in

  • the zone (your dns server); and in
  • the zone (glue record in the .uk registry dns server)

Currently, they are different ( and 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. :smiley:

(since the 103 server isn't responding, I'd say the right one is the 193 one.)

1 Like

Could be the source of the problem, but this iw with the registrar, no? I haven't touche the NS settings there for maybe a couple of decades.

It's probably not, but you still should correct it.

You might want to see acme-dns, it should be easier to use: GitHub - joohoi/acme-dns: Limited DNS server with RESTful HTTP API to handle ACME DNS challenges easily and securely.

1 Like

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

You are renewing a wildcard cert and a second cert for just the apex name. Does the cert for the apex name fail in the same way as the wildcard?

TSIG is beyond my expertise but I found these two threads in the github. I apologize in advance if these are not pertinent.

Error add txt for domain when using nsupdate
Any way to update DynDNS Standard with TXT record


I didnt' change anthing after 2019 - don't know why the requests started.
Thanks for the suggestion - suspect the 2nd one will be less relevant

1 Like

Something has changed - certificates have appeared. Maybe the glue records were the problem.

1 Like

Maybe it was some transient error you had no control over...

1 Like

Are you sure they are fresh? The 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 :slight_smile: Did you test a new method or command options in Aug2020 when that started and left it active? Maybe try --list to check it.


They relate to Feb 10 and Feb 11, but had disappeared from my
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.

You wrote:

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 directory.

The 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 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?

Check your server time is correct and that all servers are in sync with the same time server. TSIG uses HMAC which in turn uses the current time.


Something I hadn't thought of, but not the answer. As it happens the ntpd process on the machine where I run 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 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 UDP request
06-May-2022 13:29:17.652 client using view '_default'
06-May-2022 13:29:17.652 client request is not signed
06-May-2022 13:29:17.652 client recursion available
06-May-2022 13:29:17.652 client query
06-May-2022 13:29:17.652 client (
query '' 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 request has invalid signature: TSIG update: tsig verify failure (BADSIG)

I still don't know enough about TSIG to help with that.

But, you could try using manual DNS to quick get a cert before it expires.