ACME with NSUPDATE not working


May 13, 2020

i am trying to use LetsEncrypt certificates using Acme in Proxmox 6.2 with the new DNS verification. Specifically, I am trying to use nsupdate.

Following the instructions in [1] and the information in [2], I have created a new ACME challenge configuration in my Datacenter configuration, and have used the variables indicated in [2], in the form:



When I try to order the certificate, I get the following error:

Loading ACME account details
Placing ACME order
The validation for proxmox.[MYDOMAIN] is pending!
[Wed May 13 13:09:13 CEST 2020] key "/etc/pve/nsupdate.key" is unreadable
[Wed May 13 13:09:13 CEST 2020] Error add txt for domain:_acme-challenge.[MYDOMAIN]
TASK ERROR: command 'setpriv --reuid nobody --regid nogroup --clear-groups --reset-env -- /bin/bash /usr/share/proxmox-acme/proxmox-acme setup nsupdate proxmox.[MYDOMAIN]' failed: exit code 1

I have moved the nsupdate.key file to different locations, and have made it world-readable. I have even changed its owner to be "nobody" with group "nogroup", but since the command seems to drop all privileges, it fails to read the file no matter what I do or where it is located.

I have used nsupdate manually with that same nsupdate.key file, and I can see that it does update my remote DNS. So either I am doing something wrong here, or the way that the ACME implementation in Proxmox tries to do nsupdate does not work and this may be a bug.

Any help would be appreciated! Thank you very much in advance!
  • Like
Reactions: lexxai
thanks for reporting! seems like the nsupdate api requires some special handling - could you file a bug at for easier tracking, and we'll see what we can do about supporting it properly.
I copy key file to NFS common disk, for cluster nodes, and change mode as
chmod 644 ns-update.key
And now ACME certificate with DNS plugin nsupdate - updated successfully.

on /etc/pve user can't change not mode of file not ownership of file.
script runned as nobody:nogroup
Last edited:
Hope I'm not kicking a dead horse, but you need to remote the quotes from the value: NSUPDATE_KEY=/etc/pve/nsupdate.key
I had a similar issue and had to remove 'export' from the front of the variables specified in the docs ...



instead of -

export NSUPDATE_KEY=/mnt/pve/cephfs/nsupdate.key

I changed and tried a few things in a short period (all suggested here - removing the quotes, and moving the key out of /etc/pve), but I think removing export is what did it.
Sorry for bumping an old thread, but did anyone end up getting this working?
I'm trying to get a certificate for a server that has no open ports to the wider internet, but my external name server will happily take nsupdate input.

Sadly, I'm getting the same "key unreadable" error when I try to get a certificate
@TonyArr, last time I tried this following suggestions from the comments on the forum it did not work for me with the scripts included with proxmox. So I used a different script that replaces the one provided by Proxmox, which works for me. I have a cron job that warns me if the script changes.

I will upload this later.
  • Like
Reactions: CanadaGuy
@TonyArr, last time I tried this following suggestions from the comments on the forum it did not work for me with the scripts included with proxmox. So I used a different script that replaces the one provided by Proxmox, which works for me. I have a cron job that warns me if the script changes.

I will upload this later.
Thanks, I use dehydrated on my existing systems, but figured since I'm using proxmox to replace those systems I'd try get it to handle everything I can with it's built in tools. Guess I'll bring my dehydrated configs over as well.
I'd love to see your script still, see if there's anything I'm doing that yours does better, which is likely since all my existing stuff is pretty hodge-podge. Seeing how you wrap it into Proxmox would be very useful too, when you get the time! :)
I have attached the scripts here. I had to add ".txt" at the end so they could be uploaded.

  • is located in /usr/share/proxmox-acme/dnsapi/
  • is located in /root/, and is invoked every night via cron, with an entry like the following one:
    00 10 * * * /root/


    3.4 KB · Views: 31
    782 bytes · Views: 22
  • Like
Reactions: CanadaGuy
I had a post but I deleted it because I interpreted the instructions incorrectly. My interpretation was that "my.key" in the step cat my.key | base64 -w 0 was the secret itself without the rest of the TSIG key file formatting. For future readers, to use these scripts you need the base64 encode of the TSIG key file itself that should look something like this:
key "proxmoxdns" {
        algorithm hmac-sha512;
        secret "+YFmSvlP5J8ofrHFZX+qd2ZqpTvIOc3==";
  • Like
Reactions: Hyacin
Just got an email today from the server. If you are using this modification, a recent patch reverts the changes for this fix. If you aren't using the example script to check and restore the fix, you might need to check your server.
Last edited:
  • Like
Reactions: radn
I'm not sure if or how this was working for me, but the 'like' I put above at some point in the past indicates I've clearly been here before! :-/

I was using a key on my cephfs but I just ripped out ceph a month or so ago and forgot about the key! Cert update failures began today, lol.

I tried a couple other locations in the fs and got the "not found" error that led me (back) to this thread ... so I've modified my script as instructed and replaced the key in my acme config with the base64 encoded version, but now I'm getting -

[Fri Apr 21 02:51:40 EDT 2023] key a2V5ICJkZ<redacted>jsKfTsK is unreadable


Stumped. But it's also 3 AM so that could have something to do with it.

Any input would be greatly appreciated!

I did verify all the scripts on ALL my nodes have been updated to the version with the _dbase64 modification :-/

Edit: Ah! Got it! I missed the "Change "_checkKeyFile" to return immediately." instruction. Working now.

Still wonder how I saw this thread before but managed to use a key file on the system subsequent to that though :confused:
Last edited:
  • Like
Reactions: radn
For anyone still wondering - just put the key-file in /usr/local/share or similar and give o+r permissions or chown to nobody:nogroup
Works like a charm. Is it secure to leave your key in the open? not very much.

To make user friendly split into key-name and secret field rather than keyfile.


The Proxmox community has been around for many years and offers help and support for Proxmox VE, Proxmox Backup Server, and Proxmox Mail Gateway.
We think our community is one of the best thanks to people like you!

Get your subscription!

The Proxmox team works very hard to make sure you are running the best software and getting stable updates and security enhancements, as well as quick enterprise support. Tens of thousands of happy customers have a Proxmox subscription. Get your own in 60 seconds.

Buy now!