• Guide, Sicurezza, Sistemi Operativi
• 4 Maggio 2026

La migrazione di una Certification Authority (CA) rappresenta un’attività critica all’interno di qualsiasi infrastruttura PKI. La CA è infatti il punto centrale di fiducia per l’emissione e la gestione dei certificati digitali, ed è progettata per operare per anni, spesso attraversando diversi cicli di vita hardware e software.

Quando decidete di migrare una CA, non state semplicemente spostando un servizio, ma state garantendo la continuità operativa di tutti i sistemi che dipendono da essa: autenticazione, cifratura, firma digitale e identità dei servizi. Una migrazione eseguita correttamente consente di mantenere integrità, affidabilità e fiducia senza interruzioni percepibili dagli utenti o dai sistemi.

Il processo, nella sua essenza, si basa su un principio semplice ma rigoroso: preservare e trasferire in modo consistente database della CA, chiave privata e configurazione, dismettendo il sistema sorgente e ripristinando il servizio su una nuova piattaforma.

In questa guida vedrete come affrontare la migrazione in modo strutturato, partendo da Windows Server 2022 per arrivare a Windows Server 2025.

Dovete considerare che la procedura non è legata in modo rigido a una singola versione sorgente. Il modello di migrazione definito da Microsoft è infatti progettato per essere retrocompatibile, purché le versioni coinvolte siano ancora supportate e compatibili con il ruolo AD CS.

In pratica, la procedura è valida a partire da Windows Server 2008 (e successive) come sorgente e arrivare fino alle versioni più recenti, inclusi Windows Server 2022 e Windows Server 2025 come destinazione.

Prerequisiti

Prima di iniziare la migrazione della Certification Authority (CA), dovete verificare alcuni requisiti essenziali per evitare problemi durante il processo.

• È necessario disporre di accesso amministrativo su entrambi i server. Per le CA Enterprise, dovete operare con privilegi di Enterprise Admins o Domain Admins.
• Dovete avere accesso agli strumenti operativi, in particolare Certification Authority, PowerShell e Certutil, indispensabili per gestire backup e restore.
• Preparate una posizione sicura per i file di backup: conterranno la chiave privata, quindi devono essere protetti adeguatamente.
• Verificate la connettività di rete tra sorgente e destinazione, necessaria per le attività di migrazione e validazione.
• Se utilizzate Failover Clustering, assicuratevi che lo storage condiviso sia disponibile e che i nodi del cluster siano correttamente configurati e autorizzati.

Backup della Certification Authority

Come prima operazione dovete eseguire un backup completo della CA. Questo passaggio è determinante: rappresenta l’unica garanzia di poter ripristinare correttamente identità, stato e fiducia della vostra infrastruttura PKI.

Dovete includere nel backup tutti gli elementi critici: database della CA, chiavi private, configurazione (registro), file CAPolicy.inf e, nel caso di CA Enterprise, anche l’elenco dei template. Prima di rimuovere il ruolo, è inoltre buona pratica pubblicare una CRL con validità estesa, così da evitare problemi di revoca durante la transizione.

L’operazione deve essere eseguita con un account con privilegi di CA Administrator. In ambienti Enterprise, tipicamente si tratta di membri dei gruppi Administrators, Enterprise Admins o Domain Admins. Se utilizzate un HSM, dovete gestire il backup delle chiavi seguendo le procedure del vendor: questo aspetto non è gestito direttamente dal sistema operativo.

Potete eseguire il backup tramite diversi strumenti, ma l’approccio più diretto resta PowerShell:

Al termine, dovete interrompere il servizio per evitare l’emissione di nuovi certificati:

Figura 1: Esecuzione del backup della Certification Authority tramite PowerShell con il comando Backup-CARoleService

Figura 2: Arresto del servizio CertSvc e verifica dei file di backup della Certification Authority

Verificate quindi la presenza dei file fondamentali: il file .p12, che contiene certificato e chiave privata, e il database della CA, composto da file come CAName.edb e relativi log.

Tutti i file devono essere copiati in una posizione accessibile dal server di destinazione e protetta adeguatamente. Centralizzare il backup in un’unica directory semplifica le fasi successive e riduce il rischio di errori durante il ripristino.

