È una delle domande più ricorrenti — e più controverse — tra chi gestisce Active Directory da anni: si può installare il ruolo Certification Authority direttamente su un domain controller? La risposta tecnica è sì, Microsoft lo supporta e Active Directory Certificate Services (AD CS) si integra perfettamente con un DC: template dei certificati, auto-enrollment e pubblicazione funzionano senza intoppi. Ma “supportato” non significa “consigliato”, e la differenza tra le due cose è esattamente il punto su cui vale la pena soffermarsi, perché tocca il cuore della progettazione di una PKI aziendale.

Perché viene fatto comunque (e quando ha senso)

Nella pratica, combinare CA e DC sullo stesso server capita più spesso di quanto si pensi, soprattutto in contesti con risorse limitate:

• piccole aziende con uno o due domain controller in totale;
• filiali remote con hardware e budget contenuti;
• ambienti di laboratorio o di test;
• scenari dove il certificato serve solo per usi interni (autenticazione LDAPS, smart card, qualche servizio intranet) senza requisiti di compliance stringenti.

In questi casi, la strettissima integrazione con Active Directory semplifica davvero il deployment iniziale e riduce il carico amministrativo: non c’è un server aggiuntivo da patchare, monitorare e proteggere separatamente. Dal punto di vista del semplice funzionamento tecnico, non c’è nulla che impedisca questa configurazione.

Il problema: concentrare il rischio in un unico punto

Il motivo per cui la maggior parte delle linee guida di hardening sconsiglia questa combinazione non è un dettaglio tecnico, ma un principio di progettazione della sicurezza: un domain controller compromesso che è anche una CA espone contemporaneamente le credenziali di dominio, l’autenticazione di tutto il dominio, le chiavi private della CA e i diritti di emissione e revoca dei certificati. Un singolo attaccante che ottiene accesso privilegiato a quella macchina ottiene tutto in un colpo.

Ci sono poi due conseguenze meno ovvie, ma altrettanto importanti:

Il contenimento diventa più difficile

Ricostruire il domain controller da zero dopo un incidente non “ripristina la fiducia” nei certificati già emessi da quella CA: quei certificati restano validi (o da revocare uno per uno) indipendentemente da cosa succede al DC. Viceversa, ripristinare la CA da un backup non dimostra affatto che la directory sia ancora integra e non compromessa. Sono due problemi di fiducia distinti che, se il ruolo è unico, si trovano intrecciati nello stesso incidente di sicurezza.

Il recovery diventa accoppiato

Se la CA fallisce proprio durante la ricostruzione di un DC (o viceversa), si rischia di bloccare contemporaneamente la revoca urgente di certificati compromessi, il rinnovo e l’enrollment — con impatti diretti su VPN, Wi-Fi aziendale, autenticazione tramite smart card, certificati dei dispositivi e servizi TLS interni. In un’emergenza, avere due sistemi critici che devono essere ripristinati insieme nell’ordine giusto è l’ultima cosa che si vuole gestire sotto pressione.

L’architettura PKI che scala davvero: la gerarchia a due livelli

Il design che la maggior parte delle organizzazioni di dimensioni medio-grandi dovrebbe adottare è la classica gerarchia PKI a due livelli, pensata esattamente per separare i ruoli e isolare il rischio:

• Root CA offline: non è mai joinata al dominio, viene accesa solo quando serve (tipicamente per emettere o rinnovare i certificati delle CA subordinate e pubblicare le CRL), e l’accesso fisico e logico è estremamente ristretto. È, di fatto, l’ancora di fiducia di tutta la PKI, e per questo resta isolata dal resto dell’infrastruttura.
• Issuing CA aziendale: normalmente un member server joinato al dominio ma non un domain controller. Si occupa dell’enrollment quotidiano, pubblica i certificati, supporta l’auto-enrollment e si integra con AD per i template — ma senza condividere il ruolo con l’autenticazione del dominio.

Su scala enterprise, a questo si aggiungono storage delle chiavi protetto dove opportuno (HSM o equivalente), ruoli amministrativi distinti tra chi gestisce AD e chi gestisce la PKI, e procedure testate — non solo scritte su un documento — per revoca, sostituzione delle chiavi e disaster recovery.

Come scegliere in base alla dimensione dell’organizzazione

