Trouble with certbot dns-rfc2136 and split BIND views

[dk_means]

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. https://crt.sh/?q=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: digitalelephant.org

I ran this command:/bin/certbot -n certonly --dns-rfc2136 --dns-rfc2136-credentials=/etc/letsencrypt/rfc2136.ini --dns-rfc2136-propagation-seconds 30 --logs-dir /var/log/letsencrypt --work-dir /etc/letsencrypt/live --config-dir /etc/letsencrypt -m means@digitalelephant.org --rsa-key-size 3072 --agree-tos -d reggie.digitalelephant.org

It produced this output:
Saving debug log to /var/log/letsencrypt/letsencrypt.log
Plugins selected: Authenticator dns-rfc2136, Installer None
Starting new HTTPS connection (1): acme-v02.api.letsencrypt.org
Obtaining a new certificate
Performing the following challenges:
dns-01 challenge for reggie.digitalelephant.org
Cleaning up challenges
Encountered exception during recovery:
Traceback (most recent call last):
File “/usr/lib/python2.7/site-packages/certbot/_internal/error_handler.py”, line 124, in _call_registered
self.funcs-1
File “/usr/lib/python2.7/site-packages/certbot/_internal/auth_handler.py”, line 243, in _cleanup_challenges
self.auth.cleanup(achalls)
File “/usr/lib/python2.7/site-packages/certbot/plugins/dns_common.py”, line 77, in cleanup
self._cleanup(domain, validation_domain_name, validation)
File “/usr/lib/python2.7/site-packages/certbot_dns_rfc2136/_internal/dns_rfc2136.py”, line 79, in _cleanup
self._get_rfc2136_client().del_txt_record(validation_name, validation)
File “/usr/lib/python2.7/site-packages/certbot_dns_rfc2136/_internal/dns_rfc2136.py”, line 163, in del_txt_record
.format(e))
PluginError: Encountered error deleting TXT record: The peer didn’t know the key we used
Encountered error adding TXT record: The peer didn’t know the key we used

My web server is (include version): Apache/2.4.6 (CentOS)

The operating system my web server runs on is (include version): CentOS 7 – kernel version 3.10.0-1062.4.3

My hosting provider, if applicable, is: n/a

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): no

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

In addition, I have configured named on this system so that nsupdate succeeds. Named is configured with two views, one responding to the server’s external address, and the other to its internal address. The nsupdate transaction looks like this:
nsupdate -k Kcert-ddns.+165+01476.key -v nsUpdate.txt
nsupdate -k Kcert-ddns.+165+01476.key -v nsUpdate.txt
Outgoing update query:
;; ->>HEADER<<- opcode: UPDATE, status: NOERROR, id: 0
;; flags:; ZONE: 0, PREREQ: 0, UPDATE: 0, ADDITIONAL: 0
;; ZONE SECTION:
;digitalelephant.org. IN SOA

;; UPDATE SECTION:
_acme-challenge.digitalelephant.org. 180 IN TXT “my-first-dns-dynamic-update”

Sending update to ::1#53
Outgoing update query:
;; ->>HEADER<<- opcode: UPDATE, status: NOERROR, id: 42194
;; flags:; ZONE: 1, PREREQ: 0, UPDATE: 1, ADDITIONAL: 1
;; ZONE SECTION:
;digitalelephant.org. IN SOA

;; UPDATE SECTION:
_acme-challenge.digitalelephant.org. 180 IN TXT “my-first-dns-dynamic-update”

;; TSIG PSEUDOSECTION:
cert-ddns. 0 ANY TSIG hmac-sha512. 1577389715 300 64 uq773okPVt6+XWEO5d1D/E7bd2Ozmc9Uo+OfJ1LGNKMZE0XovfbiOWUq gDIYrLYKStxoyjxSjpzZ0HucsyETlA== 42194 NOERROR 0

Reply from update query:
;; ->>HEADER<<- opcode: UPDATE, status: NOERROR, id: 42194
;; flags: qr; ZONE: 1, PREREQ: 0, UPDATE: 0, ADDITIONAL: 1
;; ZONE SECTION:
;digitalelephant.org. IN SOA

;; TSIG PSEUDOSECTION:
cert-ddns. 0 ANY TSIG hmac-sha512. 1577389715 300 64 uAPVmRkkujBagOSIVJG94ZpawwvZrRGg2Ku8UoTjnmus2Eol83BHUYIw i2Qx5zcUisEWusk7B33cHSCqRgm7iQ== 42194 NOERROR 0

The relevant parts of /etc/named.conf are:
key “cert-ddns” {
algorithm hmac-sha512;
secret “{obscured}”;
};

zone “digitalelephant.org” {
type master;
file “pub/digele.zone”;
allow-transfer {none;};
update-policy {
grant cert-ddns name _acme-challenge.digitalelephant.org. txt;
};
};

I am guessing, but do not have any proof, that the certbot interaction is trying to use the internal view rather than the public view, even though I have this rfc2136.ini file:

Target DNS server | Your BIND server

dns_rfc2136_server = 216.160.123.8

Target DNS port

dns_rfc2136_port = 53

TSIG key name

dns_rfc2136_name = cert_ddns

TSIG key secret

dns_rfc2136_secret ={obscured}

TSIG key algorithm

dns_rfc2136_algorithm = HMAC-SHA512

If anyone has any recommendation about what else I should try, I would be grateful.

[Buffalo]

Maybe this will help: If not, you will need someone with more expertise than
I have.

Seems like each view in my similar setup wanted both a “key” and a “!key”

In the internal “view” I put

match-clients {
key “internal-key.”;
!key “external-key”;
localnets;
… other CDIR stuff
};
};

and in the external view I put …
match-clients {
key “external-key.”;
!key “internal-key”;

       ...
            };

};

$0.02
73 de Bill W5GFE

[dk_means]

As others have observed in places I didn’t originally find, the key that is used by named to validate a dynamic update is very tightly defined:
the name suplied to
dnssec-keygen -a HMAC-SHA512 -b 512 -n HOST {key_name}
must match the name given to that key in the named.conf file (or separate key definition file). Otherwise, we get the error “tsig verify failure (BADKEY)”.

Then I discovered two other problems that kept my setup from working: first, because of the split view, I needed to set up the “match-clients” clause in named.conf to exclude access to the behind-the-firewall view (match-clients {!key certbot; …}
so that the request to insert a TXT record would go to the public view. And second, my update-policy clause was too restrictive: if I had
“grant certbot. name _acme-challenge.digitalelephant.org. TXT”, any challenge for a host within that domain would fail. I went with
“grant certbot. subdomain digitalelephant.org. TXT”,
so that a TXT record looking like
_acme-challenge.fubar.digitalelephant.org. TXT would succeed.