Figura 3: Verifica dei file del database della Certification Authority all’interno della cartella di backup

Backup della configurazione della CA

Dopo aver eseguito il backup di database e chiavi private, dovete esportare anche la configurazione della Certification Authority, contenuta nel registro di sistema. Questo passaggio è essenziale per preservare tutte le impostazioni operative della CA e garantire un ripristino coerente sul server di destinazione.

Accedete al Registry Editor con privilegi amministrativi e navigate nel percorso HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\CertSvc\Configuration. Da qui esportate l’intero nodo Configuration, generando un file .reg che contiene la configurazione completa della CA.

Salvate il file nella stessa posizione utilizzata per il backup di database e chiave privata. Mantenere tutti i componenti nello stesso percorso semplifica le fasi successive e riduce il rischio di errori durante il ripristino.

Figura 4: Esportazione della configurazione della Certification Authority dal registro di sistema

Backup del file CAPolicy.inf

Se nella vostra configurazione è presente un file CAPolicy.inf, dovete copiarlo insieme agli altri file di backup. Questo file si trova nella directory %SystemRoot% (tipicamente C:\Windows) e deve essere salvato nella stessa posizione utilizzata per database, chiavi private e configurazione, così da mantenere un set completo per il ripristino.

Il file CAPolicy.inf definisce parametri avanzati della CA, come policy di certificazione, estensioni, validità e comportamento durante l’installazione o il rinnovo della CA stessa. Non è sempre presente: se non lo avete configurato, potete ignorare questo passaggio senza impatti sulla migrazione.

Backup dei Certificate Templates

Nel caso di una Enterprise Subordinate CA, dovete prestare particolare attenzione ai certificate templates associati. Queste informazioni non fanno parte del backup di database o registro, perché sono archiviate in Active Directory Domain Services (AD DS).

Prima di iniziare la migrazione, dovete quindi registrare manualmente l’elenco dei template pubblicati dalla CA. Potete farlo tramite lo snap-in Certification Authority, verificando la sezione Certificate Templates, oppure utilizzando Certutil per esportare l’elenco in un file di testo.

Questo passaggio è fondamentale: al termine della migrazione dovrete ripubblicare gli stessi template sulla nuova CA, per mantenere invariato il comportamento dell’infrastruttura PKI.

È inoltre importante che, una volta raccolta questa informazione, l’elenco dei template non venga modificato fino al completamento della migrazione, così da evitare incoerenze tra sorgente e destinazione.

Figura 5: Visualizzazione dei Certificate Templates associati alla Certification Authority tramite lo snap-in Certification Authority

Nella figura sotto viene eseguita l’esportazione dell’elenco dei Certificate Templates tramite Certutil, utilizzando il comando:

Il risultato è un file catemplates.txt che contiene l’elenco completo dei template associati alla CA, utile per il successivo ripristino sul server di destinazione.

Figura 6: Esportazione dei Certificate Templates della Certification Authority tramite Certutil in un file di testo

Pubblicazione di una CRL con validità estesa

Prima di avviare la migrazione della Certification Authority, è consigliabile pubblicare una CRL (Certificate Revocation List) con una validità estesa. Anche se non è obbligatorio, questo accorgimento aiuta a garantire la continuità della validazione dei certificati durante il periodo di migrazione, evitando possibili problemi nel caso in cui la CA non sia temporaneamente disponibile.

La validità della CRL deve coprire almeno l’intera durata prevista dell’attività. In questo modo, anche se la CA non è temporaneamente disponibile, i client possono continuare a verificare lo stato di revoca dei certificati senza errori.

Per ottenere questo risultato, dovete modificare temporaneamente il CRL publishing interval, pubblicare manualmente una nuova CRL e assicurarvi che venga distribuita correttamente. Prima di apportare modifiche, è importante registrare il valore originale, così da poterlo ripristinare al termine della migrazione.

Tenete presente che i client scaricano una nuova CRL solo alla scadenza di quella già in cache: per questo motivo dovete evitare di impostare una validità eccessivamente lunga, che potrebbe introdurre ritardi nella propagazione di eventuali revoche.

