What is the difference between a signed CSR and a leaf certificate?

Question

When creating certificates with the step CLI I have the option to create a leaf certificate for a certain subject or sign a certificate signing request (CSR). I could not really determine a difference between those two, given I use the same key for both (create a leaf certificate first and then create a CSR with the key created with the leaf). They only seem to differ in their serial number, the validity and - of course - the signature.

This led me to believe that the difference is rather organizational than technical:

• If you trust (own) the CA creating a leaf certificate would be fine because you have full control over where the private key goes
• If you do not trust the CA you would like to avoid the CA knowing your private key, therefor you send them your CSR and let them create your cert based on that

Is that (basically) correct or is there anything else that I missed?

Answer 1

The phrasing of your question is a bit odd, because you're not really asking about the difference between a certificate and a CSR (which are of course fundamentally different entities) but rather two different workflows for obtaining a certificate:

• If you have your own CA, the tool you use lets you issue certificates directly without creating a CSR first. The certificate will be signed by your CA.
• Alternatively, when you want a certificate for a particular identity and public key, the tool lets you create a CSR which can then be sent to some CA. The resulting certificate will be signed by that CA.

From a conceptual standpoint, there's no need for a CSR in either case. If you have your own CA, then you can create any certificate you want. You just take a public key, define the certificate's subject and then sign the certificate with the CA's private key. Professional CAs could also choose to skip the CSR step and ask you to provide your public key and your identity information through other means (e. g. a web form) -- unless there's a specific policy or infrastructure which requires the use of CSRs, of course. This has nothing to do with needing the private key of the certificate requester. The CA never needs that key for issuing the certificate (leaving aside those rather strange services which generate a key pair for you).

The purpose of a CSR is to cryptographically bind a subject (with a common name, country, organization etc.) to a public key, so that there are two guarantees:

• The requester does in fact have the private key associated with the public key.
• The subject data has in fact been provided by the requester.

If you simply want to create your own certificate on your own machine, those guarantees don't matter much. However, in more complex scenarios where the CA is a separate entity, CSRs make sense. But again, in principle, CAs don't have to use CSRs.

Answer 2

A leaf certificate is an end-entity certificate that cannot sign other certificates. If an intermediate (capable of signing) certificate and its private key is supplied to the tool, it can issue a leaf certificate without recourse to the CA, who would own, or would have provided, the intermediate certificate.

A CSR is usually signed by the CA, directly with the root CA certificate or with a signing intermediate certificate.

As to the two-part question, it is not strictly a matter of 'trust'. A private key is strictly private and can be used to access that the certificate that is being signed. Delegation is achieved not by 'trust' or lack thereof, but through intermediate signing certificates:

• Rather than CA, an intermediate certificate capable of signing is required. This would be trust delegated from the CA root certificate, within the organization or across organization.
• A private key is just that -- private. Trusting the CA is not relevant in this. The CA provides trust to the world through the CA root signature and traceability back to it that is required for the signed certificate to be accepted.

As an example: