Técnicamente, no hay nada que le prohíba utilizar un certificado para múltiples propósitos. Un cliente implementado correctamente debe verificar el uso de la clave del certificado y los valores de la extensión de las restricciones básicas para determinar si se permite su uso para el propósito para el que se presenta, pero ciertamente se puede crear un certificado para cumplir dos propósitos.
Dicho esto, deberías hacer esto? Casi absolutamente no. Cuando tiene dos sistemas con requisitos de seguridad muy diferentes como estos, no es solo una cuestión de "si uno está comprometido, ambos lo están", sino también que el sistema que necesita la mayor seguridad está expuesto a las vulnerabilidades del sistema que requiere. La protección más débil. Por lo tanto, tiene que desperdiciar recursos protegiendo el sistema más débil más allá de sus requisitos, o exponiendo innecesariamente el sistema que requiere mayor seguridad y aceptando riesgos innecesarios.
Un ejemplo: tome una CA que use su certificado de CA raíz como su certificado de servidor web. Si fueran susceptibles a Heartbleed, no solo tendrían que lidiar con la revocación y la reemisión de un certificado de servidor, una mera molestia, sino que su clave privada de certificado de raíz extremadamente valiosa habría sido expuesta, y potencialmente utilizada para crear estragos que podrían ser verdaderamente desastrosos.
Entonces, cuando tiene sistemas con requisitos de seguridad ampliamente dispares, no comparte certificados (o limita la infraestructura de manera crítica) entre ellos.