Matthew's picture

Hi there. I've been having issues with Let's Encrypt via the dns-01 method in confconsole and am looking for help.

Forum: 
Jeremy Davis's picture

Hi Matthew, could you please provide some more info.

Are you getting specific errors? Or is it just not working? Or something else?

Matthew's picture

Thanks for replying. Here's what I've found out so far. For whatever reason, I think the auth_token isn't working with lexicon/confconsole, resulting in the following error (actual domain name removed):

requests.exceptions.HTTPError: 400 Client Error: Bad Request for url: https://api.cloudflare.com/client/v4/zones?name=example.com

Running the below command from the terminal produces the same error:

# lexicon --config-dir /etc/dehydrated/ auto list example.com A

I've tried both account owned and user owned API tokens, as well as the global API key, without success. The tokens I created aren't restricted to any particular zone, but I tried both with and without the zone_id in the lexicon_auto.yml file and neither worked.

The following works from the terminal, however, with either a valid user or account API key (actual key & domain removed):

# curl "https://api.cloudflare.com/client/v4/zones?name=example.com" -H "Authorization: Bearer 1234567890123456789012345678901234567890"

Any help would be appreciated.

Thanks,
Matt

Matthew's picture

Also, the following (with the correct info) works with the account API token:

LEXICON_CLOUDFLARE_TOKEN="1234567890123456789012345678901234567890" lexicon --config-dir /etc/dehydrated/ auto list example.com A

Maybe the config file is not used correctly?

Matthew's picture

I sort of figured it out. I ignored lexicon_auto.yml and manually created a lexicon.yml in /etc/dehydrated/ as follows:

cloudflare:
   auth_token: 1234567890123456789012345678901234567890 # Account API Token

 
So I guess I'm writing the lexicon_auto.yml config file incorrectly, but https://dns-lexicon.github.io/dns-lexicon/configuration_reference.html doesn't say very much about "the auto provider." I tried a few different ways and couldn't get it working. It would be nice if I could do it the "right" way so it showed up in confconsole if you have any insight.

Jeremy Davis's picture

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.

Matthew's picture

I imagine picking CloudFlare would have worked fine. Instead, I tried to be clever and picked "auto" from the start and couldn't figure out how to get that to work properly, either by using example 2 directly or putting what I wrote in my manual file in the auto file. I suspect Lexicon requires something for "auto" to work that I haven't figured out. If everything but CloudFlare and Route53 uses "auto" by default then that might explain why I had an issue with another provider too before I decided to try CloudFlare.
Jeremy Davis's picture

Thanks for the info, that makes sense.

AFAIK the "auto" config just uses the specific DNS provider config and tries to guess your provider, hence why the "auto" docs are limited. Although your note about failure trying to use an alternate DNS provider suggests not...

Regardless, in an effort to make things more obvious/explicit I've added more info in the templates. Do you think that might have made things clearer and easier for you?

Any additional suggestions/modifications warmly welcomed.

Matthew's picture

I like the updates in that commit with the suggested method pointed out. I admit that it might not have deterred me completely from trying (and breaking) things, but that's the whole point of a home lab. :-D Thanks for being so responsive. I also opened an issue with dns-lexicon because I think the real fault lies in their documentation of the "auto" provider. https://github.com/dns-lexicon/dns-lexicon/issues/37

Add new comment