pfSense - Windows DNS Server (Not AD) - TSIG error with server: tsig verify failure

My domain is:

carrz-fox-fire.com (Primary domain, there are others)

I ran this command:

nsupdate -d -k /tmp/acme/carrz-fox-fire/carrz-fox-fire.comnsupdate_acme-challenge.carrz-fox-fire.com.key
Then

server 192.168.2.32
zone carrz-fox-fire.com
update delete _acme-challenge.carrz-fox-fire.com TXT
update add _acme-challenge.carrz-fox-fire.com 60 TXT "carrz-fox-fire.com"
show
send
It produced this output:

It inserted the test record, but then gave the error.

;; UPDATE SECTION:
_acme-challenge.carrz-fox-fire.com. 0 ANY TXT
_acme-challenge.carrz-fox-fire.com. 60 IN TXT   "carrz-fox-fire.com"

;; TSIG PSEUDOSECTION:
pfsense-key.            0       ANY     TSIG    hmac-md5.sig-alg.reg.int. 1779496607 300 16 xVE/AI2f2AY1oLy4ikRqoA== 11188 NOERROR 0

; TSIG error with server: tsig verify failure

When I try to use pfSense [Issue/Renew], I receive this error.
dns_request_getresponse: expected a TSIG or SIG(0)

My web server is (include version):

IIS 10

The operating system my web server runs on is (include version):

Windows 2016 Server Core

My hosting provider, if applicable, is:

Myself. I self-host

I can log in to a root shell on my machine (yes or no, or I don't know):

I am logged in to pfSense, DNS Server, and IIS Server.

I'm using a control panel to manage my site (no, or provide the name and version of the control panel):

IIS Manager through the Domain Network

The version of my client is (e.g., output of certbot --version or certbot-auto --version if you're using Certbot):

Through pfSense 2.8.1-RELEASE
ACME 1.2 (Just updated today)

Additional Information

DNS Setup

DNS Settings for each domain
Dynamic updates: Nonsecure and secure

pfSense
  1. Services
  2. ACME
  3. Certificates
  4. Edit

Validation

SAN list
Each record is set up like this, but with its own domain, of course.

Status SAN Validation Method
Enabled carrz-fox-fire.com DNS-NSupdate / RFC 2136
Enabled *.carrz-fox-fire.com DNS-NSupdate / RFC 2136
Server 192.168.2.32
Key Name pfsense-key (With and without a period at the end)
Key Algorithm HMAC-MD5
Key long string
Zone carrz-fox-fire.com (With and without the domain in the Zone)

It used to work; the last update was on

Wed, 29 Apr 2026 19:34:25 -0400
Issued Certificate Dates:
Valid From: Wed, 29 Apr 2026 18:35:54 -0400
Valid Until: Tue, 28 Jul 2026 18:35:53 -0400

Nothing on the Windows Server has changed.
I updated today the Cert from 1.0 to 1.2 on pfSense (Mentioned above)
I researched and found another thread on here about Python versions being an issue, but there is no Python folder in the /usr/lib/

Test I have run.

drill

/root: drill TXT _acme-challenge.carrz-fox-fire.com @192.168.2.32
;; ->>HEADER<<- opcode: QUERY, rcode: NOERROR, id: 56240
;; flags: qr aa rd ; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
;; _acme-challenge.carrz-fox-fire.com.  IN      TXT

;; ANSWER SECTION:
_acme-challenge.carrz-fox-fire.com.     60      IN      TXT     "carrz-fox-fire.com"

;; AUTHORITY SECTION:

;; ADDITIONAL SECTION:

;; Query time: 0 msec
;; SERVER: 192.168.2.32
;; WHEN: Fri May 22 21:40:01 2026
;; MSG SIZE  rcvd: 83

I also removed the main folder
rm -rf /tmp/acme/carrz-fox-fire
And then created it again.
mkdir -p /tmp/acme/carrz-fox-fire
Then run [Issue/Renew] in pfSense, but the error persists.

Running grep gives me this.

grep -R "pfsense-key" /tmp/acme /usr/local/etc /var
/tmp/acme/carrz-fox-fire/carrz-fox-fire.comnsupdate_acme-challenge.carrz-fox-fire.com.key:key "pfsense-key." {

I even reverted pfSense to my last backup from three weeks ago, around the time of the last cert update, but the issue persisted.

I am at a complete loss. It worked last month. Updated the records, the script ran to copy the cert to a Share on the network, which was then picked up by CCS in IIS. It all worked great, but now, it is not working.

Any information on how to resolve this would be wonderful.
Thank you in advance.
Wayne

I suspect there might be an issue with nsupdate related to the handling of HMAC-MD5. Maybe HMAC-MD5 verification is disabled or there's a software issue.

Have you tried using an HMAC-SHA256 key?

What version of nsupdate are you using? (nsupdate -V)

nsupdate 9.20.6
As for using SHA256

Copied this from the Google AI Mode results for the question.

Can Windows DNS Server use HMAC-SHA256

(Including the links for those who might find themselves needing them)

Feature [1, 2, 3, 4, 5] Support Status Details
Standard TSIG Limited / Incompatible Does not support RFC-standard HMAC-SHA256 for zone transfers or updates.
GSS-TSIG Native Support Uses Kerberos/SPNEGO for secure updates between AD-joined Windows machines.
DNSSEC Full Support Supports SHA-256 for DS record generation and zone signing.

I suggest immediately disabling dynamic DNS updates on your DNS server, there is currently no authentication on DNS updates on your server so anyone can change your DNS.

OK
I am now running the PowerShell module Posh-ACME
Have it all set up, took a few hours to get the code right and running in Stage.
Once it was working, I switched to production and ran it manually to accept the account question.
It downloaded the cert, my PS Script file checker created copies for the other domains, and everything is working now.

I created a new task in Task Scheduler to run daily at 2 AM to check the file's date.
I disabled the Task in pfSense since it is no longer needed.

So thankful I kept digging to find a solution to this issue.
Also, I disabled dynamic DNS updates.

So, that was my conclusion to this issue.
I am going to write an article and post it on my coding site, and will post a link here for those who are running Windows Server who need to get their Certs without having to do it manually.

Take care, everyone.
Wayne

Let's Encrypt recommends running at random times. And, especially avoid the top of the hour.

See: FAQ - Let's Encrypt

As example ... leave the Task Scheduler at 2:00 but add a random sleep of up to an hour in your own script. It is unlikely you will add to the "thundering herd" problem from others who don't follow this advice :slight_smile: