Migrare Enterprise Root CA da SHA‑1 a SHA‑256 in AD CS

Hai una Enterprise Root CA online ancora firmata con SHA‑1 e vuoi passare a SHA‑256 senza interruzioni? Questa guida pratica spiega se è possibile e come eseguire la migrazione in sicurezza in ambienti Active Directory Certificate Services, con checklist, comandi, test e piano di rollback.

Indice

Contesto e obiettivo

In molte infrastrutture PKI di Active Directory Certificate Services (AD CS) sopravvivono ancora autorità di certificazione radice aziendali firmate con SHA‑1. L’algoritmo è considerato debole e ormai deprecato dalla maggior parte dei sistemi moderni. La buona notizia: è possibile passare a SHA‑256 mantenendo la stessa chiave privata della CA tramite un rinnovo con same key. Il risultato è una nuova versione del certificato radice firmata con SHA‑256, mentre la chiave della CA rimane invariata. Da quel momento, tutti i certificati emessi adottano il nuovo algoritmo di firma.

Prerequisiti e campo di applicazione

AD CS installato come Enterprise Root CA online.
Accesso amministrativo al server CA e al dominio.
Versioni di sistema e applicazioni client che supportano SHA‑256 (praticamente tutti i sistemi moderni; indagare eventuali componenti legacy).
Finestra di manutenzione con possibilità di riavviare temporaneamente il servizio certsvc.
Spazio sicuro per i backup della CA e delle chiavi.

Nota operativa: in architetture PKI ideali la radice è offline. Se la tua radice è online per ragioni storiche, la migrazione a SHA‑256 è comunque possibile ma richiede disciplina operativa nell’hardening del server CA.

Cosa cambia e cosa non cambia

Cambia l’algoritmo di hash usato per firmare il certificato della CA e i certificati emessi in seguito: si passa da SHA‑1 a SHA‑256.
Non cambia la chiave privata della CA se scegli il rinnovo con stessa chiave (same key). L’identità della CA resta la stessa e non devi ricreare template o ridepositare chiavi su HSM.
I certificati già emessi restano validi fino a scadenza o revoca: non vengono rigenerati automaticamente. Puoi pianificarne la sostituzione graduale.

Schema decisionale sintetico

Hai la necessità di rinforzare l’algoritmo di firma ma non vuoi cambiare la CA? Scegli il rinnovo con stessa chiave. Vuoi anche aumentare la lunghezza della chiave o passare a un diverso provider crittografico o a chiavi su HSM non ancora in uso? Valuta il rinnovo con nuova chiave (new key) o la creazione di una nuova gerarchia. In questo articolo ci concentriamo sul percorso con stessa chiave.

Checklist preliminare

Inventaria sistemi, device, applicazioni, agent, gateway, appliance e IoT che consumano certificati emessi dalla CA.
Verifica nel laboratorio o in un gruppo pilota che SHA‑256 sia accettato in tutti i flussi critici: TLS, IPsec, S/MIME, VPN, RADIUS, firma di codice, firma documento.
Conferma la salute del PKI: AIA, CDP, CRL e delta CRL pubblicate e accessibili, archiviazione chiave e registro coerenti, nessun errore in Event Viewer.
Prepara un piano di comunicazione e un piano di rollback.

Verifiche dello stato della PKI

Apri pkiview.msc e assicurati che tutte le voci risultino in stato positivo: Authority Information Access, punti di distribuzione CRL, certificati emessi e catena di fiducia.

Controlla l’algoritmo di firma e il provider della chiave della CA:

certutil -dump &quot;%SYSTEMROOT%\System32\CertSrv\CertEnroll&lt;NomeCA&gt;_&lt;NomeCA&gt;.crt&quot;
certutil -getreg ca\csp

Verifica anche la configurazione di pubblicazione CRL e AIA in certsrv.msc → Proprietà della CA → scheda Estensioni.

Backup completo prima di qualsiasi modifica

Esegui un backup a freddo di database, chiavi e configurazione. Se usi un HSM, includi backup e procedure proprietarie del vendor.

