Certificate Request and Private Keys

Basically, the way that cert works, is that you as the user would make a request on secure link (SSL: Secure Sockets Layer).  The application does a check - is the resource I am connecting to have a good certificate (not damaged)?  OK, good - is the certificate not expired (it does a comparison between today's date and when the cert expires)?  You can view a cert in a browswer when trying to order something online, for example.  I always check to see if the cert is valid and up-to-date.  I know this is a very high-level overview, but should help give you the "lay of the land" so to speak.

What is your level of encryption?  Is it 1024 or 2048 - bit?  Is this a self-signed or is this from Thawte or Verisign?  Just as an FYI, you can create your own cert using JDK..  There are many avenues to get certs from, both commercially and internal to your organization..  Do you have one that is coming up on an expiration?

Are you just trying to learn?  There is way more to learn, than just a couple sentences here.  I know I may not be answering your question - as you are asking some kind of security-specific questions.

Is this domain cert, machine cert?  Is this put into place by a senior-level admin?  You need to be very careful when dealing with security certs, tokens, VPNs, etc.

HTH,

Kent

Not exactly.

A certificate signing request contains the public key already, plus further details (such as the name of the expected recipient, contact details and so forth) and is digitally signed by the private key that matches the public key.

In creating a certificate, the CA copies the public key and other details over from the CSR, adds some additional data (signing authority, possibly a CA cert path, certainly constraints such as "can't sign other certs" and a start and end date, plus their own cert's fingerprint) then digitally signs it with their own private key.

this certificate is then asserted verbatim to clients - who use the public key within to encode their data, which you then use the private key to decrypt.

Thanks for the replies everyone.

My problem is that I am not understanding the technical details of the CSR process. I konw what a CSR is and what is it used for.

Here are my questions.
1) What is a password needed to create a CSR?
2) When you purchase a Certificate from Verisign for example this is your public key correct? Where and how does the private key get generated.
3) What is the difference in the various certificate file formats: .CRT, p12 etc

1) It isn't. most CSRs don't have a password
2a) The certificate is generated from the CSR - if you get the CSR right, so is the certificate
2b) when you generate the CSR you also generate the private key. the private key never leaves the machine it is generated on though (unless you explicitly move it)
3) very little, just different encodings of the same data.
Essentially, there are only three objects - a cert, a private key, and a csr
you can encode each by three different standards - der (which is a binary format), pem (which is basically base64 encoding on the der format) or rsa (pkcs#whatever)
you can also have more than one item in a single file, if the format supports it - for pem, that is just putting them in the same file (literally) but for pkcs, there is a specific format for each type - 7 is one or more certificates, and 12 is basically 7 plus the secret key.

Seriously though, what you need to do is download http://sourceforge.net/projects/xca and play - that can generate CSRs, private keys and certificates, export them in various formats, and act as a CA (so signing a CSR into a cert, or creating a cert already signed by its CA.

you will learn more playing with xca for half an hour or so than an entire bookful of guides :)

oh, and I forgot to add - the *instructions* for xca are at http://xca.sourceforge.net/ :)

Thanks for the reply..

I'm going to check out the links you posted later today!!!

The item that keeps stumping me is the fact that last couple of times I created a CSR the program or app required a password. I always assumed this was used at the private key but from your description it is not..

no, you *can* password protect your CSR - but no CA will insist on this, so a non-passworded PEM or PKCS CSR is perfectly acceptable too.

The secret key is another matter - it is common to protect that (in standalone systems, less so for things like web browsers or windows) with a passphrase, but that has little to do with CSRs. for OpenSSL (for instance) it will prompt for a password, but that is for local protection of the private key and not the CSR itself.

In either case, the private key never leaves the machine that creates it - the CSR does not contain the private key.

Still having a hard time understanding how the private key is generated in relation to the csr...

I did download the tool you suggested and checking it out now..