Questo passaggio è particolarmente critico per una CA subordinata enterprise, dove l’indisponibilità della CRL può impattare direttamente i servizi di autenticazione e sicurezza dell’infrastruttura.

Il metodo più diretto è tramite Certutil. Prima di tutto annotate i valori correnti, poi impostate un intervallo più lungo, ad esempio:

Questo esempio imposta una validità della CRL a 7 giorni (adattatela alla durata della vostra migrazione).

Dopo aver modificato i parametri, dovete riavviare il servizio della CA:

A questo punto pubblicate manualmente una nuova CRL:

In questo modo la nuova CRL avrà la validità estesa configurata.

Figura 7: Pubblicazione di una CRL con validità estesa

Come ho scritto prima, al termine della migrazione ricordatevi di ripristinare i valori originali, per evitare che i client mantengano in cache una CRL valida troppo a lungo.

Rimozione del ruolo Certification Authority dal server sorgente

Dopo aver completato tutte le attività di backup, dovete rimuovere il ruolo Active Directory Certificate Services dal server sorgente prima di procedere con l’installazione sul server di destinazione. Questo passaggio è fondamentale in ambienti Enterprise, perché la CA registra in Active Directory Domain Services (AD DS) informazioni legate al proprio common name.

Se installate la nuova CA senza aver prima rimosso quella esistente, rischiate di creare inconsistenze: la rimozione successiva del ruolo dal server sorgente eliminerebbe dati di configurazione ancora necessari al corretto funzionamento della CA migrata.

La rimozione del ruolo non elimina database, certificato e chiave privata, che restano disponibili sul server. Questo vi consente, in caso di problemi, di eseguire un rollback reinstallando il ruolo e ripristinando rapidamente la CA originale.

In alternativa, se decidete di non rimuovere immediatamente il ruolo, dovete almeno arrestare il servizio CertSvc e spegnere il server sorgente prima di installare la CA sul nuovo sistema. Tuttavia, questa modalità è sconsigliata e deve essere gestita con estrema attenzione.

La rimozione avviene tramite Server Manager, utilizzando la procedura di Remove Roles and Features, assicurandovi al termine che il ruolo sia stato completamente eliminato.

Figura 8: Rimozione del ruolo Certification Authority tramite Server Manager

Figura 9: Completamento della rimozione del ruolo Certification Authority con richiesta di riavvio del server

Rimozione del server sorgente dal dominio

Per completare correttamente la migrazione e, se necessario, mantenere lo stesso nome host sul nuovo Windows Server 2025, dovete rimuovere il server sorgente dal dominio Active Directory ed eliminare il relativo account computer.

Questa operazione è richiesta quando decidete di riutilizzare lo stesso hostname, poiché in Active Directory ogni nome deve essere univoco. In questo modo il server di destinazione può assumere l’identità del precedente, garantendo continuità su configurazione, URL e servizi PKI.

È importante chiarire che mantenere lo stesso nome non è obbligatorio. Potete migrare la CA anche su un server con nome differente, ma in questo caso dovete prestare particolare attenzione alla fase di ripristino. Alcuni riferimenti, come CRL Distribution Point (CDP) e Authority Information Access (AIA), potrebbero includere il nome del server e richiedere verifiche o adeguamenti per evitare impatti sulla validazione dei certificati.

La scelta dipende quindi dal livello di trasparenza che volete ottenere: stesso nome per una migrazione più lineare, oppure nome diverso con maggiore flessibilità ma con attenzione alla coerenza dei riferimenti PKI.

Figura 10: Rimozione del server dal dominio e passaggio a Workgroup per liberare il nome host

Figura 11: Rimozione dell’account computer da Active Directory

Join del server di destinazione al dominio

Prima di unire il server di destinazione al dominio Active Directory, dovete impostare lo stesso nome host del server sorgente, se avete scelto di mantenerlo. Questo consente, come detto prima, di preservare la continuità operativa della CA senza impatti su configurazioni, URL e riferimenti PKI.

Una volta rinominato il server, potete procedere con il join al dominio, operazione che richiede privilegi di Domain Admins, Enterprise Admins o deleghe equivalenti. Il cambio nome richiede invece privilegi di amministratore locale.

