Subdomains or SAN additions and DNS validation

Help
#1

Hello all,

I've found many posts around my issue but not quite what I think is my issue.

Goal, auto-renew either 4 host specific certificates (one certificate with 4 hosts in the SAN list could work but there is a risk renewing all 4 at the same time. Even 2 and 2 would be better).

Environment:

On premise Bind9, apache, and sendmail (TLS) I'd like issue certs for.

This immediate needs is for my sendmail server's TLS certificates. These server do not run Bind or a www server. I'd rather not open more incoming ports to this server but I'm open to discussion. My understanding is the certs will be requested elsewhere on my Bind server (current attempt) or my www server then distributed internally with rsync, scripts etc.

c-mail-1.atlatravel.com
c-mail-2.atlatravel.com
a-mail-1.atlatravel.com
a-mail-2.atlatravel.com

Progress so far:

Currently working (using cerbot on my bind server):
/usr/bin/certbot certonly --dns-rfc2136 --dns-rfc2136-credentials /etc/letsencrypt/dns_rfc2136_credentials.txt -d atlastravel.com -d *.atlastravel.com --dry-run

Currently not working:
root@dmz-peleg:/etc/bind# /usr/bin/certbot certonly --dns-rfc2136 --dns-rfc2136-credentials /etc/letsencrypt/dns_rfc2136_credentials.txt -d atlastravel.com -d www.atlastravel.com --dry-run
Saving debug log to /var/log/letsencrypt/letsencrypt.log
Plugins selected: Authenticator dns-rfc2136, Installer None
Obtaining a new certificate
Performing the following challenges:
dns-01 challenge for atlastravel.com
dns-01 challenge for www.atlastravel.com
Cleaning up challenges
Encountered exception during recovery:
Traceback (most recent call last):
File "/usr/lib/python3/dist-packages/certbot/auth_handler.py", line 75, in handle_authorizations
resp = self._solve_challenges(aauthzrs)

After much reading, I suspect dns validation requires a zone delegation for each host name in this case www. IMO, this is impractical. And I should probably switch to using a web server and web validation.

Before I give up on dns validation, I'm looking for help or confirmation. Our apache servers have some turn over to them but dns has been stable for a long time. So I see an advantage to settings this up with dns validation.

I'm looking to have explicit host names in the common name or SAN list due to compliance scanning reasons. I believe SAN entries will also pass the scan but not confirmed. Our current wildcard cert is getting dinged for being a wildcard.

Finally, if I can't get the auto-renew working in an automated fashion, I think paying for a longer expiry commercial certificate would be our direction.

Thanks your guidance and sorry in advance if this is an FAQ or frequent topic that I'm just missing.

Scott

1 Like
#2

First of all, thank you for a well-written post explaining what you've tried and what isn't working. (And using the staging environment for testing!)

This isn't particularly a helpful error message to me. Is there any more detail in certbot's log, or on your Bind server about the requests to add and delete the TXT records?

I wouldn't expect that, though I haven't played with RFC2136. Are you sure that the credentials you're using have permissions to update both the _acme-challenge.atlastravel.com as well as _acme-challenge.www.atlastravel.com TXT entries? If you can get the wildcard working, it really ought to be possible to get the specific hostnames working too.

I'm really not sure what kind of "compliance scan" would object to using a wildcard? Is it just that you'd be having the same private key on multiple servers? You could, in theory, use a different wildcard certificate & key on each server as long as you're mindful of the rate limits, but in general as you say if you don't really need the wildcard then it's usually easier to just do the exact hostnames.

2 Likes
#3

Thanks for the quick response.

I believe this is my problem

as well as _acme-challenge.www.atlastravel.com TXT entries

To setup _acme-challenge.atlastravel.com TXT entries for delegation was quite a process. I know just enough about bind and dns to be dangerous.

