Je dois créer un CSR pour un certificat SSL générique. Certaines FAQ des fournisseurs SSL disent que je dois générer le fichier CSR sur la machine où je veux installer le certificat? Ma compréhension est que peu importe où je génère la CSR ou le fichier de clé tant que je déplace les fichiers au bon endroit plus tard.
Ma question est donc la suivante: où est généré le CSR et les fichiers clés pour la certification SSL?
Réponses:
Votre compréhension est correcte. Toutes choses étant égales par ailleurs, peu importe; mais il y a des rides.
Un avantage à les générer sur le serveur en question est de minimiser les risques de compromission de la clé en transit. Tant que vous utilisez une machine sécurisée pour les générer et une méthode sécurisée (immunisée contre les attaques MITM) pour les déplacer vers le serveur, vous y échapperez. N'oubliez pas de les effacer en toute sécurité sur le système de génération, à moins que vous n'ayez intentionnellement l'intention de conserver des copies, et que vous soyez sécurisé en conséquence.
Un avantage à générer sur une machine distincte: généralement, ce sera votre bureau. Le pool d'entropie sur une machine de bureau est presque toujours plus profond que sur un serveur sans surveillance, car le bureau a une grande source d'aléatoire connectée via les câbles du clavier et de la souris (c'est-à-dire vous!). La pénurie d'entropie peut entraîner une longue période de génération de clés, ou la faire utiliser à /dev/urandomla place une sortie PRNG, selon la paranoïaque de l'outil de génération, ce qui peut conduire à des clés plus faibles; les ordinateurs de bureau n'ont généralement pas ce problème.
Édition ultérieure : suite à une discussion ailleurs reliée ici, deux points ont été soulevés. Tout d' abord, vous pouvez opter pour une maison à mi-chemin en générant l' entropie sur votre bureau avec par exemple dd if=/dev/random bs=1k count=10 of=/tmp/entropy.dat, la copie que sur le serveur distant, et l' alimentation à votre processus de génération de clés soit directement , soit par l' approfondissement de l' entropie du bassin serveur distant. Je n'ai pas encore trouvé de moyen de faire le premier, et faire le second nécessite généralement d'exercer des privilèges qui - si le canal entre vous et le serveur distant n'est pas sécurisé, ce qui est plutôt le point de l'objection entière - est également peu sûr.
Deuxièmement, l'estimable mjg59 pose le problème des modules de sécurité matérielle - c'est-à-dire des périphériques dans lesquels vous placez ou à l'intérieur desquels vous créez des clés privées, et qui effectuent ensuite des opérations de clé sans jamais laisser la clé sortir. C'est un excellent point, mais en dehors de la portée de cette question.
Mais le résultat plus général du fil - que vous devez avoir un modèle de menace précis et choisir vos réponses de manière appropriée - est bon. Mon modèle de menace est que mes canaux de communication sont sécurisés mais mes points finaux sont sous attaque intelligente. Cela signifie que je vais générer localement des paires de clés SSL à forte entropie et les distribuer. S'il s'avère que mon modèle est inexact et que mes communications se révèlent vulnérables, je saurai immédiatement que toutes mes paires de clés SSL sont compromises. Si votre modèle de menace est différent, vous devez adapter vos pratiques en conséquence.
Cela compte un peu.
Si vous les générez sur une autre machine, les clés sont vulnérables sur la machine génératrice, puis sur le serveur. Si vous utilisez une machine infectée pour les générer, certains virus peuvent voler les clés, avant même qu'elles ne soient déplacées vers le serveur sécurisé.
Si vous les générez sur un serveur sécurisé et déplacez simplement le CSR / cert, les chances que quelqu'un / quelque chose obtienne la clé privée sont plus petites que dans le premier cas, car la clé privée se trouve uniquement sur une machine.