Tengo que crear una CSR para un certificado SSL comodín. Algunas preguntas frecuentes de los proveedores de SSL dicen que debo generar el archivo CSR en la máquina donde quiero instalar el certificado. Tengo entendido que no debería importar dónde genero la CSR o el archivo de clave siempre que mueva los archivos a la ubicación correcta más adelante.
Entonces mi pregunta es: ¿Importa dónde se generan la CSR y los archivos clave para la certificación SSL?
Respuestas:
Su comprensión es correcta. Todas las demás cosas son iguales, no importa; Pero hay arrugas.
Una ventaja de generarlos en el servidor en cuestión es que minimiza la posibilidad de que la clave se vea comprometida en tránsito. Siempre que use una máquina segura para generarlos y un método seguro (inmune a los ataques MITM) para moverlos al servidor, escapará de eso. No olvide borrarlos de forma segura en el sistema de generación, a menos que tenga la intención deliberada de conservar copias y esté asegurado en consecuencia.
Una ventaja de generar en una máquina separada: generalmente, este será su escritorio. El grupo de entropía en una máquina de escritorio es casi siempre más profundo que en un servidor desatendido, porque el escritorio tiene una gran fuente de aleatoriedad conectada a través de los cables del teclado y el mouse (es decir, ¡usted!). La escasez de entropía puede hacer que la generación de claves tarde mucho tiempo o que se use/dev/urandom salida PRNG, dependiendo de cuán paranoica sea la herramienta de generación, y esto puede conducir a claves más débiles; Las máquinas de escritorio tienden a no tener este problema.
Edición posterior : de acuerdo con una discusión en otro lugar que enlazó aquí, se han planteado dos puntos. En primer lugar, podría optar por una casa a mitad de camino generando la entropía en su escritorio con dd if=/dev/random bs=1k count=10 of=/tmp/entropy.dat, por ejemplo , copiando eso en el servidor remoto y alimentándolo en su proceso de generación de claves directamente o profundizando el grupo de entropía del servidor remoto. Todavía no he encontrado una manera de hacer lo primero, y hacer lo segundo generalmente requiere ejercer un privilegio que, si el canal entre usted y el servidor remoto no es seguro, que es el punto de toda la objeción, también es inseguro.
En segundo lugar, el estimado mjg59 plantea el problema de los módulos de seguridad de hardware, es decir, los dispositivos en los que se colocan, o dentro de los cuales se crean, las claves privadas, y que luego realizan operaciones clave sin soltar la clave. Ese es un punto excelente, pero fuera del alcance de esta pregunta.
Pero el resultado más general del hilo, que debe tener un modelo de amenaza preciso y elegir sus respuestas de manera adecuada, es bueno. Mi modelo de amenaza es que mis canales de comunicación son seguros pero mis puntos finales están bajo ataque inteligente. Eso significa que generaré pares de claves SSL de gran potencia local y los distribuiré. Si resulta que mi modelo es incorrecto y mis comunicaciones resultan vulnerables, sabré de inmediato que todos mis pares de claves SSL están comprometidos. Si su modelo de amenaza es diferente, debe adaptar sus prácticas en consecuencia.
De alguna manera importa.
Si los genera en otra máquina, las claves son vulnerables en la máquina generadora y luego en el servidor. Si utiliza una máquina infectada para generarlos, algunos virii pueden robar las claves, incluso antes de que se trasladen al servidor seguro.
Si los genera en un servidor seguro y simplemente mueve el CSR / cert, las posibilidades de que alguien / algo obtenga la clave privada es menor que en el primer caso, ya que la clave privada se encuentra solo en una máquina.