En teoría, siempre que un sistema fuera lo suficientemente seguro y que solo firmara la CSR en un servidor separado, manteniendo la clave maldita segura, no habría ningún problema con esto.

Sin embargo,

• ¿Qué sucede en caso de que usted haga de alguna manera tenga comprometida esa clave privada?
• ¿Cuál es su plan en caso de incumplimiento?
• ¿Tendrá esa clave privada para su certificado TLS en el mismo servidor que el servidor de firma ?

Pregúntese: ¿hay algún beneficio al usar la misma clave para más de 1000 dominios? ¿Puede explicar el único punto de falla a sus clientes?

Además, RSA (al menos) no tiene ningún ataque conocido actualmente sobre el uso de firmas repetidas que revelaría la clave. Ese es reservado para DSA con un PRNG poco fiable.

Aún así, es una mala idea.

Actualizar

El sistema que desea en este caso sería el siguiente:

1. Cada cliente es encarcelado (a través de chroot() ) en su propio directorio en el servidor
2. Para cada CSR generado, se genera una clave privada en la cárcel del usuario, pero fuera de webroot.
   • por ejemplo /jail/customername/private/server.key
   • /jail/customername/domains/<domain>/subdomains/<subdomain>/public
   • /jail/customername/domains/<domain>/public
   • /jail/a/domains/a.com/public/ , etc.
3. El servidor web debe respetar las cárceles, y los lenguajes de script deben ejecutarse como un usuario que no puede acceder a la carpeta privada en la cárcel de todos los usuarios.

No habría ningún problema con este sistema; Supongo que está ejecutando un sistema host compartido y que desea una manera fácil de generar un CSR para que cada cliente habilite TLS.

De esta manera, tiene una separación correcta y forzada de privilegios para cada cliente y en el caso de que un cliente se vea comprometido (salvo cualquier explotación local de privilegios), el resto de su infraestructura es sólida y puede revocar el certificado TLS. el usuario que fue explotado.

No hay peligro en crear una gran cantidad de CSR para la misma clave privada, aparte de la reutilización de la propia clave privada.

Una CSR contiene:

• información de solicitud de certificado (asunto, etc.)
• la clave pública
• una firma de lo anterior, usando la clave privada

Hasta donde sé, nunca ha habido un caso en el que la firma repetida con una clave privada haya degradado la seguridad de la clave privada. Si hubiera, todos estaríamos en problemas.

Sin embargo . Reutilizar la misma clave privada para muchos dominios es una idea terrible. Debe generar una nueva clave privada para cada CSR que genere. ¡Tan pronto como empieces a hacer esto, podría haber algún problema! Un atacante podría generar muchas claves privadas y esto, a su vez, reduciría la entropía disponible en su sistema, lo que (hipotéticamente) hace que las claves privadas sean más predecibles.

Originalmente escribí un comentario con dos posibles problemas antes, y luego me di cuenta de que puede haber uno aún más grande que justifique una respuesta.

Supongamos que existe una vulnerabilidad de día cero (hasta ahora, hipotética) en el servidor web, sistema operativo o en algún otro lugar que permita el acceso de una aplicación PHP a la clave privada. Normalmente, esto solo sería explotable insertando un archivo PHP malicioso. Sería una vulnerabilidad grave, pero solo puede ser explotada de forma remota a través de otras vulnerabilidades que permitan la carga no autorizada de un script PHP.

Si comparte la clave privada, dicha vulnerabilidad se volvería catastrófica. Todo lo que un atacante tendría que hacer es registrarse para obtener una cuenta contigo, cargar la vulnerabilidad de PHP e instantáneamente tendría la clave privada de miles de otros sitios web.

De manera similar, en su escenario, algo como Heartbleed no solo comprometería un sitio, sino que revelaría la clave privada para todos sus clientes a la vez, haciendo que este ya grave problema sea completamente catastrófico.