I’ve been working with various LE clients for a while, but this is actually the first time I’m integrating directly with the API and I’d like a confirmation about a doubt I have regarding New Requests vs Renewals.
As far as I can see, there is no notion of “renewal”. A renewal is essentially a “new request” sent to the
new-cert resource endpoint. Is it correct?
From the acme specification I read:
To avoid unnecessary renewals, the CA may choose not to issue a renewed certificate until it receives such a request (if it even allows renewal at all). In such cases, if the CA requires some time to generate the new certificate, the CA MUST return a 202 (Accepted) response, with a Retry-After header field that indicates when the new certificate will be available. The CA MAY include the current (non-renewed) certificate as the body of the response.
From the client’s perspective, there is no difference between a certificate URI that allows renewal and one that does not. If the client wishes to obtain a renewed certificate, and a GET request to the certificate URI does not yield one, then the client may initiate a new-certificate transaction to request one.
My interpretation is that a client should first send a GET to the certificate URI and compare the existing certificate. If it’s the same, then a new cert should be requested. And, in fact, this is what some clients I’ve worked with already do.
This implies that, in some cases, Let’s Encrypt may actually self-renew a certificate. Is it correct?
- In which cases LE will renew a certificate (resulting then in a different resource when I perform the GET)?
- Also, if I request a new certificate, how will LE detect that this is a renewal (and therefore lift the corresponding issuance limit)? Do I have to reuse the same CSR/private key?
As for reissue/rekey, I assume there is no such thing. To re-key a certificate I simply need to request a new one (and the request will be rules by the issuance limit). Is it correct?