Thanks for the additional info and even better that you worked out a resolution.

TBH it's been a long time since I worked on that code but I've just had a quick look over it to refresh my memory. FYI the way it's meant to work is that if you select cloudflare as the provider, it should copy the example lexicon cloudflare config to /etc/dehydrated/lexicon_cloudflare.yml. Here's the example config:

# uncomment relevant lines and replace example value(s)

# Cloudflare example 1 - using global api key
#auth_username: YOUR_CF_USERNAME
#auth_token: YOUR_CF_API_TOKEN

# Cloudflare example 2 - using unscoped API token
#auth_token: YOUR_CF_UNSCOPED_API_TOKEN

# Cloudflare example 3 - using scoped API token
#auth_token: YOUR_CF_SCOPED_API_TOKEN
#zone_id: YOUR_CF_ZONE_ID

Given what you've noted, updating "example 2" should have done the trick. I.e. removing the leading '#' and replacing 'YOUR_CF_UNSCOPED_API_TOKEN'. E.g. using your example the relevant section of the updated file should look like this:

# Cloudflare example 2 - using unscoped API token
auth_token: 1234567890123456789012345678901234567890

During that process, Confconsole should also explicitly set the provider as "cloudflare" and when 'turnkey-lexicon' runs (the lexicon wrapper that we provide) it should automatically use that that /etc/dehydrated/lexicon_cloudflare.yml file and include "cloudflare" as the provider when it calls lexicon. Currently only cloudflare and aws-route53 have example config - otherwise it will just provide an "auto" example config file - and try to use the "auto" process.

Obviously that either didn't work as expected and we have a bug - or there was some misunderstanding along the way. Either way we need to improve that as your experience is not how it should be.

Rereading your posts, it sounds like you ended up with an "auto" config yaml file in /etc/dehydrated, rather than the cloudflare specific one? So if I understand correctly, you ended up writing your own lexicon.yml file and then it worked ok?

FWIW when we added DNS-01 support, I only explicitly tested AWS Route53 myself. But another user tested the Cloudflare pathway and he said that it worked ok. So I'm not really sure what has happened there?!

Armed with a little more info of exactly what you saw/experienced I can dig in a bit deeper and improve things so it works as expected.

Thanks again for taking the time to report this.

It looks like Cloudflare are blocking your login. A 400 error when connecting to Cloudflare suggests that there is something wrong with your authentication config.

The first 2 things to double check:

• You haven't done a typo in your config - e.g. missing letter from your API key.
• You are configuring the right section of the Lexicon config and are nly providing the relevant values. E.g. if you are using an unscoped Cloudflare API key do not also provide a username or zone ID. If you are using a global api key, ensure that you are including your username, but not a zone ID, etc.

The updated config discussed in this thread won't be included in the version of Confconsole you have installed - but the important bits remain the same.

As an example of the config contents using an unscoped API key with a value of 'ABCDEFGHIJKLMNOP'. The updated lexicon Cloudflare config provided by Confconsole should look like this:

# For more info, please see:
# https://www.turnkeylinux.org/docs/confconsole/letsencrypt#dns-01

# uncomment relevant lines and replace example value(s)

# Cloudflare example 1 - using global api key
#auth_username: YOUR_CF_USERNAME
#auth_token: YOUR_CF_API_TOKEN

# Cloudflare example 2 - using unscoped API token
auth_token: ABCDEFGHIJKLMNOP

# Cloudflare example 3 - using scoped API token
#auth_token: YOUR_CF_SCOPED_API_TOKEN
#zone_id: YOUR_CF_ZONE_ID

Note that all irrelevant lines are commented (i.e. a preceeding '#'), leaving only the 'auth_token' line - the only key/value that should be used with an unscoped API key.

If you've double checked both of those things and are sure that you have it right, please share the output of the following:

# contents of dehydrated config dir
ls -l /etc/dehydrated

# contents of the custom TurnKey dehydrated conf file
cat /etc/dehydrated/confconsole.config

# contents of the custom TurnKey dehydrated hook script
cat /etc/dehydrated/confconsole.hook.sh

Also please provide the contents of any/all lexicon yaml ('.yml') config files. Before posting the output, be sure to redact any authentication secrets (username, API key, etc). Replace the secret/s with "REDACTED" or similar so we can see the full config, but not any of the values.

# show names and contents of all yaml files in /etc/dehydrated - be sure to redact secrets
find /etc/dehydrated -type f -name "*.yml" -print -exec cat {} \;

Also here are the relevant Cloudflare API permissions.

If using an unscoped API token:

permissions Zone:Zone(read) + Zone:DNS(edit) for all zones

Or if using a scoped API token:

permissions Zone:Zone(read) + Zone:DNS(edit) for the one specific zone

As is likely obvious a global API key already has permission to do anything and everything (hence why it's not an ideal option).

Deep apologies that I missed your posts earlier (not sure how/why?!). Anyway, I'm glad that you've got a solution, although that does sound like a bug of some sort somewhere.

When I get a chance I'll test it myself and see if I can work it out. FWIW I have tested multiple (sub)domains via HTTP-01 and tested a single domain via DNS-01, as well as wildcard domain. But I don't think I've tested multiple domains via DNS-01 myself.

Regardless, thanks for reporting and I'm really glad you can move forward now.