Per the what I've researched, I'd need to setup www.atlastravel.com as a subdomain in bind and then again delegate the zone _acme-challenge.www.atlastravel.com. I'm hoping there is someone with more Bind experience that can confirm "this is the way" or enlighten me there is a short cut. I'm hoping I can delegate straight from the atlastravel.com zone. However, I found posts that state a subdomain setup is required even if we just looking a host name (they are the same thing as far as Let's Encrypt is concerned)

some links I used for guidance.
https://john.daltons.info/home_server_documentation/lets_encrypt.html

I will examine the logs again for more evidence.

#4

So is the problem that Bind doesn't let you have a credential for updating just the _acme-challenge records and requires a credential for updating anything in a zone? If so, and if your security policy (reasonably) doesn't want credentials that can update anything on all your servers, then I think the usual approach would be to create just one separate zone that the credentials can modify, and have all the _acme-challenge records that you need be a CNAME into a corresponding record within that zone. I don't think certbot handles that kind of scenario, but some other clients do. (I happen to know acme.sh does, for instance, but I don't think it's the only one.)

However, I could have sworn I've seen people here that used bind and had set up credentials that only gave access to the needed TXT records, without needing to set up other zones and delegations and such. Maybe I'm mixing it up with something else, though. Hopefully, someone else here has some experience with Bind/RFC2136 setups for you.

You might also want to take a look at software like acme-dns or agnos, which you could delegate your DNS records to and are designed for integrating DNS updates, if you can't figure out how to do it through Bind.

4 Likes
#5

There shouldn't be any sub-zone creation or delegation needed. Dotted labels (records) such as _acme-challenge.www in the root of the atlastravel.com zone should definitely be able to exist and be created as part of an RFC2136 based update.

I feel like we're missing something here. I'm not super familiar with certbot, but I don't think the python error you got is normal just for a challenge that wasn't validated successfully. Is there a more verbose logging option we could try?

4 Likes
#6

Certbot can be run with many times -v (e.g. -vvv) for more verbosity. Or just look in the letsencrypt.log file as suggested by @petercooperjr

I agree it shouldn't be any hassle to have multiple labels under a single domain with BIND..

@Scott311: What's wrong with having a single wildcard certificate? If I look at your c-mail-1 subdomains, that would fit the wildcard cert perfectly. Or do you also have hostnames with double subdomains? E.g. www.c-mail-1?

4 Likes
#7

Per the wildcard cert, our third party external vulnerability scans are offended by using a cert that does not include the name of the server. I don't agree with it but I have to deal with the finding.

I'll try the logs and -v switches. I may not be back until later today or tomorrow. I wasn't expecting such great tips so quickly. Thanks a lot.

@rmbolger,

I will try this line in my root zone
acme-challenge.www IN NS atlastravel.com.

Maybe this is all I need.

Scott

#8

No, that would be creating the delegation which you don't want. It would also probably break things because NS records are intended to point to explicit nameservers rather than a domain. The only NS records in your root zone should be these:

atlastravel.com.        600     IN      NS      peleg.atlastravel.com.
atlastravel.com.        600     IN      NS      bildad.atlastravel.com.
atlastravel.com.        600     IN      NS      land.atlastravel.com.
atlastravel.com.        600     IN      NS      sea.atlastravel.com.
3 Likes
#9

I think one of the things tripping you up is that those links you found are about having the challenge entries in a different zone, which is certainly an option and may have some advantages but may also be overkill for your needs. You should be able to keep everything in just your main zone, and then once that's working (if desired) start from there to split out to different zones.

2 Likes
#10

update with -v switch

No authoritative SOA record found for _acme-challenge.www.atlastravel.com
No authoritative SOA record found for www.atlastravel.com
Received authoritative SOA response for atlastravel.com

#11

That is as expected when the only zone is the root of atlastravel.com. This is likely the RFC2136 plugin attempting to figure out which zone it will send the update to.

2 Likes
#12

Could you please share the relevant portion of your named.conf? And perhaps the zone file.

I'm currently testing my own dns-rfc2136 plugin with a certain test zone and I don't have any trouble with adding a www subdomain.

2 Likes
#13

I agree. Pretty much confirming what I thought in the first place. So I'm still at a loss on how to do this without all the zone setup. Wrong instrutions? Not possible? Wrong plugin? Switch to https? Other?

I do have this in my zone file. I'm happy to follow other instructions as this does seem overkill to the point, I'm not going to do it.

; Delegate lets encrypt zones
acme-challenge IN NS atlastravel.com.

Again you've been a great help already.

Thanks

Scott

1 Like
#14

For reference, the zone file and named.conf entry of a working zone are:

Zone file:

$ORIGIN .
$TTL 900        ; 15 minutes
subdomain.example.org          IN SOA  ns.example.com. root.example.com. (
                                2018011425 ; serial
                                7200       ; refresh (2 hours)
                                3600       ; retry (1 hour)
                                604800     ; expire (1 week)
                                21600      ; minimum (6 hours)
                                )
                        NS      ns.example.com.
                        A       x.x.x.x
                        AAAA    2001:x:x:1::1

Relevant named.conf entry:

zone "subdomain.example.org" IN {
        type master;
        file "pri/subdomain.example.org.zone";
        update-policy {
                grant certbot. zonesub TXT;
        };
        allow-query {
                any;
        };
};

And the credentials file, for reference:

dns_rfc2136_name = certbot
dns_rfc2136_algorithm = HMAC-SHA512
dns_rfc2136_server = 127.0.0.1
dns_rfc2136_secret = xxx

Works like a charm, for the zone base domain name as wel as www subdomain.

Not sure if that's correctly copy/pasted, but it seems to be missing an underscore. Is this redirect because you're running the BIND instance Certbot is using runs on 192.254.233.86 instead of the authorative nameservers of your domain?

In any case, none of my dig attempts I found any NS delegation.. :roll_eyes:

3 Likes
#15

wow. you're right. on it.

1 Like
#16

Note that if such a redirect is actually necessary for even the base domain, you probably require to redirect the _acme-challenge.www labels too.. However, if you could get a wildcard certificate earlier with a non-working delegation, it probably isn't necessary :rofl:

3 Likes
#17

Osiris, Your clip got me past the error. I just made a zone for the subdomain (aka host) and a separate file to update in with the SOA record. I can live this. I also removed the line acme-challenge IN NS completely.

zone "_acme-challenge.c-mail-1.atlastravel.com" {
type master;
file "/var/lib/bind/acme-challenge.host.atlastravel.com";
check-names warn;
update-policy {
grant certbot. name _acme-challenge.c-mail-1.atlastravel.com. txt;
};
};

It's working now. Well at least the dry run is. Thanks everyone!!!

1 Like
#19

Although it is nice to see that your DNS mastery skills are improving because of this exercise...

That might have saved you some time and effort and might actually be more secure [in the long run].

In the end your "new DNS skills", without continued use (and since they are now automated, won't be) will likely be forgotten in a few months time.
Which will then leave those DNS entry modifications (that no one else might understand nor maintain properly in your absence) to the mercy of the DNS skills the next DNS admin holds.
[Just my paranoid 2 cents]

So prepare to forget everything you just learned...
By documenting it as best you can.

1 Like
#20

@rg305 Redirecting _acme-challenge labels to an acme-dns or agnos instance or redirecting _acme-challenge labels to a DNS server under your control and where you can use the dns-rfc2136 plugin doesn't make a difference I think.

RFC 2136 is not that hard, perhaps a few comments in the zone file/named.conf might be a good idea, but I wouldn't be afraid for the next DNS admin.. If this is above his/hers/their heads, they probably shouldn't be the next DNS admin to begin with.

1 Like
#21

I didn't want to go that far, but, yes, a DNS admin should have been able to do this straightaway.
Clearly a one-size-fits-all admin could make mistakes and DNS is the last place one should be making mistakes [IMHO].

1 Like