Problem with wildcard cert using dns-01 challenge

[dfrandin]

My domain is: frandin.org

I am trying to generate a wildcard cert to apply to my webmin installs on
my virtual servers, as "https://vm1.frandin.org:1000" "https://vm2.frandin.org:1000"

I ran "certbot certonly --manual -d *.frandin.org --agree-tos --preferred-challenges=dns-01 -m daveinlv@frandin.org --server https://acme-v02.api.letsencrypt.org/directory"

I recieved the info "_acme-challenge.frandin.org" text record, with a long string to be copied into a text record on the NameCheap webpage for my frandin.org
domain. I created a txt record, with the "_acme-challenge.frandin.org" in the
field Namecheap calls "host" and the long string in the field marked "value"
and saved with a ttl of 1 minute. When I add a host with a ttl of 1 minute, I'm
able to ping that host in little more than a minute. I've waited up to an hour
for that txt record to propagate, while leaving the certbot at the "press any key to
continue". I've used the dns txt record check at MXToolbox to verify that the
txt record had propagated, but all I see is my spf txt record for mail. Am I doing
something wrong OR is there a problem with NameCheap's txt record handling?
I've tried this several times over the past few months and never get the txt record propagated..

[sahsanu]

Hello @dfrandin,

@dfrandin

I created a txt record, with the "_acme-challenge.frandin.org" in the
field Namecheap calls "host"

In that host field use only _acme-challenge instead of _acme-challenge.frandin.org because you are creating the record _acme-challenge.frandin.org.frandin.org

$ dig _acme-challenge.frandin.org.frandin.org txt                                                                                                      

; <<>> DiG 9.16.1-Ubuntu <<>> _acme-challenge.frandin.org.frandin.org txt
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 59371
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
;; QUESTION SECTION:
;_acme-challenge.frandin.org.frandin.org. IN TXT

;; ANSWER SECTION:
_acme-challenge.frandin.org.frandin.org. 54 IN TXT "lHnLxRKApHUvggeaLa6QVC-9QFGk-s6c8lt-mJYOmbE"

;; Query time: 19 msec
;; SERVER: 1.1.1.1#53(1.1.1.1)
;; WHEN: sáb feb 06 01:53:39 CET 2021
;; MSG SIZE  rcvd: 124

Cheers,
sahsanu

[dfrandin]

Thanks!! Removing the .frandin.org worked... The documentation doesn't make that clear....

[schoen]

I think a best practice in a web-based zone editor is to have a label with the domain next to the input field, so that users can easily see that it will be automatically appended to the subdomain that they enter.

The idea of auto-appending the domain to the record name goes back (at least) to zone files in BIND in the 1990s—if not longer—and people often find it helpful, but also often find it confusing. It's hard to know how to communicate this in a program like Certbot, because the actual procedure for creating DNS records could vary so widely.

https://letsdebug.net/ has a check for this specific issue.

I've thought of proposing that Let's Encrypt itself should check for this, but I have a feeling that it could be very tricky to incorporate into the existing validation logic, in the sense that the number of states that a verification could be in at a particular moment (in different parts of the validation system) could expand a lot, and it might end up consuming a lot of extra resources on the CA side as well.

[_az]

If users are copy-pasting the domain, it could help to add a trailing period to the prompt in the manual plugin:

Please deploy a DNS TXT record under the name
_acme-challenge.example.com. with the following value:

There's at least a couple of zone editors I've used that will do the right thing if you include the trailing period, but won't if you don't.

More generally I would really love if it was possible to do away with users having to go through this process. I plead for a more pragmatic DNS validation method .