Add support for pre-authorizations

[vanbroup]

Welcome

• Yes, I've searched similar issues on GitHub and didn't find any.

How do you use lego?

Binary

Detailed Description

Please add support for pre-authorizations as defined in section 7.4.1 of RFC8555:

Some servers may also wish to enable clients to obtain authorization for an identifier proactively, outside of the context of a specific issuance. For example, a client hosting virtual servers for a collection of names might wish to obtain authorization before any virtual servers are created and only create a certificate when a virtual server starts up.

Support for pre-authorizations can help the ecosystem to move to shorter domain validation re-use periods, for example by supporting organizations in keeping their domain/IP address authorizations up to date, even if these eventually do not use ACME to request or provision their certificates.

Another advantage could be that the authorization and issuance process could be separated, ensuring that DNS credentials do not have to be exposed on a server that is accessible from the internet.

[ldez]

Another advantage could be that the authorization and issuance process could be separated, ensuring that DNS credentials do not have to be exposed on a server that is accessible from the internet.

pre-authorization cannot be used with a DNS challenge or any challenge type to get wildcard certificates, so it will not "protect" DNS credentials.

Note that because the identifier in a pre-authorization request is
the exact identifier to be included in the authorization object, pre-
authorization cannot be used to authorize issuance of certificates
containing wildcard domain names.

https://www.rfc-editor.org/rfc/rfc8555.html#section-7.4.1

[vanbroup]

Thanks, that is a good point, however, this note does not exclude the use of DNS.

1. The CA can create new authorizations for the exact identifier such as the FQDN (even if the validation took place through DNS, like it would do in any new-order scenario).
2. In case the validation method allows, the CA could potentially register multiple authorizations, for example *.example.com and example.com if validated appropriately.
3. If a pre-authorization method would grand domain wide issuance based on the CA/Browser Forum BR requirements, this could be registered by the CA (for example to the external account as described below), the CA could then use this authorization (or create a new completed one on the fly) as soon it receives a new order request from a client that is already authorized for the given FQDN / wildcard.

From https://www.rfc-editor.org/rfc/rfc8555.html#section-7.1.3

authorizations (required, array of string): For pending orders, the authorizations that the client needs to complete before the requested certificate can be issued (see Section 7.5), including unexpired authorizations that the client has completed in the past or identifiers specified in the order. The authorizations required are dictated by server policy; there may not be a 1:1 relationship between the order identifiers and the authorizations required.

...

The "authorizations" array of the order SHOULD reflect all authorizations that the CA takes into account in deciding to issue, even if some authorizations were fulfilled in earlier orders or in pre-authorization transactions. For example, if a CA allows multiple orders to be fulfilled based on a single authorization transaction, then it SHOULD reflect that authorization in all of the orders.

Note that just because an authorization URL is listed in the "authorizations" array of an order object doesn't mean that the client is required to take action. There are several reasons that the referenced authorizations may already be valid:

o The client completed the authorization as part of a previous order
o The client previously pre-authorized the identifier (see Section 7.4.1)
o The server granted the client authorization based on an external account