Problem updating dns TXT record over Posh-ACME / RFC2136

Hello,

My domain is: demo2.stratus.si

I ran this command:
$params = @{
DDNSNameserver = ‘91.185.195.142’
DDNSKeyName = ‘mykeyname’
DDNSKeyType = ‘hmac-sha512’
DDNSExePath = ‘C:\BIND\nsupdate.exe’
DDNSPort = ‘53’
DDNSKeyValueInsecure = “my insecure key string”
}
New-PACertificate demo2.stratus.si -AcceptTOS -Contact support@mydomain.com -DnsPlugin RFC2136 -PluginArgs $params -Verbose

It produced this output:
VERBOSE: Using directory https://acme-staging-v02.api.letsencrypt.org/directory
VERBOSE: POST https://acme-staging-v02.api.letsencrypt.org/acme/acct/13512876 with -1-byte payload
VERBOSE: received 313-byte response of content type application/json
VERBOSE: Using account 13512876
VERBOSE: POST https://acme-staging-v02.api.letsencrypt.org/acme/order/13512876/89935709 with -1-byte payload
VERBOSE: received 348-byte response of content type application/json
VERBOSE: Using existing order for demo2.stratus.si with status pending
VERBOSE: POST https://acme-staging-v02.api.letsencrypt.org/acme/authz-v3/54316856 with -1-byte payload
VERBOSE: received 812-byte response of content type application/json
VERBOSE: Publishing DNS challenge for demo2.stratus.si
VERBOSE: Found authoritative zone demo2.stratus.si
VERBOSE: Adding _acme-challenge.demo2.stratus.si with value ansHvFxrOa5oNVbAgD5jNtekDIIr4R-WG6YenWMa5-w
VERBOSE: update failed: NOTAUTH
VERBOSE: Answer:
VERBOSE: ;; ->>HEADER<<- opcode: UPDATE, status: NOTAUTH, id: 27255
VERBOSE: ;; flags: qr; ZONE: 1, PREREQ: 0, UPDATE: 0, ADDITIONAL: 1
VERBOSE: ;; ZONE SECTION:
VERBOSE: ;demo2.stratus.si. IN SOA
VERBOSE:
VERBOSE: ;; TSIG PSEUDOSECTION:
VERBOSE: hccenter. 0 ANY TSIG hmac-sha512. 1588800650 300 64 mioJg29ZWGh6jptxv1usGJu775dmkKXecP1qWn0UPbI5/V7tI/yQ6D6H plJip15x/n5Hi3PZi7qmbP1cOY99Hw== 27255 NOERROR 0

VERBOSE:
Unexpected output from nsupdate command. Use -Verbose for details.
At C:\Program Files\WindowsPowerShell\Modules\Posh-ACME\3.13.0\DnsPlugins\RFC2136.ps1:377 char:9

  •     throw "Unexpected output from nsupdate command. Use -Verbose  ...
    
  •     ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    
    • CategoryInfo : OperationStopped: (Unexpected outp…se for details.:String) , RuntimeException
    • FullyQualifiedErrorId : Unexpected output from nsupdate command. Use -Verbose for details.

My web server is (include version):
IIS 10, but this is not really important since the problem occurs when I try to update dns txt record (_acme-challenge.demo2.stratus.si)

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

The version of my client is:
powershell 5.1
Posh-ACME 3.13.0
RFC2136 Plugin

If I try the same thing with certbot-dns-rfc2136 on Linux server, everything works OK. I can update txt record and install letsencrypt certificate. The problem is, I need to make this work on Windows server so I can install this certificate on IIS.

Thank you for all the help.

Regards, smrecko

1 Like

Hi @smrecko

looks like you use a wrong username / password.

Or has the file the wrong format? UTF-8 or UTF-16, when ASCII is expected?

1 Like

Hi JuergenAuer,

I tried to save powershell script in all different formats (UTF-8, ASCII, Unicode) but it didn’t help. The error stays the same.
I don’t know how a username / password (or rather key name and key secret) would be wrong because it’s working with certbot script on linux machine. The password does have one space character in it, but I tried to remove it as well and it didn’t help.

Regards, Smrecko

Perhaps it is in some other hash format.
Like maybe:
hmac-sha256

I tried with hmac-sha256 and then I get this error: NOTAUTH(BADKEY)

OK, so that part is correct.

Has this ever worked on this system?
[or is this the first time test]

No never, this is the first time I’m trying to set it up on this server (and have been banging my head for several days now). I tried on different server (linux) using certbot-dns-rfc2136 and it works great with hmac-sha512 and the same username/password.

Regards, Smrecko

Also, just FYI, this is only one way of resolving this problem:

There are many ways to install a certificate into IIS.

Requiring the “getting the certificate” with the “installing the certificate” be within the same system is purely a self-imposed constraint.
If you can break those into separate and independent steps, you can already see that the first step has been done by the Linux system.
[as one example]

hmm…
Please ensure that there are no firewall rules blocking the Windows system from outbound TCP & UDP 53.

To me, it looks like the problem is within the nsupdate step.
Be it firewall blocking or an incorrect parameter/usage syntax, I can’t be sure.
So, if there is any way to independently test the nsupdate command, please do so.

I agree. But I’m testing this solution to be implemented onto several Windows servers in different networks, not having linux server near by every time. How would I go around that problem?

The logs make it look like you’re generally doing everything right from a Posh-ACME perspective. But your DNS server doesn’t like something about the key values you’re passing via nsupdate as indicated by the original NOTAUTH response.

