You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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:
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.
The text was updated successfully, but these errors were encountered:
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.
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.
The text was updated successfully, but these errors were encountered: