Esto es probablemente mejor en serverfault, pero voy a intentarlo aquí.
No hay mayor riesgo de seguridad para el certificado SSL en sí mismo simplemente porque usted coloca el certificado SSL en el equilibrador de carga, suponiendo que el equilibrador de carga está configurado correctamente y no va a servir la clave privada. Este riesgo existe en cualquier servidor, equilibrador de carga o no, un nuevo compromiso o ataque de SO podría, aunque es poco probable, permitir que eso suceda.
Sin embargo, dependiendo de cómo lo haga, el tráfico detrás del equilibrador de carga podría enviarse sin cifrar, si el equilibrador de carga solo habla HTTP a los servidores de contenido. Por lo tanto, debe configurar las conexiones reenviadas para que también usen HTTPS, ya sea mediante certificados internos y su propia CA, o instalando el certificado HTTPS de cara externa en los servidores de contenido (y deberá hacerlo si lo que busca es Cumplimiento PCI).
Recuerde que también existe un riesgo de carga, el cifrado es costoso y al colocar el certificado en el equilibrador de carga aumenta, por ejemplo, la carga. Si el equilibrador de carga ya está sobrecargado, esta puede ser la gota final. Si observa muchas transacciones, tiende a ver un dispositivo SSL de hardware instalado antes del equilibrador de carga que se encarga del tráfico SSL, luego habla HTTP al equilibrador de carga, que habla HTTP a los servidores de contenido. (De nuevo, esto tiene que ser HTTPS si usted está apuntando para el cumplimiento de PCI)
parece una pregunta de error del servidor, pero buena respuesta de todos modos, merece un +1 en el imho – serg10