OID e modelli di certificato in Active Directory Certificate Services: guida tecnica a template, EKU e policy

Quando duplichi un modello di certificato in Active Directory Certificate Services (AD CS) compaiono due OID: uno per identificare il template e uno per descrivere scopo/uso del certificato. In questa guida spiego perché accade, come gestire gli OID orfani e come adottare OID aziendali basati su PEN in modo sicuro.

Contesto: cosa sono OID, EKU e modelli in AD CS

OID (Object Identifier) è un identificatore univoco globale che etichetta concetti in crittografia e PKI: algoritmi, estensioni, policy, EKU, ecc. In Windows/AD CS gli OID servono soprattutto a:

• Identificare i modelli di certificato (template) in Active Directory, così che CA e client li riconoscano senza ambiguità.
• Qualificare lo scopo d’uso del certificato tramite Application Policies/EKU (Enhanced Key Usage) o Certificate Issuance Policies. Questi OID vengono letti dai servizi (es. TLS, VPN, NPS, Wi‑Fi, firma codice) per stabilire se un certificato è adatto a un compito specifico.

Quando crei o duplichi un modello, AD CS popola e sincronizza oggetti nel Configuration Naming Context di AD. Due container chiave sono:

• CN=Certificate Templates, CN=Public Key Services, CN=Services, CN=Configuration, ...
• CN=OID, CN=Public Key Services, CN=Services, CN=Configuration, ...

Il primo ospita gli oggetti pKICertificateTemplate (i veri template). Il secondo è il catalogo degli OID di foresta, dove ogni OID ha un friendly name e può rappresentare un template, una policy, un EKU, ecc.

Perché compaiono due oggetti OID quando si duplica un modello

Alla duplicazione di un template, AD CS crea due elementi distinti. La tabella seguente riassume cosa sono, dove vivono e perché esistono:

Oggetto creato	Collocazione in AD	Scopo principale
Template OID (msPKI‑Cert‑Template‑OID)	CN=Certificate Templates,... e una voce omonima in CN=OID,...	Identifica in modo univoco il nuovo modello di certificato e ne associa il “friendly name”.
Application/Issuance Policy OID	Seconda voce in CN=OID,...	Funziona come EKU (Enhanced Key Usage) o “Certificate Issuance Policy” per qualificare lo scopo del certificato emesso dal modello.

In pratica, AD CS genera automaticamente un OID “gemello” che rappresenta la policy di emissione/uso del certificato; per questo non trovi riferimenti diretti al modello.

Esempio pratico

Supponi di duplicare il template “User” per creare “Contoso‑VPN‑User”. Dopo aver salvato:

• In CN=Certificate Templates compare l’oggetto del nuovo template, con il suo msPKI‑Cert‑Template‑OID univoco.
• In CN=OID compaiono due voci: una che mappa l’OID del template a un friendly name (“Contoso‑VPN‑User (Template)”) e una seconda voce di policy/EKU (“Contoso‑VPN‑User (Policy)”).

Questa separazione consente ai client di capire lo scopo del certificato leggendo l’OID di policy/EKU, senza dover conoscere lo specifico template che lo ha originato.

Perché il secondo OID rimane dopo l’eliminazione del modello

Eliminare un template rimuove l’oggetto Template OID dal template stesso e la corrispondente voce principale, ma non esegue un garbage collection degli OID di policy. I motivi:

• Gli OID di policy/EKU potrebbero essere ancora referenziati da certificati già emessi e in circolazione (firme, autenticazioni, tunnel TLS già attivi).
• Lo stesso OID potrebbe essere stato volutamente riutilizzato da altri template o servizi per mantenere compatibilità applicativa.
• La rimozione automatica sarebbe rischiosa: cancellare una policy in uso può provocare interruzioni di servizio difficili da diagnosticare.

Quando è sicuro rimuoverlo

Puoi considerare l’eliminazione manuale di quell’OID solo se verifichi con certezza che sia inutilizzato:

• Nessun altro oggetto AD contiene la stringa OID (ricerca LDAP).
• Nessun certificato emesso di recente presenta quell’EKU/Policy tra le estensioni.
• Non esistono GPO/Autoenrollment, MDM (SCEP/PKCS), profili VPN/Wi‑Fi o applicazioni che lo richiamino.

Come rimuoverlo in sicurezza

1. Inventaria dove l’OID appare (vedi sezione “Script rapidi” più sotto).
2. Prendi un backup dell’oggetto (esporta LDIF) e documenta friendly name/OID.
3. Elimina la voce in CN=OID via ADSI Edit o PowerShell (con privilegi Enterprise Admin) solo dopo aver chiuso tutte le dipendenze.
4. Monitora i log della CA e i client per eventuali errori di EKU/policy nelle ore successive.

# Esempio: rimozione controllata (PowerShell)
ATTENZIONE: sostituisci la DN corretta e usa -WhatIf finché non sei certo
$dn = "CN=Contoso-VPN-User (Policy),CN=OID,CN=Public Key Services,CN=Services,CN=Configuration,DC=contoso,DC=com"
Remove-ADObject -Identity $dn -Confirm:$true

Sostituire l’OID Microsoft con il proprio PEN aziendale

È prassi consigliabile per i template personalizzati adottare OID sotto il tuo Private Enterprise Number (PEN) registrato presso IANA. Questo rende l’architettura PKI più robusta e governabile.

Vantaggi	Attenzioni necessarie
Unicità globale degli OID personalizzati. Zero collisioni con template/estensioni di terze parti. Governance PKI più semplice (catalogo OID aziendale unificato).	Tutti i sistemi devono accettare il nuovo OID (compatibilità applicativa). Serve documentazione e processo di assegnazione chiaro per evitare confusione. Per scopi “standard” (es. Server Authentication, Client Authentication, Smart Card Logon) mantieni comunque gli EKU ufficiali Microsoft/PKIX oltre al tuo OID proprietario, per non rompere scenari legacy.

Linea guida pratica

1. Richiedi/usa il tuo PEN IANA (ramo tipico: 1.3.6.1.4.1.<PEN>).
2. Disegna sotto‑rami per famiglia e tipo, es.: 1.3.6.1.4.1.<PEN>.1.<idModello> per OID di template ed ...2.<idModello> per policy/EKU.
3. Aggiorna il template impostando msPKI‑Cert‑Template‑OID al nuovo OID e crea l’oggetto corrispondente in CN=OID con friendly name coerente.
4. Distribuisci via GPO/Autoenrollment o MDM i certificati con EKU/OID aggiornati e monitora la compatibilità.

Passi operativi consigliati

1. Verifica dipendenze del secondo OID (search LDAP, log CA, dump certificati).
2. Documenta in un registro PKI interno l’associazione Template ⇄ OID ⇄ EKU.
3. Pulisci OID orfani solo dopo aver confermato che non ricompaiono in certificati attivi.
4. Aggiorna template esistenti per usare OID basati sul tuo PEN dove appropriato.

Script rapidi per inventariare e migrare

Elenco dei template con OID di template ed EKU principali

# Richiede RSAT-AD-PowerShell
$base = "CN=Certificate Templates,CN=Public Key Services,CN=Services,CN=Configuration,DC=contoso,DC=com"
$templates = Get-ADObject -SearchBase $base -LDAPFilter "(objectClass=pKICertificateTemplate)" `
  -Properties displayName,msPKI-Cert-Template-OID,pKIExtendedKeyUsage

$templates | Sort-Object displayName | Select-Object `
@{n="Template";e={$*.displayName}},
@{n="OID_Template";e={$*.{"msPKI-Cert-Template-OID"}}},
@{n="EKUOIDs";e={($.pKIExtendedKeyUsage -join ";")}} |
Format-Table -AutoSize 

Cerca un OID in tutto AD (Configuration + Domain)

