Certificates issued based on a manually created signing request

[dcchannell]

I have a question concerning certificate renewal. I have an application which requires a custom certificate signing request be created with all the application require information included. I've tested submission of the signing request and was able to get a signed certificate from LE. I also tested certificate renewal and found I was able to renew without having to create and submit a new signing request.

My question is this, is there a limit to how long I can simply continue to renew the certificate created or is there a requirement to submit a new signing request after some period of time?

[Nummer378]

You can reuse a CSR indefinitely, subject to some limitations:

• If you revoke any certificate with the CSR's public key with reason keyCompromise, the public key is blocked and can no longer be used. Thus, the CSR will no longer be accepted, due to containing a blocked key.
• Future advancements in cryptography may also result in Let's Encrypt requiring a stronger public key, thus refusing CSRs with known insecure keys.
• It has happened in the past that Let's Encrypt stopped supporting a particular algorithm. For example, SHA-1 signed CSRs are no longer accepted. Such deprecations can happen again in the future (though nothing is planned at the moment)
• If the CSR contains any extensions (e.g. must-staple extension), Let's Encrypt may stop supporting these in the future.

[jvanasco]

Adding to the above:

• The ACME v1 protocol (retired) built an ACME Order off a CSR; the ACME v2 protocol (current) creates a compliant CSR from the order details.

• The ACME protocol allows CAs like LetsEncrypt to ignore or change fields in the CSR. There is no guarantee the finalized Certificate will have all the fields in the CSR as presented for signing. Note the following from 2023:

@aarongable

The CSR contained in the Finalize request message can carry additional information, but copying values directly from CSRs to final certificates has been the root cause of many CA incidents, so great care must be taken. Let’s Encrypt does use the presence of the “ocspMustStaple” extension in the CSR to cause the inclusion of the same extension in the final certificate, but this is the only attribute we extract from the CSR and frankly we’d rather not even do that much.

The CSR basically only exists in ACME v2 as a way to prove possession of the private key public key (corrected, thanks @aarongable) . There have been recent discussions of removing CSRs from ACME and using other methods to specify the public key.

Your test with a custom CSR may have resulted in a valid Certificate, but that does not mean the Certificate contains all the information you shared on the CSR.

There is currently a hard-fail on CSRs that indicate must-staple; I believe all other fields are simply ignored.

[aarongable]

@jvanasco

The CSR basically only exists in ACME v2 as a way to prove possession of the private key. There have been recent discussions of removing CSRs from ACME and using other methods to demonstrate control of the private key.

Even less than that. The CSR basically only exists in ACME v2 as a way to transport the public key.

A CSR is not proof of possession of the corresponding private key. It's proof that someone, at some time, wanted that pubkey and these domains to be associated with each other. But one can download a CSR from someone's github repo and submit it in an ACME Finalize request without ever having had access to the private key which was originally used to create that CSR. There's a reason that the Mozilla Root Program Wiki says "A CSR alone does not prove possession of the certificate’s private key for the purpose of initiating a revocation."

But otherwise, yes, all of the above is correct. You can continue to reuse a CSR as often as you like, but we recommend against it if at all possible. When something about the CSR you're using does break, you'll have to manually intervene to create a new one. It's much better to have a system which can dynamically, correctly, generate a new CSR (preferably containing a new key! key rotation is good!) every time.