Server Fault is a question and answer site for system and network administrators. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

Generating a CSR for a Windows 2008 R2 server and need to ensure that the private key used for the CSR is new.

I have used OpenSSL before to create my own self-signed certs for testing and if I remember correctly, I was able to specify a private key to use.

In IIS Server Certificates, I am never asked to generate nor pick a private key.

So, does generating a CSR on a Windows-based server always create a new private key for it? If not, how do I ensure a new private key is made/used?

share|improve this question
You mean private key? – EEAA Apr 21 '14 at 17:01
Yes, thanks, editing now. I'm a developer before a sysadmin, so primary key just came out of my head first. :) – jzimmerman2011 Apr 21 '14 at 17:01
Generating a CSR, or generating a cert? What, exactly are you doing, and how are you doing it? (It makes a difference.) – HopelessN00b Apr 21 '14 at 17:22
I am generating a CSR that will be given to a CA to create the cert. This is being done through IIS and it's Server Certificates interface. – jzimmerman2011 Apr 21 '14 at 17:37
up vote 8 down vote accepted


The "Create Certificate Request" Wizard automatically generates a new key pair.

In IIS Server Certificates, I am never asked to generate nor pick a private key.

This is actually not true - the wizard is just not super obvious about it.

When you've entered the identity information (Common Name, Locality, Organization etc.) and hit "Next", the second screen asks for 2 things:

  1. A Cryptographic Service Provider (CSP)
  2. A Bit-length

enter image description here

Choosing the default CSP - the Microsoft RSA SChannel CSP - and a Bit Length of 2048 would be the Windows equivalent to:

openssl req -new -newkey rsa:2048

Anatomy of a Signing Request

The CSR itself can be thought of as having 3 "parts":

  1. Identity information in clear text (CN, Locality, Org. etc.)
    • This is simply strings, the signatory (the CA) can alter those at will
  2. The Public Key
    • You'll need the corresponding private key on your server
  3. Optional extension fields
    • Still just clear text information

The Issuer reviews the information in the signing request, an may alter the contents of both (1) and (3).
The Issuer then uses it's CA private key to encrypt the requesters public key (2).

When the final Certificate is issued it contains:

  1. Identity information in clear text (CN, Locality, Org. etc.)
    • Now with Issuer information added
  2. The Public Key
    • Still the same as above
  3. Optional extension fields
    • Now maybe with Issuer extension fields
  4. A Signature blob
    • This is the Public key signed with the CA's private key

Now, the next time a client get's your certificate presented, it can use the Issuer CA's public key to decrypt the signature blob (4) and compare it to the public key in the certificate

share|improve this answer
Thank you for this great explanation! – Oliver Oct 15 '15 at 11:31

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

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