rem Esempio di backup su unità dedicata
mkdir D:\CA-Backup
certutil -backupDB D:\CA-Backup\DB
certutil -backupKey D:\CA-Backup\Key
reg export HKLM\SYSTEM\CurrentControlSet\Services\CertSvc D:\CA-Backup\CA-registry.reg
rem Facoltativo: backup completo con un singolo comando
certutil -backup D:\CA-Backup\Full

Conserva i backup offline in un percorso sicuro, con controllo degli accessi e verifica periodica dei restore.

Impostazione dell’algoritmo di firma predefinito

L’obiettivo è far sì che la CA utilizzi SHA‑256 per tutte le firme future. La chiave può essere gestita da un provider legacy CSP o da un provider moderno CNG KSP. Imposta la chiave di registro corretta e riavvia il servizio.

Scenario con provider CNG

Tipico di chiavi create con Microsoft Software Key Storage Provider o HSM moderni KSP.

rem Eseguire in un prompt con privilegi elevati
certutil -setreg ca\csp\CNGHashAlgorithm SHA256
net stop certsvc
net start certsvc

Scenario con provider CSP legacy

Tipico di chiavi create con provider compatibile CSP di vecchia generazione.

certutil -setreg ca\csp\HashAlgorithm SHA256
net stop certsvc
net start certsvc

Attenzione: non abilitare opzioni come AlternateSignatureAlgorithm a meno di aver testato la piena compatibilità dei client con firme avanzate; il nostro obiettivo è semplicemente passare a SHA‑256 mantenendo PKCS numero uno versione cinque per compatibilità massima.

Rinnovo del certificato della CA con stessa chiave

Una volta impostato l’algoritmo predefinito, occorre rinnovare il certificato della CA. Puoi farlo dalla console grafica o da riga di comando. La modalità consigliata in questo contesto è il rinnovo con la stessa chiave.

Procedura dalla console

Apri Certification Authority sul server CA.
Dal nodo della CA, seleziona All Tasks → Renew CA Certificate.
Quando richiesto, scegli Same key (stessa chiave).
Completa il wizard. Il servizio verrà riavviato e verrà generato il nuovo certificato della CA firmato con SHA‑256.

Procedura da riga di comando

rem Rinnovo del certificato CA riutilizzando la stessa chiave
certutil -renewCert ReuseKeys

In caso di necessità di rigenerare anche la chiave della CA (scenari non coperti da questa guida), useresti l’opzione RenewKey o l’equivalente New key nel wizard, con impatti più ampi sull’infrastruttura.

Distribuzione del nuovo certificato radice

Perché i client si fidino della nuova firma della CA, il nuovo certificato radice deve essere distribuito a tutti i sistemi. In un dominio, usa i criteri di gruppo.

Distribuzione tramite criteri di gruppo

Apri Gestione Criteri di Gruppo.
Modifica un GPO applicato ai computer interessati: Configurazione computer → Impostazioni di Windows → Impostazioni di sicurezza → Criteri chiave pubblica → Autorità di certificazione radice attendibili.
Importa il nuovo certificato radice della CA.
Forza l’aggiornamento con gpupdate /force o attendi la replica.

Pubblicazione in Active Directory

Oltre al GPO, pubblica il certificato e la CRL in AD per i client che usano LDAP come canale di distribuzione.

rem Pubblicazione del certificato radice nella directory
certutil -dspublish -f "C:\Percorso\RootCA-SHA256.cer" RootCA

rem Pubblicazione della CRL
certutil -dspublish -f "C:\Percorso\RootCA.crl"

Distribuzione ai sistemi non in dominio

Per server isolati, dispositivi di rete, appliance o IoT, importa manualmente il certificato nello store di sistema Trusted Root Certification Authorities o nei repository proprietari dei dispositivi.

Test e convalida approfonditi

Prima del rilascio in produzione, valida l’intera catena in un ambiente pilota.

Emissione di prova: rilascia un certificato da un template standard (per esempio server web) e verifica la catena fino alla radice rinnovata.
Verifica della firma del certificato ottenuto: certutil -dump "C:\temp\cert-di-prova.cer"
Verifica catena e CRL: certutil -urlfetch -verify "C:\temp\cert-di-prova.cer"
Test funzionali: handshake TLS su endpoint critici, autenticazioni RADIUS, tunnel VPN, firme S/MIME e verifica lato client.

Procedura operativa riassunta