Nel caso specifico di una Enterprise Subordinate CA, il join al dominio è un passaggio obbligatorio, poiché la CA dipende da Active Directory per la gestione dei template e della configurazione.

Diversamente, se state migrando una Standalone CA, non dovete unire il server al dominio: in questo scenario è sufficiente configurare il nome del computer, mantenendo la CA fuori da Active Directory.

Figura 12: Server di destinazione rinominato e unito al dominio con richiesta di riavvio

Import del certificato della CA

Sul server di destinazione dovete importare il certificato della Certification Authority insieme alla chiave privata, utilizzando il file .p12 generato durante il backup. Questo passaggio è essenziale per ricostruire l’identità crittografica della CA.

A proposito, avete già letto la mia guida NicolaFerrini.it – Formati dei certificati digitali?

Accedete allo snap-in Certificates (Local Computer) e importate il certificato nello store Personal, assicurandovi di utilizzare la password impostata durante l’esportazione. Se non avete impostato la password e usato solo la cmdlet, allora la password è vuota.

Figura 13: Selezione del file .p12 durante l’import del certificato della Certification Authority

Al termine, verificate che il certificato sia correttamente presente e associato alla chiave privata.

Figura 14: Verifica del certificato della Certification Authority importato nello store Personal

In ambienti con HSM, potrebbe essere necessario ripristinare manualmente l’associazione tra certificato e chiave. In questo caso, dovete recuperare il serial number del certificato e utilizzare il comando:

Questa operazione garantisce che la CA possa accedere correttamente alla chiave privata necessaria per firmare certificati e CRL.

Quando importate un certificato .p12, normalmente la chiave privata viene collegata automaticamente. Tuttavia, in alcuni scenari (tipicamente con HSM, migrazioni complesse o import manuali) il certificato può risultare privo di chiave privata associata. In questi casi la CA non è in grado di firmare certificati o CRL, quindi risulta di fatto inutilizzabile.

Il comando certutil –repairstore forza Windows a cercare una chiave privata compatibile (in base a serial number e metadati) e a ristabilire il collegamento corretto nello store.

Figura 15: Ripristino dell’associazione tra certificato e chiave privata tramite certutil –repairstore

Verifica della Root CA

Dopo l’import del certificato della CA, dovete verificare che il certificato della Root CA sia presente nello store Trusted Root Certification Authorities del server.

Nella maggior parte degli ambienti Enterprise, questo certificato viene distribuito automaticamente tramite Group Policy (GPO). Tuttavia, è buona pratica controllarne la presenza per garantire la corretta catena di fiducia.

Se la Root CA non è presente, i certificati emessi dalla vostra CA non verranno considerati affidabili dai sistemi.

Figura 16: Verifica del certificato della Root CA nello store Trusted Root Certification Authorities

Installazione del ruolo Certification Authority

Adesso potete procedere con l’installazione del ruolo Active Directory Certificate Services sul server di destinazione. Dovete utilizzare un account con privilegi di Domain Admins o Enterprise Admins, in quanto la procedura interagisce con Active Directory.

Se avete utilizzato un file CAPolicy.inf, dovete copiarlo preventivamente nella directory %windir% del nuovo server, così che venga applicato durante la configurazione della CA.

L’installazione avviene tramite Server Manager, aggiungendo il ruolo Certification Authority e configurandolo in modo coerente con il server sorgente. È fondamentale mantenere lo stesso tipo di CA (nel vostro caso Enterprise Subordinate CA) e selezionare l’opzione per utilizzare una chiave privata esistente, scegliendo il certificato precedentemente importato.

Figura 17: Selezione dei servizi di ruolo AD CS durante l’installazione della Certification Authority

Figura 18: Completamento dell’installazione del ruolo AD CS con richiesta di configurazione della Certification Authority

Avviate la configurazione della Certification Authority, specificando le credenziali amministrative necessarie per completare l’installazione dei servizi Active Directory Certificate Services.

Figura 19: Inserimento delle credenziali per la configurazione della Certification Authority

