Clarify certificate refresh process

[letsencrypt]

Clarify certificate refresh process

[martinthomson]

I have no problem with a real-time generation in response to the request. That keeps the generation load low when there are no incoming requests. Using the request to trigger generation is perfectly reasonable. If the server is stressed, and it doesn't have a pre-made cert ready, it can always respond with a 503 and a Retry-After.

As for unauthenticated requests generating load, it's easy to check how old the current cert is before starting the new one. I have no concerns here regarding strange corner cases.

Leave this to the discretion of implementers. Obviously, pre-generation is going to give you the most predictable load profile, but don't force it on everyone.

[bifurcation]

+1 to what Martin said. This is not a protocol issue, it's up to
implementors.

On Mon, Jan 26, 2015 at 11:20 PM, Martin Thomson [email protected]
wrote:

I have no problem with a real-time generation in response to the request.
That keeps the generation load low when there are no incoming requests.
Using the request to trigger generation is perfectly reasonable. If the
server is stressed, and it doesn't have a pre-made cert ready, it can
always respond with a 503 and a Retry-After.

As for unauthenticated requests generating load, it's easy to check how
old the current cert is before starting the new one. I have no concerns
here regarding strange corner cases.

Leave this to the discretion of implementers. Obviously, pre-generation is
going to give you the most predictable load profile, but don't force it on
everyone.

—
Reply to this email directly or view it on GitHub
#59 (comment)
.

[bifurcation]

Thinking on this further, I've had some evolution in thinking. I think it's pretty critical that refresh be client-initiated, probably using something like a new-cert transaction but specifying the base certificate and the new validity interval.