DNS Challenge two step

We have a custom DNS process to update records.

In order to be able to renew certificates using the DNS challenge I need to be able to

  1. request new TXT record data
  2. update our system
  3. renew the cert.

Using Certbot, (or something else if that won’t cut it) how can I just request new DNS TXT records?
Then I can run our process to update DNS records, and then renew the cert?

Something like:
certbot-auto get-new-DNS-TXT-Challenge
We do our thang
certbot-auto renew

I prefer this to be a two step process rather than relying on pre and post hooks.

You either have to conform to the workflow of your ACME client/Certbot (in other words, use validation hooks), or write your own ACME client using an ACME library.

Writing your own means having to handle things like account registration, renewal etc yourself.

I’m not sure I understand why validation hooks are not suitable to you. They allow you to receive the requested TXT record, perform some out-of-band activity to install them, and then return to Certbot.

How long does this process take?

It can take a couple of minutes, so not too long. I will try my own custom hook and see how it works out.

One thing I’m confused about…I’m registering domain.com and *.domain.com. When I did the initial cert request manually, it had me do one TXT record, wait, then another…Each time it said there might be more coming. Why did it need more than 1 TXT record?

Each name/identifier in the certificate has a distinct challenge and subsequent TXT record. Wildcard records use the same base name as their non-wildcard counterpart.

A recent explanation of the issue: https://github.com/letsencrypt/boulder/issues/4094#issuecomment-469901412

Thanks for the link.

I was able to write a validation hook and cleanup script to get the job done.

The other thing I’m curious about, why the extra “security” for wildcard certs? Certainly one who owns the http://domain.com also owns the DNS…

I think @jsha explained something close to this in the link that @_az posted. One way of thinking about it is that although usually someone who can get one cert can get the other, the wildcard certificate is much more powerful and we want to be careful that people don't get or use them when they don't intend to.

Also, in terms of the requirement for the DNS challenge, sometimes the webmaster for a site is not the DNS or network admin. For example, at a university, there might be a webmaster who runs the university's main site at example.edu yet doesn't also run other services like registrar.example.edu or mail.example.edu (and isn't responsible for the university's DNS zone). Thus this webmaster should not actually be allowed to get a wildcard certificate for other names within that zone.

1 Like

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