New “replaces” field in the Order object: We have extended the Order object to include a "replaces" field. This field identifies the certificate being replaced by a new order. Our goal is to use this field to exempt renewals within ARI suggested renewal windows from rate limits, thereby encouraging further ARI adoption.
Just thinking out loud a bit here from a client dev standpoint before I've had a chance to actually test anything or read the updated draft. A replaces field on the order object would seem to have useful implications beyond just responding to an ARI initiated renewal.
It could be used to avoid the "annoyance" expiration emails (and associated forum help threads) when a user is purposefully changing the list of identifiers in a cert. Does LE have any plans to allow for that once implemented? Or will the field only be accepted for an ARI initiated renewal?
It could also address this sort of commercial feature request:
For a client wanting to add support for this, would things break for CAs who haven't implemented it yet? Or is the server supposed to just ignore fields it doesn't recognize? I can't remember exactly.
While RFC 8555 mentions things like "The server MUST ignore any values (…)" a few times, this is NOT the case for the order object. Neither section 7.1.3 nor section 7.4 mention anything with regard to ignoring unknown things or mandating an error when encountering unknown items.
Thus with regard to RFC 8555, servers might have implemented anything. Ignoring or erroring out, both are possible for RFC compliant ACME servers.
In this case I don't believe it will be an issue. ACME clients which have not implemented a "replaces" field in their new Order request won't ever receive one back.
Good looking out! This is something that we're aware of and hope to implement in the future. For the time being you should expect that it would be limited to requests with a non-empty "replaces" field. It's important to note, though, that even outside the renewal window, we will recognize request which indicates "replaces" as a replacement. But, these orders might not be exempt from all of the same rate limits.
This was more a question about whether the ACME server would reject a new order request that had a replaces field if one was included. Realistically, it will probably come down to testing the common CAs to see how they respond. But I was more curious if from an RFC8555 perspective should it be ignored or cause a rejection of the order.
Ah, thanks for clarifying. I think the simplest answer to this, is that clients should only be including the "replaces" field in orders to CAs which implement ARI. If the CA doesn't publish a "renewalInfo" endpoint, it doesn't support ARI.
If you implement replaces but your order ends up not overlapping for any domains, will the order be rejected or will the replaces be silently ignored? I'm thinking from the point of view of how much state tracking the client has to do between edits. E.g. if the user removes all the domains, replaces it with different ones (technically no longer a valid replace) then goes back and adds one of the original domains (now a valid replace again).
The current draft in the IETF ACME WG says that servers SHOULD reject new-order requests if the identified predecessor cert doesn't share at least one identifier with the new order, and says that they may implement checks above and beyond that if they want to.
Let's Encrypt intends to use the "one name must overlap" heuristic, as suggested by the draft.
Same answer as above: the draft says that servers SHOULD check that the identified predecessor is from the same account, and Let's Encrypt intends to do so.
Thanks @aarongable I might leave further ARI implementation until it leaves draft, or at least until Certbot uses it. Getting folks to upgrade their client versions once they're happily using a version is surprisingly tricky! @mholt this is probably of interest to you.
And will it just be an all-at-once switch? Or will there be any overlap where both draft-01 and draft-03 requests will work? Just trying to plan out when and how I would need to update my homebrew cobbled-together client.
Thanks for the heads-up. Good discussion. ACMEz is up-to-date with draft-03, though that alone is easy. The hard part is integrating the actual scheduling logic into the higher-level library CertMagic, which thankfully I haven't done yet. I may also wait for big changes to blow over before I invest in that...
I may also wait for big changes to blow over before I invest in that...