ietf draft's section 5 and 6 mentions persist record with policy=wildcard allows and nested subdomain, but nether pebble and boulder currently do that tree climbing check. so I expect they won't but I'd like to have explict word for this
5 Likes
I vaguely recall seeing some discussion about ways to let clients tell the ACME server which name(s) to check against for the persist records. It's not in the draft yet though.
2 Likes
Links that may be of interest:
4 Likes
Also, nothing prevents you from configuring your DNS server to allow
_validation-persist.*.example.com.
Note that this is not a standard feature, why you might need DNS server support able to do this, for example PowerDNS with LUA support or similiar.
Also, validation complexity can appear, if you have a subdomain chained to a account, and then a wildcard domain chained to another account.
Lets take the example that customersite.example.com is chained to account 1234, while *.example.com is chained to account 2345
How should boulder intrepret such a scenario?
Should both 1234 or 2345 be able to issue for customersite.example.com?
should only 1234 be able to issue for customersite.example.com but 2345 be able to issue for other subdomains?
It becomes kinda ambigious.
So it you want policy=wildcard to mean any SAN and not just wildcard certificates, create the DNS record I suggested with a compatible DNS software. Otherwise, just issue a wildcard certificate - problem solved.
from baseline rule about this challenge both are allowed to issue, but draft doesn't have why to ask acme server to look up upper domain name for persistent txt record.
1 Like
We currently do not plan to do tree-climbing. We would prefer to have the client indicate to us which (parent) domain we should be looking at, confirm it is a valid ADN, and then check just that one location.
5 Likes