Selezionate i servizi AD CS da configurare durante la fase di configurazione della Certification Authority. In particolare selezionate Certification Authority, includendo eventuali servizi aggiuntivi come Web Enrollment in base alla configurazione del server sorgente.

Figura 20: Selezione dei servizi AD CS da configurare durante la configurazione della Certification Authority

Nella schermata successiva selezionate il tipo di configurazione della CA, scegliendo Enterprise CA in coerenza con la configurazione della CA sorgente.

Figura 21: Selezione del tipo di CA (Enterprise) durante la configurazione della Certification Authority

Selezionate il tipo di CA, scegliendo Subordinate CA in coerenza con la configurazione della CA sorgente.

Figura 22: Selezione del tipo di CA (Subordinate CA) durante la configurazione della Certification Authority

Nella scheda Specify the type of the private key selezionate Use existing private key e, nello specifico, l’opzione Select a certificate and use its associated private key. In questo modo utilizzate la chiave privata precedentemente esportata dalla CA sorgente (file .p12), garantendo la continuità operativa e la validità dei certificati già emessi. Questa scelta è fondamentale in uno scenario di migrazione, perché consente alla nuova CA di mantenere la stessa identità crittografica della precedente.

Figura 23: Selezione dell’utilizzo della chiave privata esistente durante la configurazione della Certification Authority

Selezionate quindi il certificato della CA precedentemente importato (nel nostro caso Adatum-IssuingCA) che contiene anche la chiave privata associata.

Figura 24: Selezione del certificato esistente della Certification Authority durante la fase di configurazione

Specificate i percorsi per il database della Certification Authority e per i file di log. Se durante il backup della CA sorgente avete utilizzato percorsi personalizzati, è consigliabile mantenerli anche sulla nuova installazione per coerenza e semplicità di ripristino. In caso contrario, potete lasciare i percorsi predefiniti (C:\Windows\System32\CertLog).

In scenari di produzione è buona pratica configurare questi percorsi su dischi separati (ad esempio database e log su volumi distinti) per migliorare prestazioni e resilienza.

Figura 25: Configurazione dei percorsi del database e dei log della Certification Authority

Verificate attentamente il riepilogo della configurazione della Certification Authority prima di procedere. Controllate in particolare che:

• Il tipo di CA sia corretto (Enterprise Subordinate CA).
• Il Distinguished Name corrisponda a quello della CA originale.
• Il certificato selezionato sia quello importato in precedenza.
• I percorsi del database e dei log siano coerenti con la configurazione desiderata.

Se tutte le informazioni sono corrette, selezionate Configure per avviare la configurazione finale della CA.

Figura 26: Schermata di riepilogo e conferma della configurazione della Certification Authority

Figura 27: Configurazione completata dei servizi Active Directory Certificate Services

Ripristino del database della CA sul server di destinazione

A questo punto procedete con il ripristino del database della Certification Authority sul server di destinazione. Questa operazione consente di recuperare tutti i certificati emessi, le richieste e lo stato della CA dalla precedente installazione.

Accedete al server di destinazione con un account con privilegi amministrativi sulla CA, quindi aprite Windows PowerShell come amministratore.

Arrestate il servizio della CA per consentire il ripristino del database:

Eseguite quindi il ripristino del database utilizzando il percorso del backup:

Assicuratevi che il percorso specificato sia la directory padre della cartella Database (ad esempio, se i file sono in C:\BackupCA\Database, dovete indicare C:\BackupCA). Il parametro -Force è necessario perché durante l’installazione del ruolo è già stato creato un database vuoto.

Al termine, riavviate il servizio della CA:

Nota operativa: Se state operando in uno scenario cluster, eseguite il ripristino del database solo su un nodo e assicuratevi che lo storage condiviso sia online. Se invece utilizzate Server Core, PowerShell rappresenta l’unico metodo supportato per il ripristino.

Figura 28: Ripristino del database della Certification Authority tramite PowerShell sul server di destinazione

Ripristino delle configurazioni della CA presenti nel registro di sistema

Procedete con il ripristino delle configurazioni della CA presenti nel registro di sistema, che contengono parametri fondamentali come percorsi, estensioni, CRL distribution points e altre impostazioni operative.

