0
votes

A CSR is mainly created to create a certificate having trusted public key.

Before creating a CSR,

we create a private key

openssl genrsa -out key.pem 1024

and then use that private key(key.pem) to create a CSR(req.pem) request.

openssl req -new -key key.pem -out req.pem

Edit:

I see that a docker engine is installed with root certificate, server certificate & private used with CSR

enter image description here

What is the exact purpose of providing private key(key.pem as input) amidst submitting CSR? Because certificate is supposed to be signed with parent private key

Is private key(key.pem) required to generate corresponding public key amidst CSR creation?

or

Is private key(key.pem) used to encrypt the CSR and the resulting signature is appended to CSR?

1
The CSR is signed with your private key. As it contains the public key, the CA is able to verify the signature. - Lorinczy Zsigmond
@LorinczyZsigmond and that signature is replaced with CA private key's signature amidst creating certificate from CSR(openssl x509 -req -days 365 -sha256 -in req.pem -CA ca.pem -CAkey ca-key.pem -CA createserial -out server-cert.pem). Is that the only difference in content from CSR(req.pem) to certificate(server-cert.pem)? - overexchange
The CA might change fields, add/remove usages etc. Also the CA determines the validity interval of the certificate ('not before', 'not after' fields). Edit: also the certificate contains issuer-specfic data, unlike the CSR. - Lorinczy Zsigmond
@LorinczyZsigmond does signature gets replaced? As asked in my previous comment... - overexchange
Yes, or to be precise, the cert and the csr are different documents, signed by different parties (issuer CA vs requestor). - Lorinczy Zsigmond

1 Answers

2
votes

The structure of a PKCS#10 certification request (RFC 2986) is, loosely described:

Request:
    Info:
        Version
        Name
        PublicKey
        Attributes
    SignatureAlgorithmIdentifier
    Signature

The attributes are attributes for the request, where one if them could be attributes you are requesting for the resulting certificate.

The CA can respect as much, or as little, from the CSR as it chooses. StartSSL, for example, only read out the public key information, and discarded the remainder of the CSR -- everything else they needed was based on your request from their web UI and your account status.

In general, the CA isn't going to ignore the public key value, because if they asserted a new keypair for you they'd need to figure out how you were supposed to get the private key. So, the public key part needs to be present and correct. OpenSSL's command can get the public key value by reading the private key, then it can embed it in the CSR.

The second reason you need the private key is to sign the request. I'll assert that the main reason the request is signed is to force/strongly-suggest you save the private key at this stage, so you don't come back in a few minutes with a "please revoke this new certificate, I already lost the private key" request. The RFC (also) has this to say:

Note 2 - The signature on the certification request prevents an entity from requesting a certificate with another party's public key. Such an attack would give the entity the minor ability to pretend to be the originator of any message signed by the other party. This attack is significant only if the entity does not know the message being signed and the signed part of the message does not identify the signer. The entity would still not be able to decrypt messages intended for the other party, of course.