On Thu, 25 Aug 2016 13:57:25 -0400 Daniel McCarney <[email protected]> wrote:
> In the earlier "Re: [Acme] Preconditions" thread[2] Andrew Ayer seems > to agree > that there should be only one issuance method to simplify client > behaviours, though he favours proactive issuance instead of > on-finalization issuance. While > it saves a round-trip message I'm not sure that this alone is > convincing enough > to choose proactive issuance as the one issuance method. There's another reason I prefer proactive issuance: I think the server should automatically issue a new certificate if an application's current certificate is about to expire and its authorizations are still valid. This lets you create an application from a central location with access to your account key, and then have your TLS frontends/load balancers make unauthenticated GETs to keep the certificate up-to-date. I think this is essential to make short-lived certificates work robustly, but it's useful even with longer-lived certificates. I went into further detail in my previous email[1]. Requiring an explicit action to issue would mean you'd need some process somewhere to request issuance when a cert is about to expire. This process would need access to your account key (so it should not run on your frontend servers), and if it fails your certificates stop renewing. I understand the bulk issuance use case you describe. Could it be accomplished instead by a boolean field in the application to enable/disable the application? Certificates would only be issued when the application is enabled. Bulk issuers could pre-create authorizations in the disabled state, and enable them when ready to issue. Regards, Andrew [1] https://www.ietf.org/mail-archive/web/acme/current/msg01160.html _______________________________________________ Acme mailing list [email protected] https://www.ietf.org/mailman/listinfo/acme