Unfortunately, I don’t have much experience setting up TSIG auth in BIND. So I can’t offer many suggestions there. But I can offer an easier way to troubleshoot what’s wrong with nsupdate without needing to futz with the rest of Posh-ACME. If you dot source the plugin file, you can try running the plugin’s Send-DynamicTxtUpdate function directly

Import-Module Posh-ACME
. (Join-Path (Get-Module Posh-ACME).ModuleBase "DnsPlugins\RFC2136.ps1")

$nsupdateParams = @{
    RecordName = '_acme-challenge.demo2.stratus.si'
    TxtValue = 'fakevalue'
    Action = 'add'
    Zone = 'stratus.si'
    Nameserver = '91.185.195.142'
    Port = 53
    TsigKeyName = 'mykeyname'
    TsigKeyType = 'hmac-sha512'
    TsigKeyValue = 'my insecure key string'
    NSUpdatePath = 'C:\BIND\nsupdate.exe'
}

Send-DynamicTxtUpdate @nsupdateParams -Verbose

Once you figure out what combination of values works, then go back and use them with the module and you should be good to go.

3 Likes

Port 53 is not a problem. Tried to change it to 54 (for testing purposes) and I got a connection time out. When I switched back to 53 it goes through.

I installed the version recommended in documentation for this plugin. I also tried to install older version of nsupdate, but with the same result. Also tried to run command without nsupdate (without ddnsexepath) but I immediately get an error that nsupdate is not found.

I also breaked down a command New-PACertificate and found out that the error occurs at this stage: Publish-DnsChallenge

What I didn’t try is what you recommended, to try a find an error independently in nsupdate command. I guess I’ll have to read a lot of documentation to dig this deep.

1 Like

Hi @rmbolger,

your solution actually worked. I was able to add txt record and and download the certificate. But I’m not sure how exactly do I implement this solution into the module?

Regards, Smrecko

1 Like

Were the TSIG related values you passed directly to the function any different than the params you sent to New-PACertificate? If so, change the values to match and you should be good to go.

The other thing I noticed in your original log output is that it looks like the plugin finds the authoritative zone as demo2.stratus.si rather than stratus.si that I had in my example. Is demo2.stratus.si an actual zone on the BIND server? And does it have the TSIG key associated with it?

1 Like

Values were exactly the same. Only thing that was differnet was the zone - I also noticed the same thing with this zone. But how would I change that? I can’t define a zone parameter in New-PACertificate command.

1 Like

Well, I could write a script that would do exactly what you told me (which actually works) and bypass New-PACertificate command all together :slight_smile:

Ok, now we’re getting somewhere. The plugin has to figure out which zone to update based solely on the record name _acme-challenge.demo2.stratus.si. In this plugin on Windows, it does that by running a non-recursive SOA query against the target nameserver for each portion of the FQDN getting less and less specific until it finds one that returns an authoritative answer.

In other words, it’s trying to figure out whether it needs to add _acme-challenge to a zone called demo2.stratus.si or _acme-challenge.demo2 to a zone called stratus.si. It’s a subtle but important difference and will depend on how your BIND server is configured. So it basically runs the following in order until it gets a response that contains primary name server = <blah> and ignoring any non-authoritative responses.

nslookup -norecurse -type=soa demo2.stratus.si. 91.185.195.142
nslookup -norecurse -type=soa stratus.si. 91.185.195.142
nslookup -norecurse -type=soa si. 91.185.195.142

In your case, the log output makes it seem like it got the answer it was expecting while querying for demo2.stratus.si. If you run the command manually, you can verify that’s the case.

So your DNS server is claiming it is authoritative for a zone called demo2.stratus.si. And that’s the zone the plugin will try to create the record in. But if nsupdate is only working when you try to create the record in stratus.si, that makes it seem like the TSIG config only exists in that parent zone and not in the demo2 subzone. Can you verify any of this?

3 Likes

You could, but that would be avoiding the problem. And as the author of the module and the plugin, I’d love to figure out whether the root of the problem is a bug in the plugin or just a config error on your BIND server. :grinning:

1 Like

Ok, I’ll check this tomorrow.I’ll have to contact the company who hosts our dns.

But I just remembered now… I’ve got this credentials (key name, key secret, algorithem,…) for all our domains. Yesterday I configured this exact same thing on different linux server with certbot rfc2136 plugin. And I used exact same credentials, but domain was different (not stratus.si). So it got me thinking, that TSIG config really exists only in parent zone.

I’ll get more info tommorow and let you know.

Thank you for all the help.

2 Likes

Hi @rmbolger,

I just talked with our dns provider. We have only one zone (stratus.si). There is no zone or subzone for demo2.stratus.si. TSIG config only exists on zone stratus.si.
Demo2.stratus.si is only A record in a zone stratus.si. That’s all. We then created subzone called demo2stratus.si (for the testing purposes) and the command New-PACertificate started to work :slight_smile:
So the problem is that dns plugin doesn’t find the correct zone. I belive we have 3 options now:

  1. Edit the RFC2136 plugin: give it another parameter for the zone. If this parameter is not set, then it finds the zone like it does it now. If it is set, then takes the zone parameter. I believe this would be the best options.

  2. Create a script that will bypass New-PACertificate command all together and used the solution that is already working (using Send-DynamicTxtUpdate command). This would be a quick fix for all my problems with 0 effort from either side.

  3. Create a subzone for every A record in zone which needs to be edited by Posh-ACME / RFC2136 plugin. That’s a bit messy and a lot of work. Also, every subzone would need to be configured with TSIG. It could be done, but it’s not the most practical.

Regards, Smrecko