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.
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 "%SYSTEMROOT%\System32\CertSrv\CertEnroll<NomeCA>_<NomeCA>.crt"
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 = "HKLM:\SYSTEM\CurrentControlSet\Services\CertSvc\Configuration" + (Get-ItemProperty "HKLM:\SYSTEM\CurrentControlSet\Services\CertSvc\Configuration").Active "\CSP"
try {
Set-ItemProperty -Path $hashPathCNG -Name CNGHashAlgorithm -Value "SHA256" -ErrorAction Stop
} catch {
# Per provider legacy potrebbe servire HashAlgorithm
Set-ItemProperty -Path $hashPathCNG -Name HashAlgorithm -Value "SHA256"
}
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.