7

Why should my certificate signing request be signed by my private key?

Even if I obtain a bogus certificate out of someone else's public key, that is going to be useless, since in SSL the communication can happen only via session key. That session key will be available to me only if I have the corresponding private key for the public key I used to get the certificate for, for the client (or the other party) is going to send the session key encrypted using the public key and I can decrypt it only if I have the corresponding private key.

What then is the need to prove to the CA that I own the private key for the public key I am requesting the certificate for?

6

Accepting unsigned signing requests would not invalidate SSL. But certificates are not used solely for SSL.

Beyond the reason in RFC 2986 that Jonathan Gray already cited, consider the fact that a certificate does more than associate a distinguished name and a public key. It also associates extra information (such as a human name and address). If Eve can get a CA to sign a certificate containing (Eve's public key, DN=acme.com, CN=“Kitten Killers, Inc.”), then the CA is lending legitimacy to stating that acme.com is “Kitten killers Inc.”. Since a CSR has to be signed, only the entity that can get a certificate for acme.com in the first place can pick the common name that it wants to be associated with.

  • Okay. I get that. But isn't that exactly what RFC2986 warns about? – StackzOfZtuff Dec 27 '15 at 13:19
  • @StackzOfZtuff No, the thing in RFC2986 is about having the CA validate the association between Eve's public key and acme.com without proof. It's related, of course, but the scenarios where this would come into play are a bit different — normally, when you rely on the association between the DN and the public key, you'd require a proof of possession of the private key, and RFC2986 warns against protocols that don't do this properly. For the association between DN and CN, there's no way to apply extra crypto, so if you rely on that (which is unusual), the CA is the only defense. – Gilles Dec 27 '15 at 13:33
  • I apologize for the late reply but I would like to point out that CAs are solely responsible for ensuring the legitimacy of the information provided in the CSR and for verifying ownership. Ownership of the associated private key is the only thing in a CSR that a CA cannot independently verify. Therefore logically the attack should only be feasible as described in RFC2986. – Jonathan Gray Sep 11 '17 at 23:53
6

I'm sure if you looked hard enough you could find the official explanation:

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.

RFC 2986: PKCS #10: Certification Request Syntax Specification -- Version 1.7

  • Kudos for the link. But I don't get that attack. Or even how that actually is an attack. Can you explain? – StackzOfZtuff Dec 27 '15 at 13:12
  • Thanks for that RFC. I too didnt quite get the part about "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." Why does the attack become significant if the entity (is this the entity that is getting the bogus certificate?)does not know what the message is that is being signed (in this case DN CN email etc)and what is the significance of the "signed part of the message does not identify the signer" is this referring to unsigned CSRs? Thanks – STEMExchanger Dec 27 '15 at 19:07
2

Besides authenticating the request, signing also ensures that the CSR isn't tampered with. This helps ensure that certs with invalid data aren't created and potentially used, either accidentally or maliciously.

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.