La génération d'une CSR via IIS 7.5 sur Windows Server 2008 R2 crée-t-elle toujours une nouvelle clé privée?

11

Génération d'une CSR pour un serveur Windows 2008 R2 et besoin de s'assurer que la clé privée utilisée pour la CSR est nouvelle.

J'ai déjà utilisé OpenSSL pour créer mes propres certificats auto-signés pour les tests et si je me souviens bien, j'ai pu spécifier une clé privée à utiliser.

Dans les certificats de serveur IIS, on ne me demande jamais de générer ou de choisir une clé privée.

Ainsi, la génération d'une CSR sur un serveur Windows crée-t-elle toujours une nouvelle clé privée pour elle? Sinon, comment puis-je m'assurer qu'une nouvelle clé privée est créée / utilisée?

jzimmerman2011
la source
1
Vous voulez dire une clé privée ?
EEAA
1
Oui, merci, éditez maintenant. Je suis développeur avant un administrateur système, donc la clé primaire vient de sortir de ma tête en premier. :)
jzimmerman2011
Générer un CSR, ou générer un cert? Que faites-vous exactement et comment le faites-vous? (Cela fait une différence.)
HopelessN00b
Je génère un CSR qui sera remis à une CA pour créer le certificat. Cela se fait via IIS et son interface Server Certificates.
jzimmerman2011

Réponses:

8

Oui

L'assistant "Créer une demande de certificat" génère automatiquement une nouvelle paire de clés.

Dans les certificats de serveur IIS, on ne me demande jamais de générer ou de choisir une clé privée.

Ce n'est en fait pas vrai - l'assistant n'est tout simplement pas super évident à ce sujet.

Lorsque vous avez entré les informations d'identité (nom commun, localité, organisation, etc.) et appuyez sur "Suivant", le deuxième écran demande 2 choses:

  1. Un fournisseur de services cryptographiques (CSP)
  2. Une longueur de bit

entrez la description de l'image ici

Choisir le CSP par défaut - le CSP SChannel de Microsoft RSA - et une longueur de bits de 2048 serait l'équivalent de Windows pour:

openssl req -new -newkey rsa:2048

Anatomie d'une demande de signature

La RSE elle-même peut être considérée comme ayant 3 "parties":

  1. Informations d'identité en texte clair (CN, localité, organisation, etc.)
    • Il s'agit simplement de chaînes, le signataire (l'AC) peut modifier celles qui le souhaitent
  2. La clé publique
    • Vous aurez besoin de la clé privée correspondante sur votre serveur
  3. Champs d'extension facultatifs
    • Toujours des informations en texte clair

L'émetteur examine les informations contenues dans la demande de signature et peut modifier le contenu des points (1) et (3).
L'émetteur utilise ensuite sa clé privée CA pour chiffrer la clé publique du demandeur (2).

Lorsque le certificat final est délivré, il contient:

  1. Informations d'identité en texte clair (CN, localité, organisation, etc.)
    • Maintenant, avec les informations sur l'émetteur ajoutées
  2. La clé publique
    • Toujours les mêmes que ci-dessus
  3. Champs d'extension facultatifs
    • Maintenant peut-être avec les champs d'extension de l'émetteur
  4. Un blob Signature
    • Il s'agit de la clé publique signée avec la clé privée de l'autorité de certification

Maintenant, la prochaine fois qu'un client recevra votre certificat, il pourra utiliser la clé publique de l'autorité de certification de l'émetteur pour déchiffrer le blob de signature (4) et le comparer à la clé publique du certificat.

Mathias R. Jessen
la source