Tecnicamente, non vi è nulla che vieta di utilizzare un certificato per più scopi. Un client correttamente implementato dovrebbe verificare i valori dell'estensione dei vincoli di base sull'utilizzo della chiave e dei vincoli del certificato per determinare se è consentito utilizzarlo per lo scopo per il quale viene presentato, ma è certamente possibile creare un certificato per due scopi.
Detto questo, dovrebbe farlo? Quasi assolutamente no. Quando si hanno due sistemi con requisiti di sicurezza molto diversi come questi, non è solo una questione di "se uno è compromesso, lo sono entrambi" ma anche che il sistema che ha bisogno della massima sicurezza è esposto alle vulnerabilità del sistema che richiede la protezione più debole. Quindi, devi sprecare risorse per proteggere il sistema più debole oltre i suoi requisiti, o esporre inutilmente il sistema che richiede maggiore sicurezza e accettare rischi inutili.
Un esempio: prendi una CA che utilizza il certificato CA radice come certificato per il server web. Se fossero sensibili a Heartbleed, non solo avrebbero dovuto gestire la revoca e il ri-rilascio di un certificato di server, una semplice seccatura, ma la preziosissima chiave privata di root cert sarebbe stata esposta, e potenzialmente utilizzata per creare un'ampia diffusione devastazione che potrebbe essere veramente disastrosa.
Quindi, quando si dispone di sistemi con requisiti di sicurezza molto disparati, non condivide i certificati (o l'infrastruttura che limita in modo critico) tra di essi.