a month ago
Wildcard *.aios-app.de fails with internal error since days. DNS verified correct (cname _acme-challenge delegation + tokens resolve, no caa, no dnssec) apex issued fine. please do a server side certificate job cleanup for the wildcard and confirm if the account is lets encrypted rste limited.
thank you
10 Replies
a month ago
Hello, we have acknowledged an issue with wildcard behavior when more-specific third-level domains are also provisioned on the service. I will update you when we have a fix in place.
a month ago
hello, it seems like your issue might be unrelated 🤔 let's encrypt can't find validate the _acme_challenge record
a month ago
when did you last update dns? it might take a while to propagate
Attachments
At_acme-challenge.aios-app. de my zone has ONLY your delegation CNAME → udlys13e.authorize.railwaydns.net (grey-clouded, no manual TXT on my side).
So the TXT records Let's Encrypt rejects are served by lyour delegation host, not me.
Proof, queried just now:
- dig TXT _acme-challenge.aios-app.de → "LBFa2qbv.." , "UHU1dMS.."
- dig TXT udlys13e.authorize.railwaydns.net (your host, direct) → "vogyy1PV….", "vAzXzHGp…", "zR9RqDWi…" The tokens don't match between the two and the count keeps changing (2 vs 3), i.e. your delegation DNS is publishing multiple/rotating tokens and none match the authorization being polled → the 403 "Incorrect TXT record (and 1 more)". My Cloudflare side is correct and unchanged. Could you re-check the token sync on the delegation / re-issue on your end? Happy to test whenever you've pushed a fix.
i updated my dns about 24h ago
here is my dns export if you want to take a look. everything looks fine from my end
Attachments
hey @Phineas Do we already have a solution for the problem? When can we expect it to work again?
a month ago
it worked now. after a retry after 2 days. without changing anything. thread can be closed.
Status changed to Solved brody • 29 days ago