# Cerca occorrenze letterali dell'OID in attributi testuali comuni
$oid = "1.3.6.1.4.1.55555.2.1001"
$roots = @(
 "CN=Configuration,DC=contoso,DC=com",
 "DC=contoso,DC=com"
)

foreach ($root in $roots) {
Get-ADObject -SearchBase $root -LDAPFilter "(|(cn=$oid)(displayName=$oid)(msPKI-Cert-Template-OID=$oid))" `
-Properties cn,displayName,distinguishedName |
Select-Object cn,displayName,distinguishedName
} 

Trova certificati installati che usano un certo OID come EKU/policy

# Store computer: personale e attendibilità
$stores = @("Cert:\LocalMachine\My","Cert:\LocalMachine\Root","Cert:\LocalMachine\CA")
$oid = "1.3.6.1.4.1.55555.2.1001"

foreach ($store in $stores) {
Get-ChildItem $store | ForEach-Object {
$c = $_
$ekuMatches = $c.Extensions | Where-Object {
$.Oid.Value -eq $oid -or $.Format(0) -match [regex]::Escape($oid)
}
if ($ekuMatches) {
[PSCustomObject]@{
Store = $store
Subject = $c.Subject
Thumbprint = $c.Thumbprint
NotAfter = $c.NotAfter
}
}
}
} 

Imposta un nuovo OID di template (con cautela)

# Modificare l'OID del template comporta l'uso di ADSI/AD e test accurati
$templateDn = "CN=Contoso-VPN-User,CN=Certificate Templates,CN=Public Key Services,CN=Services,CN=Configuration,DC=contoso,DC=com"
$newOid = "1.3.6.1.4.1.55555.1.1001"

Set-ADObject -Identity $templateDn -Replace @{"msPKI-Cert-Template-OID" = $newOid}

Consigliato: riavviare il servizio CA per caricare le modifiche ai template

net stop certsvc; net start certsvc

Note: gli esempi sono indicativi; adatta DN, domini, e OID al tuo ambiente e testa in un lab.

Progettazione del ramo OID sotto il tuo PEN

Per mantenere ordine e leggibilità nel tempo, adotta una convenzione stabile:

• Strutturazione: 1.3.6.1.4.1.<PEN>.1.x per OID di template, ...2.x per OID di policy/EKU.
• Numerazione: x può essere un ID incrementale o codificare area/funzione (es. 1000‑1999 utenti, 2000‑2999 server, 3000‑3999 dispositivi).
• Friendly name: ORGANIZZAZIONE – Scopo – vN. Non cambiare OID per modifiche non breaking; crea un nuovo OID solo quando cambi lo scopo d’uso.
• Registro OID: mantieni un foglio di governance con: OID, friendly name, proprietario, template associati, data di introduzione/disuso.

Decision tree: tenere o cancellare l’OID “gemello”

• Serve per compatibilità? Mantieni. Esempio: policy/EKU usata da più template (utente, dispositivo, gateway).
• È già emesso su certificati in corso di validità? Mantieni fino alla naturale scadenza o a un piano di sostituzione.
• È stato un test/lab e non è mai entrato in produzione? Dopo verifica AD e store locali, è ragionevole eliminare.

Impatto sulle applicazioni e sulle estensioni standard

Molti ruoli e protocolli si affidano a EKU standard (ad esempio Server/Client Authentication, Code Signing, Email Protection). Per i template personalizzati:

• Non rimuovere gli EKU standard necessari. Aggiungi il tuo OID aziendale oltre agli EKU standard per una riconoscibilità interna senza rompere la compatibilità.
• Se utilizzi Issuance Policies, assicurati che le applicazioni che ne fanno uso le verifichino realmente; diversamente, sarà l’EKU a determinare la decisione di accettazione del certificato.
• Per ambienti ibridi (on‑prem/MDM), valida i profili (SCEP/PKCS) e i criteri di attendibilità su tutti i sistemi coinvolti.

Operatività quotidiana: consigli pragmatici

• Refresh CA: quando aggiorni template o OID, riavvia il servizio CA per caricare le modifiche e riduci i dubbi su eventuale caching.
• Controllo replicazione: i container in Configuration replicano in tutta la foresta: verifica che i DC siano allineati prima di test su siti remoti.
• Naming coerente: allinea il friendly name dell’OID con il nome del template. Evita sinonimi che confondono i team.
• Versioning: se cambi scopo/uso (breaking change), crea nuovi OID (template e policy). Se cambi parametri minori (key length, validity), mantieni gli OID esistenti.

Checklist di migrazione a OID PEN

Prima

• Registra il PEN (se non l’hai già) e pubblica la convenzione di naming.
• Mappa template ⇄ EKU ⇄ OID correnti, identificando dipendenze applicative.
• Prepara i nuovi OID (template e policy) e i friendly name.

Durante

• Clona i template e assegna i nuovi OID sotto il tuo PEN.
• Aggiungi gli EKU standard richiesti dai servizi.
• Distribuisci la nuova catena con scope limitato (pilot) e testa enrollment/uso.

Dopo

• Migra i rilasci in produzione (GPO/Autoenrollment, MDM, profili VPN/Wi‑Fi).
• Monitora log CA e client; estrai campioni di certificati per verificare OID ed EKU.
• Quando tutti i certificati ereditati sono scaduti/revocati, valuta la pulizia degli OID orfani.

Errori comuni e come evitarli

• Confondere EKU con Issuance Policy: l’EKU determina l’uso del certificato lato applicazione; le Issuance Policy esprimono regole di emissione/affidabilità. Non sono intercambiabili in tutti i contesti.
• Riutilizzare OID senza governance: la tentazione di “riciclare” un OID porta a conflitti futuri. Usa una tabella di assegnazione centralizzata.
• Eliminare OID troppo presto: anche se un template è stato cancellato, certificati già emessi resteranno validi fino a scadenza. Pianifica prima di pulire.
• Dimenticare gli EKU standard: alcuni servizi Windows accettano solo determinati EKU. Mantienili accanto al tuo OID proprietario.

Domande frequenti (FAQ)

Vedo più di due voci nel container OID: è normale?
Sì. In ambienti complessi possono esistere OID per diversi scopi (template, policy, EKU, estensioni di terze parti). L’importante è documentare chiaramente cosa rappresenta ciascuna voce.

Posso rinominare il friendly name di un OID senza cambiare il valore numerico?
Sì: il friendly name è un’etichetta. Cambiarlo non altera la semantica dell’OID, ma allinea la visibilità per gli operatori. Meglio mantenere coerenza con i nomi dei template.

Conviene migrare tutti i template a OID sotto il mio PEN?
Per i template personalizzati è raccomandabile. Per i template standard (es. Kerberos Authentication) mantieni anche gli OID ufficiali richiesti dalla piattaforma.

Serve riavviare la CA quando aggiungo/cambio OID?
È consigliato per evitare cache incoerenti su template/policy. Approfitta per validare Enrollment Agent e CA constraints.

In estrema sintesi

• Due OID sono normali: uno identifica il modello, l’altro l’EKU/policy di emissione.
• Il secondo OID non viene eliminato automaticamente: puliscilo solo se davvero inutilizzato, dopo controlli su AD e certificati emessi.
• Usare un OID basato sul tuo PEN è ottimo per template personalizzati, a patto di garantire compatibilità e una gestione accurata degli OID.

---

Linea guida operativa rapida

1. Ottieni il tuo PEN IANA e definisci una convenzione (.1 = template, .2 = policy/EKU).
2. Assegna nuovi OID ai template duplicati e crea le voci in CN=OID con friendly name chiari.
3. Mantieni gli EKU standard quando necessario, aggiungendo il tuo OID proprietario.
4. Controlla dipendenze e migra per fasi, monitorando i log della CA e dei client.
5. Solo alla fine, pulisci gli OID orfani se non più referenziati.

Con questi accorgimenti otterrai un’implementazione AD CS pulita, prevedibile e pronta a crescere, senza sorprese legate a collisioni o cancellazioni avventate.