Migrazione AD CS: come spostare una Certification Authority Enterprise Root da Windows Server 2012 R2 a 2019 in sicurezza

Migrare una Certification Authority AD CS da Windows Server 2012 R2 a 2019 senza ricreare la PKI è possibile e sicuro con un approccio “side‑by‑side”. In questa guida trovi una procedura dettagliata, checklist, script e consigli per gestire anche il cambio di nome del server.

Indice

Scenario e obiettivo

L’utente amministra una Enterprise Root CA su Windows Server 2012 R2 e intende eseguire il passaggio a Windows Server 2019 mantenendo intatti:

la catena di fiducia esistente e tutti i certificati già emessi,
le chiavi della CA e il relativo certificato,
le impostazioni di pubblicazione CRL/AIA, i template e le policy.

Inoltre si chiede l’impatto di un cambio di nome del server durante la migrazione.

Perché scegliere la migrazione “side‑by‑side”

Microsoft scoraggia l’upgrade “in‑place” di una CA. La migrazione su un nuovo host 2019 riduce i rischi e consente rollback immediato. I principali vantaggi:

Rischio contenuto: il vecchio server resta operativo fino a validazione completata.
Finestra di fermo minima: la CA può essere resa disponibile subito dopo il restore.
Nessun impatto sui certificati esistenti: identità della CA invariata.
Possibilità di cambiare hostname senza toccare l’identità crittografica della CA.

Concetti chiave da fissare

Nome della CA (Common Name): è l’identità crittografica. Non va cambiato; cambiare il CN costringerebbe a rifare l’intera gerarchia PKI.
Nome del server (FQDN/NetBIOS): può cambiare. I certificati già emessi però contengono gli URI CRL/AIA; occorre garantirne la raggiungibilità (mantenere i vecchi percorsi o reindirizzarli).
CRL/AIA: gli URL di distribuzione delle liste di revoca (CRL) e dei certificati della CA (AIA) sono incisi nei certificati emessi. Devono rimanere validi per tutta la vita dei certificati.
Database CA: contiene richieste, certificati emessi, stato di revoca. Va migrato integralmente.
Chiavi private della CA: devono essere migrate, non rigenerate, per preservare la fiducia.

Prerequisiti e checklist

Prima di iniziare, verifica quanto segue.

Elemento	Verifica	Note
Patching 2012 R2	Ultimi aggiornamenti installati	Riduce rischi di backup/restore.
Backup CA	Database, configurazione, chiavi, CRL/AIA	Vedi comandi di seguito.
Account servizio	Se usi MSA/gMSA, presente anche sul nuovo host	Permessi su chiavi e percorsi di pubblicazione.
Tempo/NTP	Ora coerente su tutti i server	Fondamentale per validità CRL/certificati.
Firewall/ACL	Permessi su LDAP/SMB/HTTP	Distribuzione CRL/AIA e auto‑enrollment.
Spazio e snapshot	Snapshot VM o backup full	Per rollback rapido.

Schema di alto livello della migrazione

Preparare backup completo sulla 2012 R2 e validare CRL/AIA.
Installare un nuovo Windows Server 2019 (hostname diverso consigliato) e il ruolo AD CS senza configurarlo.
Ripristinare la CA su 2019 riusando certificato e chiavi.
Allineare i percorsi CRL/AIA (mantenendo quelli storici o impostando alias DNS/DFS).
Verificare con pkiview.msc e test di emissione; poi dismettere la 2012 R2.

Backup e verifiche sul server 2012 R2

Esegui un backup completo con privilegi di amministratore della CA.

rem Backup database e registri CA
certutil -backupDB "D:\CA-Backup\DB"

rem Backup chiavi private e certificato CA (proteggi il PFX con password)
certutil -backupKey "D:\CA-Backup\KEY"

rem Esporta configurazione di registro
reg export "HKLM\SYSTEM\CurrentControlSet\Services\CertSvc\Configuration" "D:\CA-Backup\CA-Config.reg" /y

rem Salva CRL e certificato della CA pubblicati
xcopy /e /i /y \\CertEnroll D:\CA-Backup\CertEnroll

