Certbot mixed-case_acmE-ChalLENGE fails

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

My domain is:
bc.n0w.cc

I ran this command:
certbot -d *.bc.n0w.cc --manual --preferred-challenges dns certonly

It produced this output:

Waiting for verification...
Cleaning up challenges
Failed authorization procedure. bc.n0w.cc (dns-01): urn:ietf:params:acme:error:unauthorized :: The client lacks sufficient authorization :: No TXT record found at _acme-challenge.bc.n0w.cc

IMPORTANT NOTES:

  • The following errors were reported by the server:

    Domain: bc.n0w.cc
    Type: unauthorized
    Detail: No TXT record found at _acme-challenge.bc.n0w.cc

    To fix these errors, please make sure that your domain name was
    entered correctly and the DNS A/AAAA record(s) for that domain
    contain(s) the right IP address.

My web server is (include version):

Portswigger.net's Burp Collaborator
It's a java application

The operating system my web server runs on is (include version):
Linux n0w 4.19.0-10-cloud-amd64 #1 SMP Debian 4.19.132-1 (2020-07-24) x86_64 GNU/Linux

My hosting provider, if applicable, is:
Route53 however the bc subdomain is running on this host, the Burp Collaborator

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, I ssh onto the box

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

rootn0w certbot --version
certbot 0.31.0

I'm unable to complete the DNS txt challenge with certbot and it seems the issue is the mixed-case query. If I query it manually using lower-case characters I the proper reply.

rootkali dig txt _acmE-ChAlLENGE.Bc.N0W.Cc +short
rootkali dig txt _acme-challenge.bc.n0w.cc +short
"da2dRkv8bNpUT2Bqt4bvrzfA82m3Wi9pk9ld7PDuNz0"

DNS queries are case insensitive; that shouldn't be a problem, assuming you're running a compliant authoritative nameserver.

It doesn't look like your nameserver at 143.198.133.45 is responding to queries from the internet, though.

Gimme a minute I'll have it back up

Yeah I hear you on the case insensitive comment. I guess all I can do is go back to portswigger on that.

I've started up the service so you should be able to get to it now.

Yeah, it does look like it's case sensitive, bummer.

Maybe you can set a CNAME from _acme-challenge back up to the Route53 zone and answer the query there. (Kidding .. kind of).

It can't be changed in certbot to make the request in lower case?

I'll reach out to portswigger just the same.

Certbot is not making this query. Certbot is just making API requests to the certificate authority (Let's Encrypt).

Let's Encrypt perform the DNS lookups on their validation servers using a DNS resolver called Unbound, which is doing the mixed-casing, as a security measure to prevent spoofing of DNS answers:

use-caps-for-id:
Use 0x20-encoded random bits in the query to foil spoof attempts. This perturbs the lowercase and uppercase of query names sent to authority servers and checks if the reply still has the correct casing. Disabled by default. This feature is an experimental implementation of draft dns-0x20.

I think, at this point, there is practically zero chance of Let's Encrypt turning this off. It's been there for years and pretty much works fine for everyone these days.

(And although the documentation says that the 0x20 checking-the-case-of-the-answer-qname stuff is experimental, the requirement that queries are case-insensitive is much older and established; very much not experimental).

2 Likes

If port 53 is allowed to your IP, you could run your own DNS server and delegate the challenge requests to it.
OR use any other compatible DNS server on the Internet.

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