Migrazione di una Certification Authority (CA) Windows su un nuovo server con hostname diverso: come aggiornare correttamente AIA e CDP, eliminare i riferimenti obsoleti in Active Directory e risolvere gli errori in PKIView senza impattare i client.
Panoramica
Quando si sposta una CA Microsoft (AD CS) su un nuovo server con nome diverso, i punti di pubblicazione AIA (Authority Information Access) e CDP (CRL Distribution Point) continuano spesso a riferirsi al vecchio hostname. Il risultato tipico è che PKIView mostra errori di download del certificato CA o della CRL, e i client non riescono a verificare la catena di fiducia. Questo articolo spiega come correggere gli URL AIA/CDP, pulire Active Directory, rinnovare il certificato della CA e validare il tutto con PKIView, includendo esempi concreti e script utili.
Perché succede
Gli URL di AIA e CDP sono memorizzati in tre luoghi diversi:
- Configurazione della CA (Estensioni in
certsrv.msc) – determina dove la CA pubblica i propri artefatti e quali URL inserire nelle estensioni dei certificati emessi. - Active Directory – i percorsi LDAP/HTTP pubblicati sotto
CN=Public Key Servicessono consultati dai client di dominio. - Dentro il certificato della CA – al rinnovo, la CA “sigilla” i nuovi URL AIA/CDP nel proprio certificato.
Dopo la migrazione con cambio hostname, è facile che rimangano URL che puntano al vecchio server in uno o più di questi punti. Finché il certificato della CA non viene rinnovato (riemettendo il certificato con i nuovi URL), i client continueranno a seguire riferimenti obsoleti.
Sintomi tipici
- PKIView segnala rosso/giallo su “AIA Location” o “CDP Location” (download fallito o URL non raggiungibile).
- Client che falliscono la validazione con errori di CRL indisponibile/obsoleta.
- Eventi nel registro Application del server CA relativi a pubblicazione CRL fallita.
Soluzione in quattro mosse (verificata)
Verifica e correzione degli URL AIA/CDP
Apri certsrv.msc → destro sulla CA → Proprietà → scheda Extensions.
- Rimuovi tutti gli URL che puntano al vecchio hostname.
- Aggiungi o conferma i nuovi URL che puntano al nuovo hostname, nei formati necessari (HTTP, LDAP, file).
- Verifica attentamente le spunte associate a ciascun URL (inclusione in certificati emessi, pubblicazione CRL, ecc.).
Linee guida pratiche:
| Estensione | Scopo | Esempio URL | Spunte consigliate |
|---|---|---|---|
| AIA | Punto da cui i client scaricano il certificato della CA | http://pki.nuovodominio.it/pki/<CaNameShort>.crtldap:///CN=<CAName>,CN=AIA,... | Include in AIA dei certificati emessi; Pubblica in AD/HTTP se previsto |
| CDP | Punto da cui i client scaricano la CRL (e Delta CRL) | http://pki.nuovodominio.it/pki/<CaName><CRLNameSuffix>.crlldap:///CN=<CAName>,CN=CDP,... | Include in CDP dei certificati emessi; Pubblica CRL/Delta CRL; Includi posizione Delta in CRL |
Esempi di template utili (variabili tipiche):
HTTP AIA: http://pki.nuovodominio.it/pki/<CaNameShort>.crt
HTTP CDP: http://pki.nuovodominio.it/pki/<CaName><CRLNameSuffix><DeltaCRLAllowed>.crl
LDAP AIA: ldap:///CN=<CAName>,CN=AIA,CN=Public Key Services,CN=Services,CN=Configuration,DC=nuovodominio,DC=it?cACertificate?base?objectClass=certificationAuthority
LDAP CDP: ldap:///CN=<CAName>,CN=CDP,CN=Public Key Services,CN=Services,CN=Configuration,DC=nuovodominio,DC=it?certificateRevocationList?base?objectClass=cRLDistributionPoint
Nota: Se usi percorsi file:// per la pubblicazione locale automatica, assicurati che la directory esista e che l’account del servizio CA abbia i permessi di scrittura. Tipicamente si usa file://\<server>\pki\ come share di staging, combinato con HTTP che pubblica dalla stessa cartella.
Dove sono salvate queste impostazioni nel Registro di sistema
Per completezza (e per audit/automazione), le liste di URL sono conservate sotto:
HKLM\SYSTEM\CurrentControlSet\Services\CertSvc\Configuration<NOME_CA>\CRLPublicationURLs
HKLM\SYSTEM\CurrentControlSet\Services\CertSvc\Configuration<NOME_CA>\CACertPublicationURLs
Le voci sono stringhe multi-linea con flag; la scheda Extensions è l’interfaccia supportata per modificarle.
Pulizia di Active Directory
Apri adsiedit.msc e naviga fino a CN=Public Key Services,CN=Services,CN=Configuration,DC=.... Controlla in particolare:
CN=AIA– rimuovi eventuali oggetti con URL riferiti al vecchio hostname.CN=CDP– elimina residui di CRL/Delta CRL che puntano al vecchio server.CN=Enrollment Services– verifica che esista un solo oggetto per la CA corretta e che gli attributi non contengano riferimenti al vecchio nome.
Consiglio: prima di eliminare qualsiasi oggetto, esporta la chiave (o scatta uno snapshot del volume AD DS/backup del System State). La replicazione richiede tempo: dopo le modifiche, attendi la convergenza oppure forza la replica tra i controller di dominio.
Rinnovo del certificato della CA
Questo è lo snodo decisivo: il rinnovo rigenera il certificato della CA includendo i nuovi URL AIA/CDP e ripubblica la CRL secondo le nuove regole.
- In certsrv.msc → destro sulla CA → All Tasks → Renew CA Certificate.
- Se non devi ruotare le chiavi, scegli senza generare una nuova chiave (stessa coppia RSA/ECDSA). In alternativa, scegli una nuova chiave se richiesto da policy di sicurezza.
- Al termine, riavvia il servizio della CA (o usa Restart CA) per applicare subito.
È normale che, dopo il rinnovo, nella console compaia il suffisso “(1)” nel nome amichevole della CA: non impatta i client. Conta ciò che è inserito nel certificato (Subject/Issuer) e, soprattutto, che gli URL AIA/CDP siano ora corretti.
Alternative da riga di comando:
REM Rinnova il certificato della CA riutilizzando la stessa chiave
certutil -renewCert ReuseKeys
REM Pubblica manualmente una nuova CRL (utile subito dopo il rinnovo)
certutil -CRL
REM Ripubblica certificati e CRL in Active Directory
certutil -dspublish Controllo finale con PKIView
Esegui pkiview.msc e verifica che:
- Le voci AIA Location e CDP Location risultino OK (verde).
- Non compaiano più riferimenti al vecchio hostname, né errori di scadenza CRL/Delta CRL.
Come ulteriore test, usa certutil -url <percorsoofile_cert> su un client per verificare il download di AIA/CDP dalla prospettiva del computer utente (firewall/proxy permettendo).
Esito del caso reale
L’utente ha confermato che il solo rinnovo del certificato della CA ha risolto l’anomalia: l’operazione ha ripubblicato correttamente AIA e CDP sul nuovo hostname, e PKIView è tornato “verde”. Non essendoci ancora client o servizi dipendenti dalla CA, non si sono verificate interruzioni operative.
Checklist operativa completa
- Backup completo (database CA, chiavi private con protezione, configurazione, CRL/Delta CRL attuali).
- Verifica estensioni AIA/CDP in certsrv.msc: rimuovi vecchie, inserisci nuove, controlla spunte.
- Pulizia AD (adsiedit.msc): AIA, CDP, Enrollment Services senza residui obsoleti.
- Rinnovo CA (con o senza nuova chiave secondo policy), riavvio servizio, pubblicazione CRL.
- Validazione con PKIView e
certutil -urlda un client. - Monitoraggio: controlla i log e pianifica la scadenza CRL/Delta CRL.
Best practice e impostazioni consigliate
- Usa HTTP + LDAP: HTTP è spesso il canale più affidabile (anche per non-domain-joined), LDAP è ideale per client di dominio.
- Evita il nome host “nudo”: preferisci un alias DNS dedicato (es.
pki.nuovodominio.it) così futuri spostamenti non impongono un altro rinnovo della CA. - Permessi corretti sulla cartella di pubblicazione CRL: l’account del servizio CA deve poter scrivere.
- CRL cadenced: imposta periodi realistici (CRLPeriodUnits, CRLDeltaPeriodUnits) per evitare scadenze ravvicinate o CRL troppo pesanti.
- Replica AD: dopo
certutil -dspublisho il rinnovo, verifica la propagazione su tutti i DC. - Documenta i template AIA/CDP usati e tienili coerenti tra ambienti (lab/staging/prod).
Controlli rapidi: cosa vedere in PKIView
| Voce | Stato atteso | Come risolvere se KO |
|---|---|---|
| AIA Location | OK (download riuscito, certificato valido) | Correggi URL AIA; ripubblica certificato CA; rinnova CA se gli URL nel certificato sono errati |
| CDP Location | OK (CRL scaricabile e non scaduta) | Correggi URL CDP; pubblica nuova CRL (certutil -CRL); verifica permessi/HTTP |
| Delta CRL | Presente se abilitata e aggiornata | Abilita delta in Extensions; pubblica; controlla Include in CRLs |
| Authority Certificate | Valido (nuovi URL corretti) | Rinnova CA; ripubblica in AD (certutil -dspublish) |
Automazione e audit con PowerShell
Di seguito alcuni snippet per elencare rapidamente ciò che va controllato.
Elenco AIA/CDP dalla configurazione della CA
# Esegui in PowerShell come amministratore sul server CA
$caName = (Get-ItemProperty 'HKLM:\SYSTEM\CurrentControlSet\Services\CertSvc\Configuration').Active
$baseKey = "HKLM:\SYSTEM\CurrentControlSet\Services\CertSvc\Configuration\$caName"
'=== AIA (CACertPublicationURLs) ==='
(Get-ItemProperty $baseKey).CACertPublicationURLs -split "`n" | ForEach-Object { $.Trim() } | Where-Object { $ }
'=== CDP (CRLPublicationURLs) ==='
(Get-ItemProperty $baseKey).CRLPublicationURLs -split "`n" | ForEach-Object { $.Trim() } | Where-Object { $ }
Ricerca di riferimenti al vecchio hostname in AD
# Sostituisci legacyHost con il vecchio hostname
$legacyHost = 'CA-OLD'
$base = 'CN=Public Key Services,CN=Services,' + (Get-ADRootDSE).configurationNamingContext
Get-ADObject -LDAPFilter "(|(cn=$legacyHost)(distinguishedName=$legacyHost)(cACertificate=)(certificateRevocationList=))" -SearchBase $base -Properties * |
Where-Object {
$_.distinguishedName -match $legacyHost -or
($_.cACertificate -ne $null) -or
($_.certificateRevocationList -ne $null)
} |
Select-Object Name, DistinguishedName, ObjectClass
Esamina i risultati prima di eliminare qualsiasi oggetto. Usa il Cestino AD (se attivo) o un backup per recovery.
Verifica download AIA/CDP dal client
# Sostituisci con un certificato utente o server emesso dalla CA
$certPath = 'C:\temp\mioCert.cer'
certutil -url $certPath
FAQ rapide
Devo riemettere i certificati ai client?
Di norma no, se rinnovi la CA senza cambiare chiave. I certificati esistenti continuano a validare sulla nuova chain, a patto che AIA/CDP siano raggiungibili e la CRL aggiornata.
Il suffisso “(1)” nel nome della CA è un problema?
No: è un friendly name locale che indica un rinnovo. Non ha impatto funzionale su chain o trust.
Meglio nuova chiave al rinnovo?
Dipende dalle policy (rotazione chiavi, crittografia). Con nuova chiave si genera una nuova CA certificate chain che i client potrebbero dover scaricare; pianifica la distribuzione del nuovo certificato CA se necessario.
Serve OCSP?
Non obbligatorio. In reti ampie o con requisiti di bassa latenza, considera l’implementazione di un Online Responder e aggiungi l’URL OCSP nelle estensioni appropriate.
Errori comuni e come evitarli
- Usare hostname del server negli URL: preferisci un alias DNS dedicato (es.
pki). Eviterai un nuovo rinnovo al prossimo spostamento. - Dimenticare la pubblicazione AD: dopo il rinnovo, esegui (o verifica)
certutil -dspublishe la replica tra DC. - CRL scaduta: aumenta i periodi (es. CRL 1–2 settimane, Delta 1–8 ore) in ambienti dinamici.
- Percorsi file non accessibili: se usi
file://, configura i permessi; se usi HTTP, verifica binding, ACL e firewall.
Approfondimenti utili
| Termine | Funzione | Dove si configura / verifica |
|---|---|---|
| AIA | URL da cui i client scaricano il certificato della CA per validare la chain | certsrv.msc → Extensions / PKIView |
| CDP | URL da cui i client scaricano la CRL per controllare le revoche | Stesse console |
| PKIView | Strumento grafico per audit dello stato PKI (AIA, CDP, CRL, delta‑CRL) | pkiview.msc |
| adsiedit.msc | Editor LDAP per rimuovere voci obsolete in AD (AIA/CDP, Enrollment Services, etc.) | MMC |
Procedure dettagliate passo‑passo
Correzione AIA/CDP in GUI
- Apri Certification Authority (
certsrv.msc). - Destro sul nome della CA → Properties → scheda Extensions.
- Nell’elenco Select extension, scegli CRL Distribution Point (CDP):
- Elimina gli URL con il vecchio hostname.
- Aggiungi i nuovi HTTP/LDAP/file secondo la tua architettura.
- Imposta le spunte:
- Publish CRLs to this location (per i percorsi di pubblicazione).
- Include in CRLs. Clients use this to find Delta CRL locations (per gli URL di riferimento).
- Include in the CDP extension of issued certificates (per i client).
- Seleziona Authority Information Access (AIA):
- Pulisci gli URL vecchi, aggiungi quelli nuovi.
- Spunta Include in the AIA extension of issued certificates per gli URL che i client devono usare.
- Conferma con OK. Se richiesto, accetta il riavvio del servizio dopo il rinnovo.
Pulizia AD con ADSI Edit
- Apri adsiedit.msc e connetti al Configuration Naming Context.
- Vai a
CN=Services → CN=Public Key Services. - Controlla CN=AIA e CN=CDP:
- Verifica che gli oggetti CN=<CAName>* non contengano URL col vecchio host negli attributi.
- Se presenti, elimina con prudenza le voci obsolete (dopo backup).
- Controlla CN=Enrollment Services:
- Deve esistere un solo oggetto per la CA attiva.
- In caso di vecchie CA dismesse, rimuovi gli oggetti non più in uso.
Rinnovo della CA e pubblicazione
- In
certsrv.msc: All Tasks → Renew CA Certificate. - Scegli se riutilizzare la chiave o generarne una nuova (valuta policy e compatibilità).
- Al termine, esegui:
certutil -CRLper forzare il rilascio immediato di una nuova CRL.certutil -dspublishper ripubblicare in AD.
- Riavvia il servizio Active Directory Certificate Services.
Validazione con PKIView e da client
- Apri
pkiview.msc: tutto deve risultare verde. In caso contrario, leggi il dettaglio dell’errore sull’URL. - Da un client, verifica il download effettivo:
certutil -url <certificato>→ schede AIA e CDP.- Controlla che le date di Next Update della CRL siano corrette.
Piano di rollback (se qualcosa va storto)
- Ripristina i template AIA/CDP precedenti (se salvati) o reimporta le voci dal backup del Registro.
- Ripubblica il certificato CA precedente in AD (
certutil -dspublishcon il file .crt di backup). - Ripubblica la CRL precedente (
certutil -f -dspublish <CRLfile.crl>).
Consiglio pratico prima di migrare
Prima del rinnovo o della migrazione in produzione, esegui un backup completo (database CA, chiavi private, configurazione, CRL) e testa l’intera procedura in un laboratorio isolato. Considera di usare un alias DNS “pki” per disaccoppiare il nome logico dai server fisici.
Riepilogo essenziale
- Allinea gli URL in Extensions (AIA/CDP) al nuovo hostname.
- Rimuovi i residui in AD (AIA/CDP/Enrollment Services).
- Rinnova il certificato della CA e ripubblica la CRL.
- Verifica con PKIView e
certutil -urlsu un client.
Con questi passaggi, la CA aggiorna i propri metadati e i client possono scaricare correttamente certificato CA e CRL dal nuovo hostname.
Nota operativa: se la tua è una Root CA offline, i passaggi di rinnovo e pubblicazione saranno manuali (copia fisica dei file .crt/.crl verso i repository HTTP/LDAP). Pianifica finestre di manutenzione adeguate e verifica la reachability dagli ambienti interessati.
Contenuti chiave del caso
- Problema: AIA/CDP ancora puntati al vecchio server dopo migrazione CA → errori PKIView, download falliti.
- Soluzione:
- Correzione URL in certsrv.msc (Extensions).
- Pulizia oggetti AIA/CDP in AD (adsiedit.msc).
- Rinnovo certificato CA (inclusione nuovi URL) + ripubblicazione CRL.
- Verifica finale con pkiview.msc.
- Esito: risolto con il solo rinnovo CA; nessun impatto perché non c’erano ancora client dipendenti.