Changing the challenge method

We have acquired some software suite that is using lets encrypt to provision certificates. It is using the default acme-dns server that joohoi provided in his python script. We want to move away from this approach and use the cloudflare plugin to configure the TXT record with an api token. Is it possible to cleanly update this such that on the next renewal cycle it will use the cloudflare plugin instead of the joohoi acme-dns challenge? Any pointers on this would be helpful.

Hello @nandobytes, welcome to the Let's Encrypt community. :slightly_smiling_face:

I'm thinking that the Cloudflare community forum might be a better place to start.

However, kindly wait to see if there are more knowledgeable Let's Encrypt community volunteers willing to assist.


I'm pretty sure the Cloudflare community doesn't know how to change the behaviour of Certbot (assuming OP uses Certbot). That said, we have some missing information.

@nandobytes You're not providing much details. Usually you would have been presented with a mandatory questionnaire when opening a thread in this Help section. Maybe something went wrong and you didn't see it or maybe you decided to delete the entire questionnaire (why?). Maybe not all questions are exactly relevant for your issue, but please answer all the questions below anyway and we'll go from there. For the command used please answer with the usual command you'd use to get a certificate.

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. |, so withholding your domain name here does not increase secrecy, but only makes it harder for us to provide help.

My domain is:

I ran this command:

It produced this output:

My web server is (include version):

The operating system my web server runs on is (include version):

My hosting provider, if applicable, is:

I can login to a root shell on my machine (yes or no, or I don't know):

I'm using a control panel to manage my site (no, or provide the name and version of the control panel):

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


Oh, I thought the OP wasn't using Certbot; like acme-dns-tiny form ACME Client Implementations - Let's Encrypt


Correct if I am misunderstanding please.



Is really not any helpful information. Sure, in theory it should be easy to switch to a different DNS plugin, if it's a client that has that concept and someone has implemented one for it for Cloudflare. Otherwise, it might be needed to change to another client, which usually wouldn't be that big a deal but is hard to know without a lot more information about how and where it's being used.


While we don't know for sure if OP is using Certbot, the client you're listing can only do the dns-01 challenge using the RFC 2136 protocol (i.e., sending an UPDATE DNS message). And not acme-dns, which uses a REST API.

I'm guessing OP uses Certbot in combination with e.g. acme-dns-certbot-joohoi.


Nope, OP specified the acme-dns server, described at:

It's unclear whether that's using @joohoi's own instance of the server (which really nobody should be doing; that kind of defeats the purpose of that software) or a self-hosted instance, but in any case that would be used in conjunction with other client software--which could be certbot, or, or a number of other things. Whichever client is in use has been using DNS validation by way of the acme-dns server, and OP wants to change it to use DNS validation by way of cloudflare instead. That seems like a step backward to me, but to each his own.

@nandobytes, in addition to configuring whatever client you're using to solve challenges using Cloudflare's servers rather than your own, you'll need to remove the DNS glue records (the NS records) pointing acme.yourdomain (or auth.yourdomain, or whatever) to the acme-dns server, and the various CNAME records you've created for that.


One of the domains is:

I ran this command: I don't know what commands were run to initially configure this.

It produced this output: na

My web server is (include version): ubuntu 20.04

The operating system my web server runs on is (include version): ubuntu 20.04

My hosting provider, if applicable, is: digital ocean

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

Sorry for the lack of details. It was configured with joohoi's acme dns server ( which I realize was supposed to be changed. acme-dns-certbot-joohoi/ at master · joohoi/acme-dns-certbot-joohoi · GitHub

This is how it is configured and why I want to move away from this approach. I want to remove the acme challenge CNAMEs that allow joohoi to validate txt records for us, since I can just put the txt records in cloudflare ( our dns is there ) and I was able to generate a cert using a cloudflare api token and the --dns-cloudflare plugin. This is the approach I want to use. I am just not sure if it is safe to change the renewal params in the renewal configs like

pref_challs = dns-01,
authenticator = manual
manual_auth_hook = /etc/letsencrypt/

to ex)

authenticator = dns-cloudflare
dns_cloudflare_credentials = /etc/letsencrypt/cloudflare-credentials.ini

Certbot supports the reconfigure subcommand nowadays, so it should not be necessary any longer to manually tamper with the renewal configuration files. See Modifying the Renewal Configuration of Existing Certificates for more info.

That said, if you already changed it and it seems to be working, meh, I'd just use that current configuration :stuck_out_tongue:


I haven't changed anything yet, I just created a new cert for a test domain using the cloudflare dns plugin and then I compared the configs in production (that use joohoi's acme dns server) with the cloudflare dns approach.

I just dont want to break the process of regenerating our certs :sweat_smile:. I can check out the doc you sent me. Thanks for the support


You can (and should after any change) always run the renewal command in combination with --dry-run to test the current configuration. If it succeeds, it should also succeed without the --dry-run (i.e., renew normally).


I was able to copy the prod backup into my test server and ran the following on one of the domains to test the reconfiguration:

certbot reconfigure --cert-name -a dns-cloudflare
certbot renew --dry-run --cert-name

I noticed that this line remained in the renewal conf:

pref_challs = dns-01,

I didn't see this in a clean test cert generation from scratch (with dns-cloudflare plugin), so I assumed it just didn't get cleaned up during reconfigure. I deleted that line from the conf and it the dry run still worked.

I think I am ready to update the prod server. You mentioned something about glue records but I don't see any of those in our domain. I think I just need to delete the CNAME pointing to

No need to delete it, the dns-01 challenge is what you actually want (and is implied by using the Cloudflare plugin). Leaving the option would be just fine.

I didn't see any notion of the Cloudflare credential file?

Dan mentioned NS records indeed, but acme-dns usually works with just a CNAME, so removing the CNAME is fine.


I wonder why pref_challs = dns-01, renewalparam does not exist on a newly generated certs renewal conf with this approach. I guess you said it is implied in that approach. I can leave it if it won't cause any trouble.

Oh I forgot to pass that in so the software asked me for the credential path and then pasted it in. Just confirmed that the reconfigure program does indeed let me pass in the --dns-cloudflare-credentials argument though so I will be taking advantage of that:

certbot reconfigure --cert-name -a dns-cloudflare --dns-cloudflare-credentials /etc/letsencrypt/cloudflare-credentials.ini

This tooling is great, will definitely be spreading the word about it. Thanks for all the support today!


Indeed--the NS records are only needed if you're self-hosting acme-dns (which is the way it's intended to be used). But if you're using, you wouldn't have your own (relevant) NS records to deal with.


That makes sense!


Would a CNAME also suffice when self hosting?


No, the NS records are needed in order to tell the Internet (and specifically Let's Encrypt's servers) to query your acme-dns instance for the acme.yourdomain subdomain. You'd still need CNAMEs for any hostnames you'd want to get certs for, but the client/auth script will tell you what those need to be, and they ordinarily only need to be created once.

Edit: I had some trouble wrapping my head around acme-dns before I started using it; this topic covers some of the basics:


I wouldn't be alarmed by this. You could think of it as "Certbot doesn't understand enough about how items got into your configuration file in order to necessarily delete or change all of them automatically if you change your configuration in some way". In cases where that lack of understanding represents a bug—actually making renewals fail—people may file a bug report and Certbot may be updated with a special case about a particular kind of reconfiguration.


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