¿Es cierto que los certificados solicitados con una CSR específica solo se pueden usar en la máquina donde se generó la CSR?

No, no es cierto.

La CSR define varios parámetros para el certificado que está solicitando, como el nombre común, cualquier nombre alternativo, etc. Sin embargo, la CSR es, en última instancia, solo un archivo, y puede hacer todas las cosas de archivo habituales con él - como copiarlo o moverlo a otro servidor, si lo desea.

No es que se requiera mucho. Todo lo que necesita es el certificado SSL que recibe en respuesta a su CSR (muchas veces con un archivo de clave y / o una "cadena de certificados"). Y puede ponerlo en tantas máquinas como desee, incluso si ninguna de ellas hubiera visto el CSR en primer lugar, y mucho menos las máquinas originarias para ello.

Caso en cuestión: administro un grupo de 5 servidores de correo electrónico (que pronto quedarán en desuso), otro grupo de 9 servidores de correo electrónico (que pronto serán reemplazados por el primero), un par de balanceadores de carga BigIp, un grupo de 5 servidores web y más, y los más de 20 utilizan exactamente los mismos archivos de certificado, clave y cadena, pero no el CSR (diablos, los equilibradores de carga ni siquiera tienen una opción en su GUI para subir el CSR en absoluto!). ¿El CSR que se utilizó para obtener este certificado en primer lugar? La máquina que lo generó se retiró hace un tiempo, llevándose consigo la única copia de la CSR.

Sin embargo, lo que no puede hacer (bueno, no sin causar errores) es usar su certificado en un dominio diferente al que se menciona en el certificado; p.ej. Si tiene un certificado para example.com, con un nombre alternativo de example.net, no puede usarlo en example.org. (Bueno, técnicamente usted podría , pero obtendría errores de "certificado no válido" cada vez que lo visite.) Tampoco pudo usarlo en sub.example.com. Sin embargo, esto no tiene nada que ver con la CSR, excepto que es donde se ponen esos nombres en primer lugar.

No necesita la CSR para utilizar el certificado. Sin embargo, para que una máquina se autentique con este certificado, la máquina también necesita la clave privada que acompaña al certificado.

La clave privada se genera normalmente junto con la CSR. En el escenario más simple, la clave privada es solo un archivo que puede copiar a tantas máquinas como desee, junto con el certificado. (Si usa un módulo de seguridad de hardware (HSM), este paso es más complejo, pero todavía hay formas de hacerlo). Esta es también la razón por la que debe proteger la clave privada del acceso no autorizado, similar a una contraseña.

Como mencionó Kromey, la otra cosa a considerar es el nombre por el cual se emitió el certificado. Debe coincidir con el nombre con el que los usuarios llegarán al servidor:

• En un escenario de equilibrio de carga (cinco servidores idénticos detrás de un equilibrador de carga, todos con el mismo certificado) está bien.
• Lo mismo ocurre si tiene un certificado comodín (como *.example.com ) y todos los nombres de sus servidores coinciden (por ejemplo, www.example.com y mail.example.com ).
• Si su certificado es para www.example.com e intenta usarlo en mail.example.com , los usuarios recibirán una advertencia de falta de coincidencia de nombre de servidor cuando intenten conectarse (algunos productos de software pueden incluso negarse a conectarse por completo).