Fase	Azione	Scopo e note operative
Valutare l’impatto	Verificare il supporto SHA‑256 su sistemi e applicazioni; individuare componenti legacy e pianificare gli upgrade.	Evitare interruzioni quando i nuovi certificati iniziano a circolare.
Controllare lo stato del PKI	Aprire `pkiview.msc` e confermare che AIA, CDP e CRL siano in stato corretto. Verificare log e disponibilità endpoint.	Garantire la salute della CA prima delle modifiche.
Eseguire un backup completo	Backup di database, registro, chiavi e, se presente, configurazione HSM.	Abilitare un rollback rapido e sicuro.
Impostare SHA‑256 predefinito	`certutil -setreg ca\csp\CNGHashAlgorithm SHA256` oppure `certutil -setreg ca\csp\HashAlgorithm SHA256`; riavviare `certsvc`.	Influenza solo le firme future; i certificati esistenti restano invariati.
Rinnovare il certificato della CA	Console → Renew CA Certificate → Same key oppure `certutil -renewCert ReuseKeys`.	Emettere una nuova versione del certificato radice con SHA‑256 mantenendo la chiave corrente.
Distribuire il nuovo certificato radice	GPO su Trusted Root Certification Authorities, pubblicazione in AD e import manuale su sistemi non in dominio.	Assicurare fiducia e validazione della catena su tutti i client.
Test e convalida	Emissione di certificati di prova, verifica catena e CRL, test su applicazioni critiche.	Ridurre il rischio di outage.
Monitoraggio e rollback	Monitorare i log, mantenere i backup e predisporre una procedura di ripristino.	Gestire eventuali regressioni con tempi rapidi.

Approfondimenti su scenari particolari

Presenza di subordinate

Se la tua gerarchia include CA intermedie, la sequenza corretta è:

Rinnovare la radice aziendale con la stessa chiave e SHA‑256.
Rinnovare le subordinate in modo che i loro certificati siano firmati dalla radice rinnovata.
Aggiornare l’archivio dei certificati nei server e nei client per la nuova catena.

Radice offline

Se la radice è offline, l’operazione è simile ma richiede lo spostamento fisico del supporto sicuro contenente la chiave privata e la successiva pubblicazione del nuovo certificato radice e della CRL. Le subordinate andranno poi rinnovate con la nuova firma.

Uso di HSM

Verifica con il vendor se l’aggiornamento dell’algoritmo di firma richiede parametri specifici sul provider KSP o modifiche ai criteri di protezione della chiave. Assicurati che le librerie e i driver dell’HSM siano aggiornati e che i backup delle chiavi siano consistenti.

Ottimizzazioni consigliate

Validità del certificato della CA: valuta, tramite CAPolicy.inf o proprietà della CA, di mantenere un periodo di validità in linea con le policy aziendali e la compliance.
CRL e delta CRL: imposta una frequenza di pubblicazione coerente con le finestre di manutenzione e i requisiti di revoca.
Hardening: limita l’accesso al server CA, rimuovi ruoli non necessari, applica il principio del privilegio minimo.

Esempi di comandi utili

rem Verificare quale valore è impostato per l'hash
certutil -getreg ca\csp\CNGHashAlgorithm
certutil -getreg ca\csp\HashAlgorithm

rem Controllare i certificati CA installati
certutil -store "CA"

rem Verificare la catena per un certificato appena emesso
certutil -urlfetch -verify "C:\temp\server.cer"

rem Forzare la ripubblicazione delle CRL
certutil -crl

Automazione con PowerShell

Puoi automatizzare verifica e rinnovo con uno script semplice. Eseguilo solo dopo aver creato un backup completo.

# Esempio didattico: verifica e rinnovo con stessa chiave
$hashPathCNG = &quot;HKLM:\SYSTEM\CurrentControlSet\Services\CertSvc\Configuration&quot; + (Get-ItemProperty &quot;HKLM:\SYSTEM\CurrentControlSet\Services\CertSvc\Configuration&quot;).Active &quot;\CSP&quot;
try {
    Set-ItemProperty -Path $hashPathCNG -Name CNGHashAlgorithm -Value &quot;SHA256&quot; -ErrorAction Stop
} catch {
    # Per provider legacy potrebbe servire HashAlgorithm
    Set-ItemProperty -Path $hashPathCNG -Name HashAlgorithm -Value &quot;SHA256&quot;
}
Restart-Service certsvc -Force
certutil -renewCert ReuseKeys

