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?

  • 1
    You mean private key?
    – EEAA
    Apr 21, 2014 at 17:01
  • 1
    Yes, thanks, editing now. I'm a developer before a sysadmin, so primary key just came out of my head first. :) Apr 21, 2014 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.) Apr 21, 2014 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. Apr 21, 2014 at 17:37

1 Answer 1



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


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.