Has LetsEncrypt released any documentation on how to invoke the DNS-PERSIST challenge with the client?
At the moment, dns-persist-01 is only available in the staging environment Staging Environment - Let's Encrypt.
Selecting dns-persist-01 must be done by the ACME client so I'd refer to your ACME client's documentation.
I'm using the getssl client, which is a unix shell script. getssl doesn't have an update to handle DNS-PERSIST yet, but if I knew what LetsEncrypt expects to get, I could edit the script accordingly.
For instance, I'm trying a NewOrder request type of "dns-persist-01" instead of "dns" but that's not the correct value.
getssl: ACME server returned error: 400: "detail": "NewOrder request included unsupported identifier: type "dns-persist-01"
I'm trying this against the Stage server
I moved this into its own thread. We like each unique topic to be its own. Your question is not related to the original thread.
The type field in the new order request refers to what identifiers you want in the certificate i.e. a domain name, not the challenge type (RFC 8555 section 7.4).
The available challenges are in the responses to requests to the provided authorizations (RFC 8555 section 7.5).
the domain name is in there too, but I just showed the type. the type value in the un-mod'ed getssl script is "dns".
That challenge is described in the draft RFC here: draft-ietf-acme-dns-persist-01 - Automated Certificate Management Environment (ACME) Challenge for Persistent DNS TXT Record Validation
The Let's Encrypt Staging system reflects version 00 of the draft (not the later v01)
thanks, I'll check it out
The type field should be left as dns unless you're getting an IP address certificate.
Selecting a challenge is performed after fetching the pending authorization (RFC 8555 section 7.5), you might want to check where http-01 or dns-01 appears in getssl.
If you are open to other ACME Clients the lego client already has support for the draft dns-persist. used in LE Staging Correction: The current lego requires draft v01 and does not work with LE Staging dns-persist based on v00. See: How code the dns-persist-01 challenge - #15 by tob.
There are others as well but lego is supported on a wide variety of platforms and often gets support for new ACME features promptly
It offers a CLI which shouldn't be that difficult to use instead of getssl CLI. Isn't getssl mostly in maintenance mode?
Sort of? It gets commits every few weeks; it has profile support on the master branch but I think it's slightly wrong (if you don't specify a profile it picks the first one listed in the JSON output which I read as incorrect; my reading of the spec is that if you want to use the default you just don't select a profile at all, but I'd appreciate a second opinion there).
I have submitted a pull request to add ARI support to getssl; the maintainer said he was going to commit it, but that was two weeks ago. I know life gets busy sometimes for people so I'm not holding it against him.
Fingers crossed. I used getssl for a while but quit almost 5 years ago. I vaguely recall Tim saying he didn't have much time for it back then. Perhaps I remember wrong. It did what I needed at the time and have no ill will for it or Tim.
As a practical matter the CA Server needs to choose a default if the ACME Client did not provide one. It would be impractical for a commonly used CA to stop supporting ACME Clients that did not specify a profile. Especially given profiles is only a draft spec but even if formalized.
That doesn't mean getssl is in violation even though I agree with you that it should not be choosing a default from the advertised list if one is not given by the user.
I say that because of this in the draft
If the server is advertizing profiles and receives a newOrder request which does not identify a specific profile, it is RECOMMENDED that the server select a profile and associate it with the new Order object.
It is only recommended that a server select a default profile. To me that means it could choose to reject the order that omits a profile. Although, as noted I don't think it would be reasonable for a CA to do that as a practical matter.
Further, I don't believe Let's Encrypt has said they will adhere to any particular sequence when advertising the profiles. And, the spec does not indicate anything about this. So, choosing the first in the list isn't necessarily the default LE would choose when a profile is not stated.
Correct, the client should not select a default profile. For example, the server might select a different default for you, depending on what's in the rest of your order (e.g. defaulting to classic for most orders, but defaulting to shortlived if the order contains an IP address). If the client selects a default, it removes the ability of the server to make intelligent profile selections, as it always did before profile selection was an option.
Unfortunately not. Lego expects draft 01, but Let's Encrypt Staging uses draft 00. Error message: "dnspersist01: missing accounturi in challenge object"
Thanks! That was my read also, but as Mike pointed out the draft is a little vague on what a client is supposed to do by default; maybe that could be clarified in the next version?