Verifiche post rilascio

Conferma che i nuovi certificati emessi dopo il rinnovo riportino SHA‑256 nel campo algoritmo di firma.
Controlla che i client risolvano AIA e CDP senza errori, anche fuori rete locale.
Esamina i log applicativi per intercettare rifiuti di handshake dovuti a pinning o cache.
Comunica ai team di sicurezza e compliance l’avvenuto cambio e archivia la documentazione.

Piano di rollback prudenziale

Se emergono problemi gravi non risolvibili rapidamente:

Ferma certsvc.
Ripristina database e chiavi dal backup eseguito prima del cambio.
Ripristina il registro esportato e riavvia certsvc.
Rivaluta la compatibilità dei client che hanno generato l’incidente, correggi la causa e ripeti il percorso di migrazione.

Importante: il rollback deve essere l’ultima spiaggia; lavorare su test e comunicazione riduce fortemente la necessità di tornare indietro.

Domande frequenti

È possibile cambiare algoritmo senza cambiare la chiave della CA? Sì, il rinnovo con same key permette di mantenere esattamente la stessa chiave e identità della CA.

I certificati già emessi diventano invalidi? No. Restano validi fino a scadenza o revoca, ma continueranno a presentare SHA‑1 come algoritmo di firma. Per i servizi più sensibili puoi programmare la sostituzione anticipata.

Devo modificare i template? In genere no: i template ereditano l’algoritmo dalla CA, quindi dopo il rinnovo le nuove emissioni saranno firmate con SHA‑256.

È richiesto un riavvio del server? No, è sufficiente riavviare il servizio certsvc durante la configurazione e il rinnovo.

Serve aggiornare la CRL? Sì. Dopo il rinnovo, pubblica nuovamente CRL e, se usata, delta CRL, assicurandoti che i punti di distribuzione siano raggiungibili.

Tabella di marcia operativa estesa

Attività	Dettagli operativi	Esito atteso
Inventario e impatto	Mappa flussi TLS, IPsec, posta, VPN, firma codice, dispositivi e applicazioni che convalidano certificati della CA.	Elenco dei sistemi critici e dei rischi residui.
Verifica salute	Controlla `pkiview.msc`, AIA e CDP, latenza di replica AD e reachability da sedi remote.	Indicatori verdi, assenza di errori in log.
Backup	Esegui backup di database, chiavi, registro e, se applicabile, configurazione HSM; verifica ripristino in laboratorio.	Pacchetto di restore verificato.
Impostazione algoritmo	Configura `CNGHashAlgorithm` o `HashAlgorithm` a `SHA256`; riavvia il servizio.	La CA è pronta a firmare con SHA‑256.
Rinnovo certificato CA	Rinnova con stessa chiave via console o `certutil -renewCert ReuseKeys`.	Nuovo certificato radice con firma SHA‑256.
Pubblicazione	Distribuisci radice e CRL via GPO e directory; aggiorna device non in dominio.	Fiducia completa nei client.
Collaudo	Emissione test, verifica catene, handshake TLS, controlli su applicazioni e dispositivi critici.	Conferma funzionale e di conformità.
Monitoraggio	Osserva log di sicurezza, autenticazioni fallite, eventi CA; prepara escalation.	Stabilità in esercizio.

Linea guida conclusiva

La migrazione da SHA‑1 a SHA‑256 su una Enterprise Root CA online è una procedura alla portata di ogni amministratore che gestisca AD CS con pratiche operative rigorose. Con un rinnovo same key, backup solidi, test pilotati e una corretta distribuzione del nuovo certificato radice e delle CRL, ottieni una catena di fiducia aggiornata, resiliente e allineata alle migliori pratiche di sicurezza, senza stravolgimenti dell’infrastruttura.

In sintesi: sì, l’operazione è possibile e consigliata. Imposta SHA‑256 come algoritmo di firma predefinito, rinnova il certificato della CA mantenendo la stessa chiave, distribuisci la nuova radice e valida attentamente il funzionamento dei servizi. Conserva i backup e monitora l’ambiente nelle ore successive al cambio.