Continuing the discussion from Dns-persist-01 challenge : [image] Dns-persist-01 challenge I had hoped the ACME client did not have to start the issuance process at all (by creating a new order) just to be able to get the CA's issuerDomainNames. (To get all needed values for the dns-persist-01 ch…

Just to add to the list of proposed changes that could fix this issue: Add the issuer-domain-names list to the meta field in the directory alongside caaIdentities Remove issuer-domain-names from the spec and rely on the account URI for cross CA reuse protection. Option 1 would be my preferred sol…

[image] mholt: issuerDomainNames I just did this: ACME.apk/src/main/java/eu/sebbe/acme_nostate/MainActivity.kt main caadomain = directory.meta.caaIdentities[0] if (domains.isEmpty()) { onProgress(0) return Pair( …

Is there a reason they can't just turn the caaIdentities option into a MUST? Like, it's still optional for base RFC8555, but becomes required if implementing dns-persist-01?

Not really required. If you make a client that supports different CA's rather than coding directly at a CA, you can easily check if caaIdentities is present in meta, and say "unsupported CA" if the CA doesn't publish caaIdentities. The CAB/F actually sets it as requirement that whats accepted in CA…

[image] sebastiannielsen: Works aswell, you really don't need to create an order to get the required value. Note that caaIdentities is not (currently) required even if DNS-PERSIST is supported, and does not have to intersect with the set of values in issuerDomainNames, which is problematic. I…

You can safely assume directory.meta.caaIdentities[0] is the "primary CA name". issuerDomainNames MUST be a subset of caaIdentities, but caaIdentities does not be == issuerDomainNames. The MUST here is derived from the CAB/F forum, not the RFC for DNS-PERSIST-01.

Bottom line, I agree with @mholt in that ACME clients should be able to definitively derive everything they need to pre-create a dns-persist-01 record using only information from an ACME directory endpoint and an established ACME account object. [image] sebastiannielsen: You can safely assume d…

Thanks @rmbolger . I opened an issue with the spec authors as well since I think, while it's Let's Encrypt's lack of newAuthz that I hit this snag, the crux of the problem is the weak verbiage in the spec that could prevent this entirely.

@mholt have added my minor 2c - signalling via meta seems to me to be the best combination of an optional and flexible way to streamline the process for clients.

Thank you for opening the issue. While this discussion has been productive, I am not one of the authors of the spec and (to the best of my knowledge) the authors are not watching this forum for feedback.

DNS-PERSIST without spending an Order

Client dev

Topic		Replies	Views
Dns-persist-01 challenge Client dev	20	787	April 2, 2026
Problem finding dns-persist-01 in staging Client dev	26	640	May 8, 2026
Dns-persist-01 deployment status and timeline Issuance Tech	9	793	May 7, 2026
How code the dns-persist-01 challenge Client dev	15	146	May 22, 2026
DNS-PERSIST-01 and _validation-persist CNAME Issuance Tech	4	261	May 7, 2026

DNS-PERSIST without spending an Order

Related topics