Change challenge from http to dns

[captainproton]

I am using Certbot 1.11.0 and have been using it for about 18 months.

Some of the domains use http for the renewal challenge and I want to change it to dns.

I've read through the documentation for certbot and unless I'm missing something, I cannot see how to change from http to dns with an existing certificate.

Any help would be appeciated.

Craig

[griffin]

Welcome to the Let's Encrypt Community, Craig

This is usually accomplished via changing the authentication method as most authentication methods only support one type of challenge.

Authenticator examples using http-01 challenges:

• --manual --preferred-challenges http
• --standalone
• --webroot -w /path/to/webroot
• --apache
• --nginx

Authenticator examples using dns-01 challenges:

• --manual --preferred-challenges dns
• --dns-cloudflare --dns-cloudflare-credentials ~/.secrets/certbot/cloudflare.ini

---

You can change the authentication method (aka authenticator) for a particular existing certificate by specifying its name as given by certbot certificates (e.g. example.com) in your certbot command using --cert-name.

For example:

certbot certonly --cert-name example.com --manual --preferred-challenges dns

---

You can also do this using the renew command:

certbot renew --cert-name example.com --manual --preferred-challenges dns

[captainproton]

Hi Griffin,

Thanks for you reply.

I will try what you have suggested and see what happens.

Previously I would run "certbot renew" without any other parameters and certbot would automatically renew all existing certificates within 30 days of expiring.

The certificates I have set up previously using dns required me to include an acme-challenge in the dns zone file (I'm using bind). The domains I want to change to dns do not have an acme-challenge setup.

When I use a command like;

certbot renew --cert-name example.com --manual --preferred-challenges dns

it succeeds despite there being no appropriate entry in the name server.

I guess ultimately I'd like to know how to get the dns acme-challenge for the domains I want to convert from http. I was hoping the above command would issue me with the required TXT record.

Sorry if I'm confusing things

[schoen]

@captainproton

it succeeds despite there being no appropriate entry in the name server.

Hi @captainproton,

This is due to cached authorizations, because you already validated successfully using a different method recently enough that Let's Encrypt remembers that your account is still authorized to issue certificates for that name, even without completing any further validations.

@captainproton

certbot renew --cert-name example.com --manual --preferred-challenges dns

it succeeds despite there being no appropriate entry in the name server.

I guess ultimately I'd like to know how to get the dns acme-challenge for the domains I want to convert from http. I was hoping the above command would issue me with the required TXT record.

I think you might have a small but important misunderstanding about this. There isn't just one TXT record; there's a different one every single time. Therefore, in order to do this (once your cached authorization is no longer present) you will need a DNS plugin or script that can make these DNS zone changes from software (each time, for each renewal). If you don't have and specify that, then your command will fail with this very frequently encountered Certbot error:

https://community.letsencrypt.org/search?q=%22client%20with%20the%20currently%20selected%20authenticator%22

(certbot renew won't attempt to renew a certificate that was obtained with --manual, unless it also had --manual-auth-hook specifying a script for Certbot to run to make the DNS changes.)

[captainproton]

Hi Schoen,

Ok, a new TXT record with each renewal is new info for me and I did misunderstand that part of the process. Having said that, one of my domains using dns has remained unchanged for over 12 months; so I'm not sure how long a cached result lives for.

I just did a "certbot renew --dry-run" and it did indeed fail with the following message;

Cert not due for renewal, but simulating renewal for dry run
Could not choose appropriate plugin: The manual plugin is not working; there may be problems with your existing configuration.
The error was: PluginError('An authentication script must be provided with --manual-auth-hook when using the manual plugin non-interactively.',)
Failed to renew certificate wozsites.com.au with error: The manual plugin is not working; there may be problems with your existing configuration.
The error was: PluginError('An authentication script must be provided with --manual-auth-hook when using the manual plugin non-interactively.',)

I've got some thinking to do now. My Name Server is on a different machine and not on the IP Address where certbot is installed. I'm using bind 9 and I maintain it manually with a text editor and then signed them for DNSSEC. I have not seen a Bind plugin.

I'll do some more reading.

Update:

I'm reading this Welcome to certbot-dns-rfc2136’s documentation! — certbot-dns-rfc2136 0 documentation related to updating dns records.

[schoen]

@captainproton

Ok, a new TXT record with each renewal is new info for me and I did misunderstand that part of the process. Having said that, one of my domains using dns has remained unchanged for over 12 months; so I'm not sure how long a cached result lives for.

I think it's probably doing something different on that domain from what you think! For example, if you used --nginx --preferred-challenges dns,http or --apache --preferred-challenges dns,http, Certbot would just notice that the nginx and apache plugins don't support DNS, and fall back to doing the HTTP-01 method (which might well succeed).

@captainproton

I've got some thinking to do now. My Name Server is on a different machine and not on the IP Address where certbot is installed. I'm using bind 9 and I maintain it manually with a text editor and then signed them for DNSSEC. I have not seen a Bind plugin.

There's this

https://certbot-dns-rfc2136.readthedocs.io/en/stable/

but it may not do what you want (especially with DNSSEC).

Another possibility is to add a CNAME record for _acme-challenge inside your zone pointing to some other zone, where you could use some sort of API to update the target DNS record. You can either do this with self-hosting with

GitHub - joohoi/acme-dns: Limited DNS server with RESTful HTTP API to handle...

or with someone else's DNS service that offers an API.

[schoen]

@captainproton

I'm reading this Welcome to certbot-dns-rfc2136’s documentation! — certbot-dns-rfc2136 0 documentation related to updating dns records.

Yes, that is very possible but I don't know if it will interact well with DNSSEC signatures!

[captainproton]

Thanks for your help, you have enlightened me.

I will work out a method to automate the process across all severs here. My initial problem isn't urgent as I've recently renewed them all - so I have three months to sort it out.

I don't use outside services and prefer doing everything myself. I converted my knowledge from Windows to Linux just over 12 months ago (I've avoided Unix / Linux for 30 years). I have 8 Linux servers with no GUI interfaces and it's a barrel of laughs figuring it all out.

I was reading the rfc2136 link while you were replying

So now I learn something new.

Again, thank you & Griffin for your replies. You have both helped me.

[griffin]

You are quite welcome.

[griffin]

Remember that you can test your renewals with:

certbot renew --dry-run

Those tests aren't cached!

[captainproton]

Thanks Griffin,

I used the dry run option to test my challenge changes and they did fail as @schoen hoen had previously suggested.

I'm switching back to http while I figure things out. It would seem the dns plugin (Welcome to certbot-dns-rfc2136’s documentation! — certbot-dns-rfc2136 0 documentation) will ultimately be the solution.