Certificates issued based on a manually created signing request

[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.