Valida la pubblicazione CRL/AIA:

certutil -getreg CA\CRLPublicationURLs
certutil -getreg CA\CACertPublicationURLs
pkiview.msc

Controlla che la CA stia emettendo regolarmente, che le CRL non siano in scadenza e che eventuali Delta CRL siano coerenti con la policy.

Preparazione del nuovo server Windows Server 2019

Unisci il server al dominio con nome diverso (consigliato), assegna IP e DNS corretti.
Installa il ruolo Active Directory Certificate Services, ma non configurare la CA in questa fase.

Install-WindowsFeature ADCS-Cert-Authority -IncludeManagementTools

Se usi un HSM, installa il provider e verifica che le chiavi possano essere importate. Se la CA è software‑based, il restore userà KSP/CSP originale (CAPI o CNG) senza generare nuove chiavi.

Ripristino della CA su 2019

Copia backup, CRL e certificato della CA sul nuovo server (ad es. D:\CA-Restore).
Avvia il wizard di configurazione AD CS e scegli Certification Authority → Enterprise → Usa un certificato esistente e una chiave privata.
Importa il PFX della CA (o seleziona il provider/HSM) e specifica il medesimo nome di CA della 2012 R2.
Ripristina il database CA dal percorso salvato quando richiesto o con certutil -restoreDB a servizio fermo.

net stop certsvc
certutil -restoreDB "D:\CA-Restore\DB"
net start certsvc

Importa eventuali certificati della CA in AD e ripubblica CRL e AIA:

certutil -dspublish -f "D:\CA-Restore\CertEnroll&lt;CA-Name&gt;.crt" RootCA
certutil -crl

Allineamento dei percorsi CRL/AIA

Per non rompere i certificati già emessi, conserva gli URL storici. Esempio di configurazione mista (vecchio hostname mantenuto tramite alias DNS e share):

Tipo	URI consigliati	Note operative
CDP (CRL)	`ldap:///CN=<CAName>,<...>,CN=CDP,CN=Public Key Services,CN=Services,<ForestDN>?certificateRevocationList?base?objectClass=cRLDistributionPoint` `http://pki.<domain>/CertEnroll/<CAName>.crl` `file://\\OLD-CA\CertEnroll<CAName>.crl`	Mantieni `\\OLD-CA\CertEnroll` come alias (DFS/CNAME) puntato alla nuova share.
AIA (CA cert)	`ldap:///CN=<CAName>,CN=AIA,CN=Public Key Services,CN=Services,<ForestDN>?cACertificate?base?objectClass=certificationAuthority` `http://pki.<domain>/CertEnroll/<CAName>.crt` `file://\\OLD-CA\CertEnroll<CAName>.crt`	Assicura permessi di lettura anonimi su HTTP se usato per i client esterni.

Rivedi e applica i percorsi con:

certutil -getreg CA\CRLPublicationURLs
certutil -getreg CA\CACertPublicationURLs

rem Se devi modificarli:
certutil -setreg CA\CRLPublicationURLs ""
certutil -setreg CA\CACertPublicationURLs ""
net stop certsvc & net start certsvc
certutil -crl

Opzione consigliata: crea un CNAME DNS old-ca → new-ca e/o pubblica la share \\OLD-CA\CertEnroll via DFS Namespace puntandola alla nuova share del 2019. In questo modo tutti gli URL storici rimangono validi.

Verifiche e test prima della dismissione

Apri Enterprise PKI (pkiview.msc) e verifica verde su AIA/CDP, compresa la Delta CRL se attiva.
Emetti un certificato di prova da un client e valida la catena:

certreq -new request.inf request.req
certreq -submit request.req issued.cer
certutil -verify -urlfetch issued.cer

Controlla che GPO, script, applicazioni (VPN, IIS, RADIUS, NDES/SCEP, Wi‑Fi) non referenzino percorsi hard‑coded con il vecchio hostname. Se sì, aggiorna o fornisci gli alias.
Se usi OCSP, aggiorna il responder con il certificato di firma su 2019 o ricrea il binding verso la CA migrata.

Dismissione sicura del vecchio server

