How and in what context CSR works?

Question

I'm trying to understand scenario under which CSR (certificate signing request) can be useful. Please help me understand the concept and use.

Mutual authentication

In client side authentication, where a client generates a CSR to be signed by server trusted root CA. The result be a client public certificate, which can be used by server to authenticate client by encrypting its session key using client public key.

MITM i.e SSL proxy

The goal, it to view all outbound SSL traffic going to external resources e.g twitter , facebook etc. Have the SSL-appliance on-board CA authority generate public-private key pair, generate CSR request and have it signed by a trusted root authority e.g verisign. So, when client request to access a ssl website, the ssl proxy passes the SSL proxy server certificate which be accepted by user local browser since its signed by local CA, From SSL to target server, we will use CSR approved public certificate to encrypt session key for use by target sever.

I know the above description just describe a very vague high level overview of the process. I just wanted to understand the high level concept involved.

Answer 1

A CSR allows a user to get a certificate authority (CA) to give them a signed certificate, without the CA actually knowing the user's private key. An X.509 cert has a few major pieces: the subject (who the cert is for), the cert's validity period, the cert's allowed uses, the subject's public key, and the issuer's signature (that is, a signature generated using the issue's private key, where the issuer is generally a CA). A CSR has most of that info, except it lacks the issuer cert (because it's generated by the user - who is usually the subject - and sent to the issuer, so it can't have the issuer's signature on it yet). The CA signs the CSR, turning it from a certificate signing request into a signed certificate.

The neat thing is, in order to do this, the issuer never has to see the subject's private key, just the public one (which is, of course, public). The user needs to have a corresponding private key for the public key they submit, or they wouldn't be able to use the returned certificate for anything, but the issuer (that is to say, the CA) doesn't have to know what that private key is.

This is a better alternative to the simple, naïve approach, which would be the issuer generating the public-private key pair themselves, then building a cert with that public key, signing it, and sending both the cert and the private key to the user. The problems with doing that:

• The CA would know your private key, at least until they forgot/erased it. Ideally, nobody else should ever know your private key.
• The private key would need to be transmitted very securely (so that a third party couldn't intercept it); this is hard. Better to just never transmit it at all.
• The user may want to generate the key a particular way, for example using a random number generator that they trust to be particularly good, rather than relying on the CA to produce an acceptable quality of key. (You have to expect that others will trust the CA's master key - otherwise their signature on your cert is meaningless - but you shouldn't have to trust them to actually generate your key properly.)
• The user may want to re-use an existing public key, for example to keep old signatures valid if an existing certificate would expire but the key is believed to still be safe. Using a CSR, you can basically get a certificate re-issued with new validity period, allowed uses (OIDs), etc. even if you don't update the key.

CSRs are what make it possible to avoid all of these problems.

Answer 2

A certificate signing request is the precursor of a CA signed certificate. Thus a CSR is needed wherever CA issued certificates are used: server authentication, client authentication, creation of a sub-CA, signing mails with S/MIME, signed applications ...