Allow changing the "_acme-challenge" TXT record ID

I’m trying to get a wildcard certificate for *.cryptoclimate.io and cryptoclimate.io, as described here, after making the mistake of getting only a certificate for *.cryptoclimate.io.

Due to TTLs or propagation (even though I set the TTL to the minimum 30s on Digital Ocean), it’s been a highly frustrating experience trying to get that wildcard cert over the past hour or so. Every single challenge fails, and I get different (old, like in this post) TXT values from online domain tools checkers vs. running nslookup locally vs. what certbot fails with.

Would it be possible to force a different hostname than _acme-challenge? That should avoid these caching and propagation problems.

The main thing that materially affects how fast you can complete a DNS challenge is how quickly Digital Ocean pushes updates out to its own nameservers.

Last I checked, they are pretty fast about it. I think your problem is elsewhere if things are taking an hour.

Being able to control the _acme-challenge label will not change anything in your situation. Zone updates are not pushed out any quicker on the basis of what the actual change is - it’s opaque.

Regarding TTLs, Let’s Encrypt currently observes TTLs up to a maximum of 60 seconds. That is the worst case delay that can be caused by TTL/caching. You are free to set a TTL of 0 or 1 seconds.

I use Digital Ocean with no problems.

All you need is one wildcard cert. So you had it right in the first place, then messed it up. Make sure that you have 2 txt records. Don’t delete the first one to create the second one. The ttl should not make any difference at all.

Wayne Sallee
Wayne@WayneSallee.com

_acme-challenge is in the IETF specs/RFCs, so I don’t think that will work well.

IMHO your best option to avoiding this problem - and many others - is to use acme-dns (https://github.com/joohoi/acme-dns)

It’s a small RESTful DNS server that works with certbot and other clients. once you set it up and forward the _acme-challenge record to it, you never have to touch the main DNS servers again. you can control all your LetsEncrypt validations through it.

1 Like

A few years ago I had similar problems with namecheap’s DNS. Even with a 60s TTL, it could take 10-30 minutes for things to clear; other times it was fine.

After a lot of experimentation, I eventually concluded they had multi-level read-through cache installed. (It could have been something else, but it behaved like a multi-level read through cache.) While the TTL on the record was 60s, their internal cache seemed to have a 5 or 10 minute storage time, which wasn’t cleared with an update. When I tried to complete a challenge, LetsEncrypt might talk to a DNS server with the 60s timeout that has a local cache, or trigger an internal distributed cache lookup between 60s and 300s, or trigger a new internal datastore lookup. Every subsequent attempt was the same - either returning one of 2 possible stale values or doing a read-through cache on the new value.

At that point, I just said “fork it” and migrated everything to acme-dns.

1 Like

DigitalOcean uses Cloudflare DNS Firewall, which has configurable edge caching. So there probably are multiple layers of caching involved. I don’t know if DigitalOcean has published the details.

1 Like

I tried acme.sh and it also failed with “Incorrect TXT record”.

Then I simply waited an hour from adding the TXT record to pressing Enter to preform each challenge, and that worked. After two hours, I have my wildcart cert :raised_hands:. So I think the problem was with DigitalOcean’s caching.

Allowing _acme-challenge to be changed is extremely dangerous. Let’s say a malicious actor gets access to set a limited number of txt records, but _acme-challenge isn’t one of them. They could get still get a wildcard cert, and if they disguised it as something technical you might not notice.

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