Pubblica una nuova CRL sul nuovo server e attendi propagazione AD/HTTP/SMB.
Ferma il servizio sulla 2012 R2: net stop certsvc.
Conferma dal client che catena e revoca siano ancora risolvibili solo tramite i nuovi percorsi/alias.
Rimuovi il ruolo AD CS dalla 2012 R2. Mantieni un backup offline per eventuale emergenza.

Gestione del cambio nome server

Il cambio di hostname non impatta l’identità della CA se rispetti due regole:

Il nome della CA resta lo stesso durante il restore.
Gli URL CRL/AIA storici restano raggiungibili (alias DNS, DFS, re‑publishing su HTTP).

Dove può emergere la dipendenza dal vecchio nome:

GPO che puntano a \\OLD-CA\CertEnroll.
Script di infrastruttura (job di publishing manuale o backup).
Applicazioni con trust store o URL di CRL codificati.

Rimedi pratici:

Imposta un CNAME old-ca → new-ca.
Esponi la share storica via DFS (namespace invariato, target aggiornato).
Mantieni HTTP “http://pki.domain/CertEnroll” invariato spostando il backend dietro IIS 2019.

Automazione utile con PowerShell

Alcuni snippet che velocizzano backup, restore e reporting.

# Esegui come amministratore sulla vecchia CA
$root = "D:\CA-Backup"
New-Item -ItemType Directory $root -Force | Out-Null

Backup DB e chiavi (ti verrà chiesta la password PFX)

certutil.exe -backupDB "$root\DB"
certutil.exe -backupKey "$root\KEY"

Esporta configurazione di registro

reg.exe export "HKLM\SYSTEM\CurrentControlSet\Services\CertSvc\Configuration" "$root\CA-Config.reg" /y

Copia CRL e cert della CA

robocopy \OLD-CA\CertEnroll "$root\CertEnroll" .crl .crt /e

Report degli URL CDP/AIA

"CDP:`n" + (certutil.exe -getreg CA\CRLPublicationURLs) | Out-File "$root\CDP.txt"
"`nAIA:`n" + (certutil.exe -getreg CA\CACertPublicationURLs) | Out-File "$root\AIA.txt"

# Sul nuovo server, dopo l'installazione del ruolo
Ripristino DB e ripubblicazione CRL
net stop certsvc
certutil.exe -restoreDB "D:\CA-Restore\DB"
net start certsvc
certutil.exe -crl

Validazione post‑migrazione

Oltre a pkiview.msc, esegui questi controlli:

CA operativa: servizio CertSvc in esecuzione, nessun errore in Event Viewer > Applications and Services Logs > Microsoft > Windows > CertificateServices*.
CRL valide: verifica scadenze e overlap.
Auto‑enrollment: avvia su un client gpupdate /force e poi certutil -pulse.
Risoluzione URL: certutil -url http://pki.domain/CertEnroll/<CAName>.crl.

Piano di rollback

Se la validazione fallisce, spegni la 2019, riaccendi la 2012 R2 (o ripristina snapshot) e ripubblica le CRL sul percorso storico.
Analizza i log e riprova in laboratorio; la presenza di backup completo ti consente di tornare allo stato precedente senza perdita.

In‑place upgrade: pro e contro

Aspetto	Side‑by‑side	In‑place upgrade
Rischio	Basso, server originale intatto	Alto, rollback complesso
Fermo servizio	Minimo	Prolungato
Compatibilità	Isolata, puoi testare prima	Driver/agent potrebbero fallire
Hostname	Può cambiare senza impatto	Invariato, ma upgrade a rischio

L’upgrade in‑place si considera solo in mancanza di hardware/VM aggiuntive, sempre con backup completo identico a quello richiesto per la migrazione.

Domande frequenti

Posso cambiare il nome della CA durante la migrazione?

No. Il CN della CA non deve cambiare. Se cambi il nome della CA, la fiducia dei certificati già emessi si interrompe e va ricostruita l’intera gerarchia.

Posso cambiare algoritmo/chiave della CA?

