Problem certbot and dns-rfc2136 plugin

Help
1

Hi everyone,
I have a problem with creating certificates, I'll explain the scenario.
I have a server (freebsd) on which certbot and its dns-rfc2136 plugin is installed which tries to create/update certificates by authenticating on a remote Bind server (same network and always freebsd).
On named.conf I configured the desired zone with "update-policy" and "allow-update" on the key generated and configured on the .ini file that I feed to certbot.
The error message is this:
"
Certbot failed to authenticate some domains (authenticator: dns-rfc2136). The Certificate Authority reported these problems:
Domain: webmail.example.com
Type: unauthorized
Detail: Incorrect TXT record "WrBP2Uyn4aJFUxD2DDa1nInnL2wVwBhxTm7RcsKR" found at _acme-challenge.webmail.example.com

Hint: The Certificate Authority failed to verify the DNS TXT records created by --dns-rfc2136. Ensure the above domains are hosted by this DNS provider, or try increasing --dns-rfc2136-propagation-seconds (currently 60 seconds).

Cleaning up challenges
Some challenges have failed.
"

Thanks in advance
P.S. BIND 9.16.10 and Certbot 2.6.0 (but the same error also in 1.8.0 version)

1 Like
2

Hi @ciccio, and welcome to the LE community forum :slight_smile:

Is that DNS server authoritative for the domain?:

Can that DNS server be reached from the Internet?

2 Likes
3

yes certainly, obviously it can be reached from the internet.
to date it has been renewed without problems by manually updating the TXT record at _acme-challenge.webmail.example.com

thank you very much for the quick reply :slight_smile:

1 Like
4

It may be obvious to you.
But I take nothing for granted.
Like the domain name for instance...

Has this dns-rfc2136 worked with this DNS server before?
OR is this your first try?

3 Likes
5

Please don't use real domain names that don't belong to you.
When writing a domain name as an example, use "example.com/.net/.org".

4 Likes
6

... and if you want to use a second level domain, we also have .example :smiley:

4 Likes
7

My advice would be to use the --debug-challenges option of Certbot and while Certbot is waiting for your input to continue, use dig @insert-nameserver-here _acme-challenge.example.com to debug your nameservers.

3 Likes
8

HI,
this is the first attempt to use the plugin I have always updated the certificates manually.
Obviously the domain I wrote is just an example, I omitted the real domain.

9

Hi, using dig the certificate is resolved correctly, both using my bind server and using an external DNS.
Here you will find an extract of the log file:

Using --debug-challenges instead this is the result:

I remember that the domain example.com is not the original one, mine is another one.
Thanks again :slight_smile:

10

What was the dig output from external during the debug challenges pause?

2 Likes
11

There is your confusion.
example.com is the "example" domain.
domain[.]com is NOT to be used as an example domain - it is a real domain.
[which is why I changes "domain" to "example" in all your posts]

3 Likes
12

Hello everyone,
sorry for the late response.
I investigated by debugging the bind log and saw that certbot was trying to update the wrong view record.
My named.conf has two views, in order, the first for lan and the second public.
Certbot should update the record for the public view, but since on the named.conf it finds the LAN one first, it tries to update that one.
How can I solve this problem?
Can I specify with the certbot command which view to work with?

thank you all

1 Like
13

If I read the following issues/PRs correctly:

This should (maybe?) be fixed when signing the SOA RR with the TSIG.. Or something.. :stuck_out_tongue: I don't understand it fully, but I've read "split-horizon" and "multiple views" on a few occasions. You can use dns_rfc2136_sign_query = true in your credentials INI file to make that happen.

1 Like
14

Hello Osiris and hello everyone,
It seems I've solved the problem.
I don't know if it's the correct way but in the end it worked, so I'm sharing it, it might help someone.
Or maybe to tell me not to apply this configuration at all :laughing:

  • As per the documentation, I created the TSIG key and pasted it into the named.conf
  • I added update-policy { grant rndc-key name....... }; to the affected area
  • In the view directives, I inserted for that LAN match-clients { !key rndc-key; };
    and match-clients { key rndc-key; }; for the public one.

Again, I don't know if this is the right solution but it works :slight_smile:

1 Like