Ssl – Does generating a CSR through IIS 7.5 on Windows Server 2008 R2 always create a new private key

csriis-7.5private-keysslwindows-server-2008-r2

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?

Best Answer

Yes

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

Related Topic