La migrazione non richiede re‑key. Se desideri rinnovare con nuova chiave (es. RSA‑4096 o passaggio a CNG), pianificalo come rinnovo separato dopo la migrazione, gestendo i certificati “cross‑certified” e le AIA.

Il cambio di hostname rompe i certificati già emessi?

Non se mantieni i vecchi URL CRL/AIA raggiungibili (alias DNS/DFS/HTTP) e non se il nome della CA resta invariato.

Uso un HSM: cosa cambia?

Verifica sul nuovo server il provider HSM e le politiche di export/import delle chiavi. Alcuni HSM non consentono l’export: in quel caso migri la chiave restando sullo stesso dispositivo o segui la procedura del vendor.

Devo ricreare i template dei certificati?

No. I template vivono in Active Directory; la CA migrata li ritroverà identici. Verifica soltanto le Autorizzazioni di emissione e le proprietà di auto‑enrollment.

Come gestire OCSP e NDES/SCEP?

OCSP: aggiorna il responder con il certificato di firma emesso dalla CA migrata. NDES: verifica i binding verso la CA e i permessi del servizio; spesso serve solo aggiornare l’hostname di destinazione se non usi alias.

Checklist rapida

Aggiorna 2012 R2 e verifica lo stato CRL.
Esegui backup di DB, chiavi, registro, CRL/AIA.
Prepara il 2019, uniscilo al dominio, installa il ruolo AD CS.
Configura la CA su 2019 riusando certificato e chiavi e stesso nome di CA.
Allinea CDP/AIA mantenendo anche l’hostname storico (alias DNS/DFS).
Verifica con pkiview.msc, emetti un certificato di prova e testa certutil -verify -urlfetch.
Allinea GPO/script/applicazioni che puntano al vecchio hostname.
Dismetti la 2012 R2 solo dopo validazione completa e pubblicazione CRL.

Appendice: esempi di policy CRL

Un’impostazione prudente prevede overlap per coprire la propagazione:

certutil -setreg CA\CRLPeriodUnits 7
certutil -setreg CA\CRLPeriod "Days"
certutil -setreg CA\CRLOverlapUnits 12
certutil -setreg CA\CRLOverlapPeriod "Hours"
net stop certsvc &amp; net start certsvc
certutil -crl

Adatta le unità alle tue policy di sicurezza e ai tempi di distribuzione.

Appendice: CAPolicy.inf di esempio

Se vuoi forzare impostazioni al prossimo rinnovo della CA, usa un CAPolicy.inf prima dell’operazione di renew (non necessario per la semplice migrazione):

[Version]
Signature="$Windows NT$"

[BasicConstraintsExtension]
PathLength=0
Critical=TRUE

[CRLDistributionPoint]
URL="[http://pki.<domain>/CertEnroll/<CAName>.crl](http://pki.<domain>/CertEnroll/<CAName>.crl)"

[AuthorityInformationAccess]
URL="[http://pki.<domain>/CertEnroll/<CAName>.crt](http://pki.<domain>/CertEnroll/<CAName>.crt)"

[certsrv_server]

AlternateSignatureAlgorithm=0

Riepilogo operativo

La strategia più sicura per migrare una Enterprise Root CA da 2012 R2 a 2019 è side‑by‑side su nuovo host: backup completo, restore delle stesse chiavi e dello stesso nome di CA, conservazione degli URL CRL/AIA storici (o reindirizzati). Con test accurati e alias appropriati, anche il cambio di hostname non comporta alcun impatto sui certificati già in circolazione.

Suggerimenti supplementari

Lab: replica la CA in laboratorio e prova la procedura end‑to‑end.
Snapshot: se la CA è virtualizzata, scatta un checkpoint prima delle modifiche.
Audit: monitora i log applicativi critici (VPN, Wi‑Fi, proxy, RADIUS, MDM) per errori di revoca.
Roadmap: lo stesso approccio ti agevolerà in futuro verso Windows Server 2022/2025.

Risorse utili per approfondire (senza collegamenti): cerca su Microsoft Learn le guide “Migrazione AD CS a Windows Server 2019”, “AD CS Migration: Migrating the Certification Authority” e la documentazione “Performing the Upgrade or Migration”.