Prima di importare il file .reg della CA sorgente, eseguite un backup della configurazione corrente del server di destinazione (ad esempio esportando la chiave CertSvc in un file come DefaultRegCfgBackup.reg). Questo vi consente di effettuare un rollback in caso di problemi.

Figura 29: Esportazione della configurazione di registro della Certification Authority per il backup della configurazione corrente

Successivamente, aprite il file .reg esportato dalla CA sorgente con un editor di testo (ad esempio Notepad) e analizzatelo attentamente:

• Se il nome del server è cambiato, cercate tutte le occorrenze e aggiornatele con il nuovo hostname (in particolare il valore CAServerName).
• Verificate tutti i percorsi locali (cartelle database, log, CRL, AIA) e assicuratevi che siano validi sul server di destinazione.
• Rimuovete eventuali riferimenti non più validi legati a:
  • ambiente precedente
  • configurazioni hardware specifiche
  • versioni di sistema diverse

Tenete presente che:

• Alcuni valori devono essere migrati senza modifiche (configurazione logica della CA).
• Altri devono essere adattati o rimossi perché dipendono dall’infrastruttura (hostname, percorsi, servizi).

Una volta completata la revisione, importate il file .reg sul server di destinazione (doppio clic o tramite reg import).

Questa operazione trasferisce le impostazioni di configurazione della CA (come estensioni, percorsi, CRL e AIA) dal server sorgente al nuovo server. È un passaggio cruciale per garantire che la CA migrata mantenga lo stesso comportamento operativo della precedente.

Nota operativa: I valori non presenti nel file .reg manterranno la configurazione già esistente o quella di default sul server di destinazione. Questo comportamento è utile per evitare di sovrascrivere impostazioni specifiche del nuovo ambiente.

Figura 30: Importazione del file di registro della CA sorgente nel server di destinazione

Figura 31: Verifica delle chiavi di configurazione della Certification Authority dopo l’importazione del registro

Avvio e verifica finale della Certification Authority

Completate la procedura avviando la Certification Authority e verificando che il ripristino sia avvenuto correttamente.

Dalla sezione Issued Certificates. Dovete verificare che i certificati precedentemente emessi siano presenti, che i Request ID risultino coerenti con quelli del server originale e che le date di validità siano corrette. Nella figura sotto si osserva che l’elenco dei certificati è popolato e che i dati storici sono disponibili, il che indica che il database è stato ripristinato correttamente e che la CA sta funzionando come previsto.

Per completare la verifica, accertatevi che eventuali certificati revocati siano visibili nella sezione dedicata e che la CA sia in grado di emettere nuovi certificati senza errori. Potete anche forzare la pubblicazione della CRL per confermare che tutti i componenti operino correttamente.

Se il servizio è attivo, i certificati storici sono presenti e l’emissione di nuovi certificati avviene senza problemi, potete considerare la migrazione della Certification Authority completata con successo.

Figura 32: Console Certification Authority con certificati emessi ripristinati correttamente dopo la migrazione

Ripristino della lista dei template di certificato

Questa operazione è necessaria solo nel caso di una Enterprise CA, poiché le Standalone CA non utilizzano i template.

Accedete al server di destinazione con credenziali amministrative e aprite un prompt dei comandi. A questo punto eseguite il comando:

Dovete sostituire <templatelist> con l’elenco dei template separati da virgola, utilizzando i nomi precedentemente salvati nel file catemplates.txt durante il backup della CA. Ad esempio:

Questo comando aggiorna la configurazione della Certification Authority aggiungendo i template specificati, rendendoli nuovamente disponibili per l’emissione dei certificati.

Dopo l’esecuzione, la CA sarà in grado di gestire le richieste basate sui template configurati, completando così il ripristino della configurazione operativa della PKI.

Figura 33: Ripristino dei template di certificato tramite comando certutil

Aprendo la sezione Certificate Templates, si osserva che i template risultano nuovamente presenti e disponibili, inclusi quelli appena aggiunti come Adatum User, Nic Web Server e TPM Virtual Smart Card Logon.

Figura 34: Template di certificato ripristinati e visibili nella console della Certification Authority

Dalla console dei Certificate Templates potete invece verificare che i template abbiano mantenuto tutte le configurazioni che avevate impostato sul server sorgente.

