Need to figure out the correct key config to get my certs renewed. I had backups of the /etc/letsencrypt path but not the credential files Using certbot-dns-rfc2136 plugin as web server is on a different server

Help
1

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.

My domain is: dlld.us

I ran this command: certbot renew

It produced this output: Processing /etc/letsencrypt/renewal/dlld.us.conf

Renewing an existing certificate for *.dlld.us and dlld.us
Encountered exception during recovery: certbot.errors.PluginError: Encountered error deleting TXT record: The peer didn't know the key we used
Failed to renew certificate dlld.us with error: Encountered error adding TXT record: The peer didn't know the key we used

My web server is (include version): apache

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

My hosting provider, if applicable, is: My machine, my dns 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):
N/A
The version of my client is (e.g. output of certbot --version or certbot-auto --version if you're using Certbot): certbot 5.0.0

2

How do I tell Letsencrypt which key I am using or named. I had this working for years before I had to rebuild. Any help or guidance would be appreciated.

3

You don't tell Let's Encrypt the key to your DNS Server. You need to setup your dns-rfc2136 config with the correct credentials (again). The credentials you lost are the ones used by Certbot's plugin to access your DNS.

Was this the way you did that? GitHub - joohoi/acme-dns: Limited DNS server with RESTful HTTP API to handle ACME DNS challenges easily and securely.

Also see Certbot docs: Welcome to certbot-dns-rfc2136’s documentation! — certbot-dns-rfc2136 0 documentation

1 Like
4

No, not doing web api, My web servers and dns servers are intact. Strictly using dns. I have followed the instructions from Welcome to certbot-dns-rfc2136’s documentation! — certbot-dns-rfc2136 0 documentation still getting the error that the peeer doesn't know the key we used

5

The "peer" in this case is the DNS Server that the Certbot plugin is using to update your DNS system

2 Likes
6

When you use rfc2136 to update your DNS server it's the certbot plugin talking directly to your own DNS system (which is either internal or hosted by a DNS provider), it uses the TSIG secret key issued by the DNS service to authenticate itself.

If you have lost your secret key you need to issue yourself another one, presumably the existing one isn't used elsewhere or you'd just get it from there.

All of this is internal to your own organization and Let's Encrypt and certbot etc have no control over any of it.

3 Likes
7

here are what I have for the credential file and named.conf , the key file exists, I created it new.
I don't see what's missing when I follow the documentation for rfc2136, Do I have something crossed or wrong here?

Credential file
dns_rfc2136_server = 127.0.0.1
dns_rfc2136_port = 53
dns_rfc2136_name = Kdlld.us.tsig.+165+xxxxx.key.
dns_rfc2136_secret = ruSjdfUxxxxxxxxAZv4qKKxxxxxxxxxxxxxx/xxxxxxxxxxxxxxxxxxx PKgMxxxxxxxxEuer9koxBFcasYNXtw==
dns_rfc2136_algorithm = HMAC-SHA256

named.conf
key "keys/Kdlld.us.tsig.+165+XXXXX.key." {
algorithm hmac-sha512;
secret "ruSjdfUxxxxxxxxAZv4qKKxxxxxxxxxxxxxx/xxxxxxxxxxxxxxxxxxx PKgMxxxxxxxxEuer9koxBFcasYNXtw==";
}

zone "dlld.us" {
type master;
file "dlld.us";
allow-transfer { xxx.xxx.xxx.xxx; };
also-notify { xxx.xxx.xxx.xxx; };
update-policy {
grant Kdlld.us.tsig.+165+63072.key. name _acme-challenge.dlld.us. txt;
};
dnssec-policy "dlld-us-no-rotate";
inline-signing yes;
key-directory "/var/named/data/keys/dlld.us/";

};

8

Why does it vary from HMAC-SHA256 to hmac-sha512? I'm not an expert on rfc2136 but I assume these should be the same, and probably hmac-sha512.

9

Thanks, that was my feeble brain mis typing the credential file. They key is hsa512, corrected the credential file but it still fails same error. If i paste the actual key and private here could you verify I am actually putting the correct info in the files? I will regenerate after it gets fixed
created new tsig key, reconfigured named.conf and credential file still getting the error that the peer doesn't know the key we used.
Testing the key for transfers I get dig @1##.232.##.1## dlld.us axfr -k tsig.dlld.us.key
Couldn't read key from tsig.dlld.us.key: unexpected token

; <<>> DiG 9.18.30-0ubuntu0.24.04.2-Ubuntu <<>> @1##.232.##.1## dlld.us axfr -k tsig.dlld.us.key
; (1 server found)
;; global options: +cmd
; Transfer failed.

key "tsig.dlld.us.key" {
algorithm hmac-sha512;
secret "eyRFGNMkXAfabcdefghijklmnopqrstuvwxyzCBW+OvMeYdzyxwvutsrqponmlkjihgfedcba4QsVzO6w==";
};

10

No I'm not an nsupdate/rfc2136 user so I can't help beyond that. Perhaps someone else can advise.

Are you sure the key name (which as far as I know is not a file name but a "name" for the key) is the same as that used in when generating the key in the keygen command?

11

Hi dlpreston,

I use RFC2136 for my DNS updates as well, I don't use certbot at the moment but have done in the past without any problems and I've still got my certbot configuration to hand. There are a couple of things we can try just with BIND and its support utilities as well.

First off, how are you generating your TSIG key(s)? The test one (eyRF...w==) isn't quite long enough to be an HMAC-SHA512 TSIG key and gives errors when using a base64 decoder -- that's why I think you're getting the unexpected token error from dig.

The key that you obfuscated looks to be of the right length although I'm not sure if certbot will like the space in the middle. (I use HMAC-SHA256 keys which are short enough not to require line breaks or the like.) As a first step, make sure that the secret in both your credential file and named.conf doesn't have any spaces in it and give it another go. If that doesn't help, let's try something else:

Running tsig-keygen will give you a new HMAC-SHA256 key (we can always try again with SHA512 if needed) that will look like this:

key "tsig-key" {
  algorithm hmac-sha256;
  secret "V7Ryr/D4mFQNoAOBfkLEufsmkHWbDnuDohtjI5IQfoI=";
};

(That's not a key I've used!)

Add that into your named.conf and also save it as a separate file tsig.key. Modify your update policy for the dlld.us zone to this:

update-policy {
  grant tsig-key name _acme-challenge.dlld.us txt;
};

Reload BIND, then run nsupdate -k tsig.key and type in the following at the prompts:

zone dlld.us
server 127.0.0.1
add _acme-challenge.dlld.us 600 txt hello
<blank line>

nsupdate will send that update, signed with the key in tsig.key, to 127.0.0.1. If you just get another > prompt after the blank line, it worked. If you get any other output, including before you get the first > prompt, let us know.

If it did work, pop that secret (without the surrounding double quotes) into your credentials, change dns_rfc2136_name to tsig-key and give that a go.

Martin

2 Likes
12

(post deleted by author)

13

tested the nsupdate, got no errors, nice clean > prompt, did a zone transfer works with key and it fails without key. Still get this error when trying certbot:
Encountered exception during recovery: certbot.errors.PluginError: Encountered error deleting TXT record: The peer didn't know the key we used
Failed to renew certificate with error: Encountered error adding TXT record: The peer didn't know the key we used

14

As I was getting ready to post the credential file I saw I missed changing the HMAC-SHA512 to HMAC-SHA256. Changed it and I got the cert. Thak all of you that helped. I really appreciate it. Now on to the other 3 domains.

3 Likes
15

Ok I have all 4 of my certs renewed. I want to thank you all one more time for the help.

3 Likes
16

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.