Non esiste una risposta universale: la scelta corretta dipende dal contesto, e la linea guida pratica è questa:

• Piccole organizzazioni: combinare CA e DC può essere un compromesso accettabile, a condizione che sia una scelta consapevole e non un effetto collaterale della pigrizia. Serve comunque: backup separati e testati del database della CA e della chiave privata, location di revoca (CRL/AIA) effettivamente raggiungibili, e una sequenza di recovery documentata e provata almeno una volta.
• Organizzazioni di medie dimensioni: è il momento di passare a una issuing CA dedicata quando i certificati iniziano a supportare VPN, Wi-Fi, Network Policy Server (NPS) o autenticazione dei dispositivi, quando il volume di auto-enrollment cresce, o quando PKI e Active Directory devono poter essere ripristinati in modo indipendente l’uno dall’altro.
• Grandi organizzazioni: qui la separazione dei ruoli non è un “nice to have” ma un requisito di fiducia e resilienza. Un’architettura PKI realmente separata (root offline + issuing CA dedicata, eventualmente più issuing CA per region o per business unit) è lo standard de facto.

Checklist operativa: cosa fare se le cose vanno male

Chi si trova a gestire un ambiente con CA e DC combinati — per scelta o per eredità — dovrebbe avere già pronte due procedure di emergenza.

CA fallita su un domain controller

1. Preservare il sistema guasto e tutti i backup disponibili, senza sovrascrivere nulla prematuramente.
2. Confermare che un altro DC stia fornendo correttamente AD DS e DNS, per non trovarsi anche senza directory funzionante durante il recovery.
3. Ripristinare la CA solo da backup verificati come integri.
4. Verificare che le location AIA e CRL siano effettivamente raggiungibili dai client.
5. Pubblicare dati di revoca aggiornati, se necessario.
6. Testare enrollment e validazione dei certificati prima di dichiarare chiuso l’incidente.

Sospetto compromesso della chiave della issuing CA

1. Fermare immediatamente l’emissione di nuovi certificati.
2. Preservare le evidenze per l’analisi forense.
3. Sostituire il certificato e la chiave della CA emittente.
4. Identificare e revocare i certificati fraudolenti o potenzialmente compromessi.
5. Pubblicare informazioni di revoca aggiornate.
6. Rilasciare nuovi certificati a utenti, dispositivi e servizi impattati.

Un dettaglio spesso sottovalutato: i certificati dei domain controller

Indipendentemente da dove risiede la CA, i certificati emessi per i domain controller devono soddisfare requisiti precisi: supportare sia l’autenticazione server che quella client, includere il nome DNS corretto del DC, avere i key usage adeguati e fare riferimento a una location CRL effettivamente raggiungibile dai client che devono validarli. I requisiti esatti del template variano in base ai servizi coinvolti — LDAPS e sign-in tramite smart card, in particolare, hanno esigenze specifiche che vanno verificate caso per caso.

Cosa fare se si eredita un ambiente con CA e DC già combinati

Non è necessario smontare tutto in un weekend. Microsoft supporta la migrazione di una CA che preserva database, certificati, configurazione e chiavi private, quindi il percorso corretto è trattarla come un vero e proprio progetto PKI pianificato — valutando criticità del business, obblighi di compliance, piani di espansione dei certificati e il livello di rischio accettabile — magari approfittando di un refresh hardware già previsto per farlo con il minimo impatto operativo.

Conclusione

La domanda “posso installare la CA sul domain controller?” ha una risposta tecnica semplice (sì) e una risposta di design molto più sfumata (dipende, ma per la maggior parte delle organizzazioni in crescita la risposta pratica è no). Il punto da ricordare è che la supportabilità di Microsoft non equivale a una buona architettura: è una scelta che concentra rischio, complica il contenimento degli incidenti e accoppia il recovery di due sistemi critici che, idealmente, dovrebbero poter fallire e essere ripristinati in modo indipendente. Per un laboratorio o una microazienda può essere un compromesso ragionevole, purché documentato; per tutto il resto, una issuing CA dedicata, separata dai domain controller, resta la base di una PKI che tiene quando serve davvero.

Fonte: Petri IT Knowledgebase – Should You Install Certificate Authority on a Domain Controller?