[GH-ISSUE #339] CAA issues when higher level domain has a CAA #184

New issue

Open

opened 2026-03-13 16:04:40 +03:00 by kerem · 2 comments

kerem commented

2026-03-13 16:04:40 +03:00

Owner

Originally created by @peharri on GitHub (Apr 28, 2023).
Original GitHub issue: https://github.com/acme-dns/acme-dns/issues/339

OK, so I had a problem this morning, I worked around it, but I feel like there might be a way to prevent it from happening automatically.

I have an acme-dns server on acme-dns.example.com, and I want to fetch certs for example.com. [All domains changed to protect the guilty]

When I initially set up the certificates for example.com, certbot recommends adding a CAA record. So I dutifully did that. (Quite a while ago, not sure what changed that causes the below chaos to result, but...)

Anyway, this morning my certificates have expired, there's no renewed certs, and after a lot of digging and upgrading to the latest, I find acme-dns is reporting that it can't grab a certificate for its own REST service:

Apr 28 09:20:20 vps acme-dns[3437465]: 1.682688020881612e+09#011error#011acme_client#011challenge failed#011{"identifier": "[acme-dns.example.com]", "challenge_type": "dns-01", "problem": {"type": "urn:ietf:params:acme:error:caa", "title": "", "detail": "CAA record for [acme-dns.example.com] prevents issuance", "instance": "", "subproblems": []}}

So what's happening? Well, the CAA for example.com exists, but acme-dns isn't generating one for acme-dns.example.com. So it's falling over. (I don't even know if the CAA records for example.com are appropriate any more since I started using acme-dns, but given certbot recommends setting it up, presumably if they are obsolete, then there probably needs to be a workaround.)

So I assume one of two things needs to happen. Either acme-dns needs to generate an appropriate CAA record and serve that DNS record in response to a requests for its domain's CAA, or the docs need to be updated to warn users not to have a CAA for their acme-dns server's parent domain.

I'm guessing this is a new issue because something changed at Lets Encrypt that means it checks CAA records now.

Apologies if this has been reported before or is addressed somewhere, but I wasn't able to find anything appropriate when doing a search of the project (four tickets mentioned CAAs but no code, and the tickets don't really answer this issue.) It's probably only now becoming an issue.

Originally created by @peharri on GitHub (Apr 28, 2023). Original GitHub issue: https://github.com/acme-dns/acme-dns/issues/339 OK, so I had a problem this morning, I worked around it, but I feel like there might be a way to prevent it from happening automatically. I have an acme-dns server on acme-dns.example.com, and I want to fetch certs for example.com. [All domains changed to protect the guilty] When I initially set up the certificates for example.com, certbot recommends adding a CAA record. So I dutifully did that. (Quite a while ago, not sure what changed that causes the below chaos to result, but...) Anyway, this morning my certificates have expired, there's no renewed certs, and after a lot of digging and upgrading to the latest, I find acme-dns is reporting that it can't grab a certificate for its own REST service: Apr 28 09:20:20 vps acme-dns[3437465]: 1.682688020881612e+09#011error#011acme_client#011challenge failed#011{"identifier": "[acme-dns.example.com]", "challenge_type": "dns-01", "problem": {"type": "urn:ietf:params:acme:error:caa", "title": "", "detail": "CAA record for [acme-dns.example.com] prevents issuance", "instance": "", "subproblems": []}} So what's happening? Well, the CAA for example.com exists, but acme-dns isn't generating one for acme-dns.example.com. So it's falling over. (I don't even know if the CAA records for example.com are appropriate any more since I started using acme-dns, but given certbot recommends setting it up, presumably if they are obsolete, then there probably needs to be a workaround.) So I assume one of two things needs to happen. Either acme-dns needs to generate an appropriate CAA record and serve that DNS record in response to a requests for its domain's CAA, or the docs need to be updated to warn users not to have a CAA for their acme-dns server's parent domain. I'm guessing this is a new issue because something changed at Lets Encrypt that means it checks CAA records now. Apologies if this has been reported before or is addressed somewhere, but I wasn't able to find anything appropriate when doing a search of the project (four tickets mentioned CAAs but no code, and the tickets don't really answer this issue.) It's probably only now becoming an issue.

kerem commented

2026-03-13 16:04:46 +03:00

Author

Owner

@peharri commented on GitHub (Apr 28, 2023):

(Oh, the workaround was removing the CAA records for example.com, for anyone else having the issue.)

@peharri commented on GitHub (Apr 28, 2023): (Oh, the workaround was removing the CAA records for example.com, for anyone else having the issue.)

kerem commented

2026-03-13 16:04:51 +03:00

Author

Owner

@tigeli commented on GitHub (Feb 9, 2024):

I added

"sub.domain.tld. CAA 0 issue \"letsencrypt.org\"",

into config.cfg's record-section to overcome this issue... it seems that Let's encrypt is querying CAA record for the subdomain over and over again and certmagic's module used by acme-dns isn't able to handle the delay caused by it or something.

@tigeli commented on GitHub (Feb 9, 2024): I added `"sub.domain.tld. CAA 0 issue \"letsencrypt.org\"", ` into config.cfg's record-section to overcome this issue... it seems that Let's encrypt is querying CAA record for the subdomain over and over again and certmagic's module used by acme-dns isn't able to handle the delay caused by it or something.