Certbot challenge conflict renewing wildcard certificates

Help
1

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:

I ran this command:

certbot renew \
      --preferred-challenges=dns \
      --manual-auth-hook ./authenticator.sh \
      --manual-cleanup-hook ./cleanup.sh \
      --server "https://acme-v02.api.letsencrypt.org/directory"

I have custom Authenticator/Cleanup scripts which are designed to add and remove the appropriate TXT records from Namecheap

It produced this output:
Certbot failed to authenticate some domains (authenticator: manual). The Certificate Authority reported these problems:
Domain: ohmvision.com
Type: unauthorized
Detail: Incorrect TXT record "EzNjxZH9-koDAj5QBhQlUcxHoWTNBQAwd8JML6GRGoY" found at _acme-challenge.ohmvision.com

Hint: The Certificate Authority failed to verify the DNS TXT records created by the --manual-auth-hook. Ensure that this hook is functioning correctly and that it waits a sufficient duration of time for DNS propagation. Refer to "certbot --help manual" and the Certbot User Guide.

My hosting provider, if applicable, is:
Namecheap

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

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

----------------- SUMMARY
So fundamentally, I have a single wildcard certificate for ohmvision.com and *.ohmvision.com

I've noticed that through the renewal command, it attempts to authenticate ohmvision.com and *.ohmvision.com with two separate TXT records on the same host. (ie. ohmvision.com will get "A" as the challenge text and *.ohmvision.com will get "B" as the challenge text)

This seems to pose a problem for certbot which cannot seem to properly resolve the correct TXT record as they both resolve to _acme-challenge.ohmvision.com

I've tried a few different variants to work around this challenge.

  • Adding both TXT records appears to confuse certbot and result in consistent failure - nothing is renewed
  • Adding the first TXT challenge fails the second domain (*.ohmvision.com) consistently - nothing is renewed
  • Adding the last TXT challenge fails the first domain (ohmvision.com) on the FIRST run, but when I run the exact same command again, everything renews correctly

Not sure where to go from here, I've updated my code to process the renewal twice for the time being, but this just seems like a really bad workaround.

Is there something I'm missing here?

2

Yes, that's working as intended.

You just need to add two. You can have multiple TXT records.

This issue might depend on your authenticator.sh, or on namecheap. Can't be sure.

(I think authenticator.sh is called twice, and that sounds right)

3 Likes
3

So it is called twice, and the two TXT records are correctly added. However, the certbot is picking up both and rejecting because one is incorrect. It doesn't seem to understand that one is correct and the other is for the other domain.

What makes this weird, is that when I add only the most recent TXT record and run the script twice, it fails the first time and succeeds in the renewal the second time

4

That doesn't make sense. Try adding --debug-challenges to your command (maybe --dry-run as well) and check if your two records actually get added.

That's because authorizations are cached.

5 Likes
5

So in the past, I've verified that the two records are correctly added.

I even run a dig externally (Dig (DNS lookup)) to verify that the TXT records have properly propagated during the wait step.

Unfortunately, I will have to try the --debug-challenges test next month when the renewal is up again - I've added it to my renewal script so I should be able to pull the logs from the next run

The cached authorizations make sense now as to why it works when I run it twice, didn't know that happened

6

Also, namecheap could be introducing delays. Check this issue if you want to sleep in your hook, No sensible way to add delay when using DNS challenge with --manual-auth-hook · Issue #9497 · certbot/certbot · GitHub

If you want to try, use --dry-run -- it goes against the staging endpoint, and it shouldn't use cached authorizations.

3 Likes
7

Yeah, Namecheap does definitely have some delays in the TTL. However, I was able to configure that and verify the TXT record it at least discoverable from google's dig externally prior to continuing

I introduced a set timeout which is greater than the TTL of the record through a simple
sleep 60 command in the ./authenticator.sh. Originally I was running dig in the script on a loop until the record was found, but it proved to be unreliable. The sleep appears to be consistent

When I've run with the --dry-run command, it appears to consistently succeed

1 Like
8

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