I know that a CSR includes a public key from which a signed certificate shall be generated.

But why is the CSR istself signed and which key is typically used? For signing I need a private key, so the user of the CSR's signature must have the associated public key. But what key/pair is taken?

  • $\begingroup$ The private key for which a cert is requested to prove ownership of the key. $\endgroup$
    – SEJPM
    Oct 4, 2016 at 16:32
  • $\begingroup$ does it mean I sign the CSR with the same key, for which the certificate shall be generated? $\endgroup$
    – MichaelW
    Oct 4, 2016 at 18:28
  • $\begingroup$ Effectively, yes. $\endgroup$
    – SEJPM
    Oct 4, 2016 at 18:36

2 Answers 2


[Why] is the CSR istself signed?

The CSR is signed to ensure consistency of the data in it in a similar way to how root certificates are also self-signed. Additionally signing the CSR proves ownership of the private key corresponding to the public key in the CSR.

[Which] key is typically used?

The private key which is associated with the public key embedded in your CSR.

  • 2
    $\begingroup$ Is the CSR signed solely for consistency ("gee, everything else is signed, why not this"), and possibly stop people from accidentally asking for a certificate they cannot use? Or is it to prevent some nonobvious attack? The only thing I can see it preventing is if an attacker replaces the public key in the CSR with their own key, and if they could do that, they'd probably be able to replace the signature as well... $\endgroup$
    – poncho
    Oct 4, 2016 at 18:50
  • 3
    $\begingroup$ Actually, I think there actually are non-trivial attacks. The signature will not provide any authentication, but it will provide non-repudiation, in particular if the key owning entity might be forced to commit to owning a particular key pair. In such a scenario no one can deny having requested a certificate with a particular subject name. $\endgroup$ Oct 5, 2016 at 0:15
  • $\begingroup$ @HenrickHellström can you elaborate on scenario? Perhaps I'm misinterpreting it, but I do not see any context in which it could be relevant to bind the person constructing a CSR to a specific keypair $\endgroup$
    – Joost
    Dec 19, 2016 at 8:55
  • 1
    $\begingroup$ @HenrickHellström most of the tutorials on how to generate a certificate consist of 1) Generate the public/private key-pair -- CSR and key; 2) Sign the CSR with the key; 3) Submit the signed CSR to a CA. The question the topic-starter and I have is why the step 2 is necessary... Actually, GoDaddy's instructions omit the step -- it really must be optional... $\endgroup$
    – Mikhail T.
    Oct 3, 2017 at 14:57
  • 1
    $\begingroup$ @MikhailT: wrong. see comment on your answer, or just look at the resulting CSR and you'll see it IS signed. $\endgroup$ Oct 4, 2017 at 2:14

There are several benefits for enforcing signature on the CSR.

  1. Signing of the CSR provides strong proof that the public key that will end up in the certificate is a valid public key for which there exists a private key. This enforces key generation correctness for certificate requesting party. It also prevents the certificate requesting party from (at least trivially) including arbitrary value in the certificate's public key field (e.g., political statements, hate speech, etc.).
  2. The subject could include some errors in CSR and once the certificate is issued, claim that it was CA who introduced the errors in the certificate. The signature on the CSR will prove that the subject was the one who asked the data with errors to be included in the certificate. Sure, the subject could then claim that the key which signed CSR is not his, but that would be something that is harder for the subject to repudiate, especially if he has already made some signatures with the key and he does not want to repudiate them.
  3. It is possible to come up with attacks against non-standard protocols, that would not be possible if the CSR was signed. For instance, if Mallory could obtain certificate in her name which contains Bob's public key, the Mallory could replace the Bob's certificate attached to Bob's signed message with her certificate and trick the relying party to believe that Mallory signed it. (Note: this will not work in EU eIDAS signature formats where the hash of signatory's certificate is included under the signature.) You could say that this does not provide any advantage to the Mallory, since Mallory could legally obtain certificate which contains her own key and simply resign Bob's messages. However, there may be non-standard protocols where this is not possible. For example, where the relying party expects the public key used to sign the message to have a specific value. This protocol would be secure if CSR is signed, but becomes insecure if the CSR is not signed.

See the reasoning provided in RFC 2986:

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.


Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.