Figura 35: Verifica delle proprietà di un template di certificato per confermare la corretta configurazione dopo la migrazione

Concessione dei permessi sui container AIA e CDP

Questa operazione è necessaria solo quando il nome del server di destinazione è diverso da quello del server di origine, poiché la nuova CA deve avere i permessi per pubblicare certificati e CRL nei container di Active Directory.

Accedete con un account membro del gruppo Enterprise Admins a un sistema che dispone dello snap-in Active Directory Sites and Services (dssite.msc). Dopo aver aperto la console, abilitate la visualizzazione del nodo Services dal menu View.

Espandete quindi Services –> Public Key Services –> AIA, individuate la vostra Certification Authority, aprite le proprietà e nella scheda Security aggiungete l’oggetto computer del nuovo server, assegnandogli il controllo completo. Se presente, rimuovete il vecchio account della CA che appare come Account Unknown.

Figura 36: Configurazione dei permessi sulla CertificationAuthority in Active Directory Sites and Services

Successivamente spostatevi nel container CDP, selezionate la cartella con il nome della CA e per ciascun oggetto CRLDistributionPoint configurate allo stesso modo i permessi, aggiungendo il nuovo server e assegnando il controllo completo, rimuovendo eventuali riferimenti al vecchio server.

Figura 37: Configurazione dei permessi sul CRLDistributionPoint in Active Directory Sites and Services

Questa configurazione garantisce che la nuova Certification Authority possa aggiornare correttamente i punti di distribuzione delle CRL e pubblicare i certificati della CA in Active Directory, assicurando la continuità operativa dell’infrastruttura PKI dopo la migrazione.

Verifica di funzionamento

Per eseguire la verifica del corretto funzionamento della Certification Authority dopo la migrazione, effettuate una richiesta di certificato da un client appartenente al dominio utilizzando uno dei template disponibili. Una volta ottenuto il certificato, accedete allo store personale dell’utente o del computer (a seconda del template che state utilizzando) e verificate che sia stato emesso dalla nuova CA, controllando che il nome dell’emittente, le date di validità e gli utilizzi previsti siano coerenti con il template scelto. La corretta emissione e presenza del certificato sul client confermano che la CA è pienamente operativa e che l’infrastruttura PKI funziona correttamente anche lato client.

Figura 38: Certificato emesso correttamente da un client di dominio tramite la CA migrata, a conferma del corretto funzionamento della PKI

Accedete alla console della Certification Authority e controllate la sezione Issued Certificates. Individuate il certificato appena richiesto dal client di test e verificate che sia presente nell’elenco, con un Request ID valido, il nome del richiedente corretto e il template utilizzato coerente con la richiesta effettuata. La presenza del certificato nella lista, insieme alla corrispondenza dei dettagli (data di emissione, scadenza e template), conferma che la CA migrata non solo emette correttamente certificati, ma li registra anche nel proprio database, garantendo il pieno funzionamento dell’infrastruttura PKI.

Figura 39: Verifica lato CA: il certificato emesso dal client di test è correttamente presente tra gli Issued Certificates, confermando il corretto funzionamento della CA migrata

Conclusioni

La migrazione di una Certification Authority è un’operazione delicata che richiede attenzione e pianificazione, ma se eseguita correttamente consente di trasferire l’intera infrastruttura PKI senza impatti sui servizi. Durante il processo è fondamentale preservare l’integrità del database, delle chiavi private e delle configurazioni, assicurandosi che il nuovo ambiente sia coerente con quello di origine.

Un aspetto cruciale è la fase di verifica, che permette di confermare che la CA sia in grado di emettere certificati e che tutte le componenti, come template e permessi, siano state ripristinate correttamente. Eventuali differenze tra server di origine e destinazione, come nome host o percorsi, devono essere gestite con attenzione per evitare malfunzionamenti.

Se tutti i passaggi vengono eseguiti correttamente, la migrazione garantisce continuità operativa e permette di aggiornare l’infrastruttura mantenendo invariati i servizi di certificazione, elemento essenziale per l’autenticazione e la sicurezza all’interno del dominio.