The ACME v2 announcement indicates that Pre-authorization “is an optional feature and we have no plans to implement it.” Can you provide more information about this decision?
The v1 pre-authorization feature is very useful when developing an integration as a hosting provider. In this case domains are only partially in control of the provider, and partially in control of the provider’s customer. Because of this, there are occasional authorization errors due to things like DNS configuration problems or propagation delays. This is despite best efforts to only attempt authorization on domains that are expected to succeed.
With the v1 pre-authorization workflow this means that new certificates were requested when they would almost certainly be issued. With the v2 order workflow, there’s additional overhead for both Let’s Encrypt and the implementer when the authorizations fail. This includes creating and tracking the order objects, as well as generating the CSR.
Additionally, having authorizations not dependent on the certificate request allows more flexibility in architecture, especially when parallelizing a large number of authorizations.
I have another use for pre-authorizaion, my acme client, acmebot has a master/follower mode. The usage is for when you have a non-http server, for example xmpp, that lives behind a firewall and doesn’t have port 80 or 443 open to it. The server also doesn’t have the ability to set DNS records for whatever reason.
In this case you can setup a master that does have access to DNS or an http server that performs authorizations but doesn’t issue certificates for those domains. Then the follower uses the same account client key and registration and issues certificates by drafting on the existing authorizations obtained by the master.
For the V1 api this was straightforward. For V2 the master creates “authorization only” orders that run through the authorization workflow but never submit CSRs. I presume this is leaving open orders that will eventually expire but are likely consuming server resources until they do. Having the pre-authorization API would avoid this (as would having the ability to cancel the order, which may be possible but I don’t know how to do it properly).
Why can’t the master just pass the order URL back to the follower when it informs the follower that its validations are ready?
Is it because they do not communicate at all, and the follower just tries to get a certificate in a loop and hopes the master completes a validation eventually? If so, the order flow will actually work better for you once this feature is implemented, because the follower will be able to ask the ACME server if there are any orders ready for it, rather than just trying and failing.
There’s no communication between the master and followers (if I could presume that, I’d just have the followers ask the master to respond to the challenges). This workflow only requires a one-time share of the client key and registration (and optionally of the private keys if there are public key pins spanning subdomains).
The followers just go through a normal order flow, but if all the required authorization requests don’t come back as already authorized, they stop and don’t request the certificate rather than attempting to respond to the authorization challenges. So polling for an existing order doesn’t really save much vs polling for existing authorizations. (The master requests the authorizations once per day so the follower’s domains generally stay authorized all the time.)
Also, currently the master just needs a list of all domains to get authorizations for that don’t require certificates. It doesn’t need to know how those domains will be used by followers to issue certificates, e.g. the master could authorize a.example.com, b.example.com, and c.example.com and one follower could issue a certificate for a.example.com and b.example.com, where another follower issues a certificate for b.example.com and c.example.com. Having the master and followers re-use the same orders would require the master’s order configuration to mirror the configurations of all the followers, and a change on one follower would also require updating the master.