DNS-PERSIST without spending an Order

Client dev
1

Continuing the discussion from Dns-persist-01 challenge:

I was a little dismayed by this thread tbh. The designers of the dns-persist challenge seem to have no perspective or care for real-world client concerns, and seem to be missing points of concern brought up by client developers, so I would like to reiterate here...

And apologies if I am missing something obvious, as is usually the case!

Is it possible to get the issuerDomainNames without creating an order? According to the spec, a pre-auth (newAuthz) should make it possible, but Let's Encrypt's directory does not offer this optional endpoint.

Right now it seems like in order to use DNS-PERSIST, interactive use is required, because an Order must be created first, and orders expire and cost fake Internet tokens. :slight_smile:

Aaron's opinion does not seem to consider this though:

If it did that every time, all renewals would be manual, and that's a problem. If it never did the prompt-and-wait, the user would never be told what record they should put in place.

This perspective still implies an initial mandatory interactive certificate issuance, rather than a pre-authorization or even just a GET request for information.

I think most users, at least of my clients, will run a command or hit an API endpoint to get the info they need for a DNS record, then provision that record once and be done.

They will NOT want to do this in-band with a real order getting a certificate. The whole point is to provision the record before needing certificates.

The DNS-PERSIST spec says that CAs "MAY" use the domains in the directory's caaIdentities field, but this is optional (and the "MAY" is weak). So I can't rely on that.

It seems we have to create an Order, then initiate an Authz to get a Challenge object with issuerDomainNames. This essentially mandates interactive domain issuance.

The information we need from the CA should be a free GET request, or should just be in the directory. It already might be in the directory but weak verbiage makes this unreliable.

Calling the newAuthz endpoint would be acceptable if we must, but this is also an optional endpoint and Let's Encrypt's directory does not include it.

So what are we to do?

Please, either:

  • require that issuerDomainNames be identical to the caaIdentities in the directory (so we can just use caaIdentities)
  • or revise the spec so that supporting DNS-PERSIST necessarily implies supporting pre-authorization (newAuthz then becomes required for DNS-PERSIST).

Thank you for considering, and please enlighten me if I've missed something...

2

Just to add to the list of proposed changes that could fix this issue:

  1. Add the issuer-domain-names list to the meta field in the directory alongside caaIdentities
  2. Remove issuer-domain-names from the spec and rely on the account URI for cross CA reuse protection.

Option 1 would be my preferred solution unless someone can provide a use case for per domain issuer-domain-names.

3

I just did this:

Works aswell, you really don't need to create an order to get the required value.

Letsencrypt does definitely publish caaIdentities. For other CA's that support ACME, you can just look if they support caaIdentitites. There is not many CA's today that support ACME, and for those that do, most, if not all, publish caaIdentitites.

Checked:
ZeroSSL publish caaIdentitites
GTS publish caaIdentities
Letsencrypt publish caaIdentities
ssl.com publish caaIdentities (both for ECC and RSA endpoints)
Actalis: Does NOT publish caaIdentities

Just one CA you need to be aware of currently who uses ACME.

Note, that for the separation of CA identities between CA's that have relationship between each other (to prevent account "leaking" between, this is enforced by the account-uri which must be CA-unique)
So a CA should accept all valies it accept for CAA, in its _validation-persist record as issuer-domain-name aswell.

4

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?

5

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 CAA, must also be used for DNS-PERSIST-01 - but it CAN choose to reject a "valid" value. (since CAB/F sets what they can accept).
However, the CA CANNOT accept a value in a DNS-PERSIST-01 record, that it would not accept for CAA.

A CA may reject one, but you cannot have one identity for CAA and another for validation-persist:

"2. Theissuer-domain-namevalueMUSTbeanIssuerDomainNamedisclosedbytheCAin
Section 4.2 of the CA’s Certificate Policy and/or Certification Practices Statement; and"

"3.2.2.8 CAA Records
As part of the Certificate issuance process, the CA MUST retrieve and process CAA records in
accordance with RFC 8659 for each dNSName in the subjectAltName extension that does not
contain an Onion Domain Name.Thesepractices MUST be described in Section 4.2 of the CA’s
Certificate Policy and/or Certification Practice Statement, including specifying the set of Issuer
DomainNamesthattheCArecognizes in CAA“issue”or “issuewild”records as permitting it to
issue"

This effectively means, one of the records in caaIdentities field of meta, MUST be suitable for DNS-PERSIST-01 and if that field only contains 1 record, (which is true for all ACME supporting CAs except for ZeroSSL) that value must be accepted.

6

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. It works by chance, for now.

Not that I know. That's my second suggestion above.

But caaIdentities is orthogonal to DNS-PERSIST support, like I said.

  • On the one hand, caaIdentities is optional in the first place. Nothing makes it required (as-is currently)
  • On the other hand, caaIdentities does not have to overlap with issuerDomainNames in DNS-PERSIST.

But how do you know which one, and even then, that's still not acceptable if one of the major ACME CAs is an exception...

7

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.

8

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.

The spec is still in draft. There's no reason to leave it in a state where you have to assume anything. Make it explicit.

9

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.

10

@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.

11

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.

12

@aarongable is it reasonable where the authors be watching for feedback?
Assuming elsewhere besides here ietf-wg-acme repositories · GitHub

13

it's their repo, but they (ietf) use maling list as their main place to discuss. (if not in session) acme

14

Yep, hence I didn't tag you; and I had already opened an issue in the spec's repository (linked above).

Anyway, thanks everyone for the discussion. Sounds like the spec authors (or their LLM; unclear) are updating the spec to add a field called issuerDomainNames to the directory meta to solve the problem:

I haven't seen the PR yet but I hope the verbiage indicates it is required.