I'm trying to obtain a certificate for a private domain name and I'm stuck on the CAA validation:
I'm trying to obtain a certificate for "app.adm.example.tld" knowing that the entire "adm.example.tld" zone is private (querying is only possible from certain IPs), but "example.tld" is public
I've set up a public subzone "_acme-challenge.app.adm.example.tld" to allow the ACME DNS-01 challenge
I'm not having any issues at this level: my nsupdate queries are working correctly (auth & cleanup), querying the name from an external IP is working correctly, no replication issues with secondary servers, etc.
When I try to obtain my certificate with certbot, I get the following error:
Domain: app.adm.example.tld
Type: dns
Detail: DNS problem: SERVFAIL looking up CAA for
app.adm.example.tld - the domain's nameservers may be
malfunctioning
In the logs of my DNS server (bind 9.16), I see queries being blocked on CAA records at the level of app.adm.example.tld and adm.example.tld. From what I understand, Let's Encrypt should also try to retrieve the CAA record of example.tld. Until now, I didn't have any, but I've also tried adding one explicitly authorizing letsencrypt.org, but it doesn't make a difference:
example.tld. 3600 IN CAA 0 issue "letsencrypt.org"
Is it possible to obtain a certificate in such a situation? How can I pass the CAA validation in this context?
It's going to be hard for people here to help without knowing the actual domain name. While CAs will check the higher level if it gets a "no records" response from the full domain name, if it gets an error it doesn't know if there was supposed to be a record forbidding issuance.
To test, put a TXT record at _acme-challenge.app.adm.example.tld, and then try to query the CAA record for app.adm.example.tld and fix whatever is giving you the SERVFAIL. Some tools like Unboundtest and DNSViz may help if you're willing to type your domain name into external tools (though you'll need to make sure to pick CAA, which for DNSViz is a buried advanced option).
Thank you for your response. I understand that it's not easy to help me in this context. What I would like to understand is how the CAA validation works in detail.
Today, if the Let's Encrypt servers try to request the CAA record for app.adm.example.tld or adm.example.tld, they will receive a REFUSED. Furthermore, if they request the CAA record for example.tld, they should not encounter any problems (I notice none, whether by querying the domain's NS servers or by going through a public DNS, such as 8.8.8.8 & 9.9.9.9 for example) and will retrieve:
example.tld. 3600 IN CAA 0 issue "letsencrypt.org"
If I've understood correctly, this should be enough for the CAA validation to work, but it doesn't seem to be the case. Does the REFUSED status on app.adm.example.tld and adm.example.tld cause any issues?
If I believe the official documentation, the SERVFAIL error is mainly caused by three things:
DNSSEC: I don't have DNSSEC on this zone (dnsviz.net indicates it as insecure)
an invalid response in case of an empty response: my record is not empty and the query returns the record with a NOERROR status
a problem at the level of the domain's NS servers: I've checked and both of my servers are available and return the same thing for the CAA records in question.
I think these are saying the opposite things? If it's getting a REFUSED status, doesn't that mean that the authoritative server doesn't think it's authoritative for that name? In which case, Let's Encrypt can't tell whether it's allowed to issue for that name. Whereas a NOERROR (even with no records) would indicate that the name has no additional restrictions on what CAs can issue for it.
Well, there's a lot in the Let's Encrypt CAA documentation, but if you want it in detail then you probably need to read through the official RFC. I'm not sure what confusion you're having is, though, each level from the full name down to the TLD needs to be checked, and either give a successful "no records" response or a CAA record that allows the CA. This should be the case for all CAs.
Indeed, it's certainly the REFUSED responses on the intermediate names that are causing problems. The fact that I saw the server still attempting a CAA resolution on the higher-level names made me think that this might not be an issue. I tried to set up RPZ to correctly respond to CAA queries for my zone adm.example.tld, but unfortunately, the allow-query clause I use to limit access to the zone seems to take priority over the RPZ and I still get the REFUSED answer from unauthorized clients... If you have any idea of a configuration that would allow obtaining a certificate in such a context, I'm all ears
I haven't had the pleasure of dealing with bind configuration settings myself, but if you post the part of the config that you're having trouble with getting working to respond authoritatively for your domain, it's possible that someone else here could lend a hand.
I've given up on it. Explanation: it was actually a certificate that would be used exclusively by private hosts, and I've decided to set up an internal CA for this type of use case.
