MENU
  1. Inicio
  2. Windows
  3. Windows Server
  4. Cómo gestionar OID duplicados al crear plantillas de certificados en Active Directory Certificate Services

Cómo gestionar OID duplicados al crear plantillas de certificados en Active Directory Certificate Services

Windows Server

Al duplicar o modificar plantillas de certificado en Active Directory Certificate Services (AD CS) es habitual encontrar “apariciones fantasma” de objetos OID adicionales. Entender por qué surgen, cuándo son inocuos y cómo gobernarlos es clave para evitar conflictos de nomenclatura, auditorías interminables y problemas de validación de certificados en producción.

Índice

Conceptos básicos sobre OID en AD CS

Un Object Identifier (OID) es una cadena numérica jerárquica que identifica de manera unívoca casi cualquier cosa en X.509 PKI — desde un Extended Key Usage (EKU) hasta políticas de certificación. Microsoft aprovecha el LDAP de Configuración de Active Directory para almacenar estos objetos dentro de CN=OID,CN=Public Key Services,CN=Services,CN=Configuration,DC=<nombredebosque>. Cada nodo OID cuenta con atributos que incluyen su “Friendly Name”, la notación punto (p. ej. 1.3.6.1.4.1.311.21.8.12345678.345678) y el GUID interno.

OID de plantilla (msPKI-Cert-Template-OID)

Se genera cada vez que creas una plantilla nueva (o duplicas una existente). Este OID actúa como “número de serie” de la plantilla y viaja incrustado en cada certificado emitido a partir de ella. AD CS comprueba este valor durante la inscripción para identificar inequívocamente la plantilla.

OID de directiva o aplicación

Cuando duplicas, AD CS copia también los EKU, policies y flags de la plantilla original. Ese contenido necesita su propio OID para seguir siendo único; por ello se crea un segundo objeto que, a ojos del administrador, parece “huérfano”. En realidad:

  • Puede mapearse a una Policy Module interna (por ejemplo, Kerberos Authentication).
  • Puede ser consumido por certificados heredados incluso si la plantilla se elimina.
  • No se borra automáticamente para proteger la cadena de confianza y los procesos de revocación.

¿Por qué aparecen OID duplicados al duplicar una plantilla?

El asistente de AD CS ejecuta en background tres pasos:

  1. Clona los atributos de la plantilla fuente y genera un Plant OID.
  2. Crea un Policy/Application OID para cada EKU o Issuance Policy original que no existiera previamente en el contenedor OID.
  3. Enlaza ambos con la nueva plantilla mediante los atributos certificateTemplates y pKIExtendedKeyUsage.

Por diseño, el sistema evita colisiones; dos plantillas distintas no compartirán el mismo OID, y dos EKU idénticos comparten OID para ahorrar nodos en LDAP.

Riesgos y consideraciones de los OID «huérfanos»

Eliminar de golpe el segundo objeto puede parecer una buena idea para mantener el bosque limpio, pero conlleva:

  • Error de validación: certificados ya emitidos seguirán declarando ese OID en su campo EKU; las aplicaciones que requieran su presencia no lo encontrarán en los almacenes locales y fallará la autenticación.
  • Problemas de renovación automática: estaciones de trabajo con certificados “autorenew” utilizan la plantilla anterior como pista; si el OID desaparece antes de que todos los certificados expiren, la CA responderá con código de error.
  • Impacto en CRLs: si el OID forma parte de la sección Issuance Policies, se puede comprometer la revocación correcta.

Sustituir el OID estándar por uno bajo tu Private Enterprise Number (PEN)

Asignar tus propios OID (1.3.6.1.4.1.<PEN>...) es la forma de garantizar unicidad global y evitar conflictos cuando debes federar varias PKI, migrar entre bosques o pasar auditorías estrictas (PCI-DSS, eIDAS, etc.). No obstante, implica gobernanza adicional:

Ventajas

  • Evitas colisiones con los OIDs predeterminados de Microsoft (1.3.6.1.4.1.311).
  • Tienes flexibilidad para modelar sub‑árboles por región, finalidad o nivel de seguridad.
  • Facilitas la interoperabilidad con dispositivos no Windows que esperan OIDs de vendor neutro.

Retos

  • Necesitas un inventario riguroso para no reutilizar accidentalmente el mismo sufijo.
  • Cualquier cambio exige actualizar scripts de enrollment, GPOs y documentación.
  • Las plantillas “legacy” (Windows 2003) no admiten OID de más de 32 caracteres.

Estrategias de gobernanza de OIDs

Aplica un marco de control similar al de números ASN o subdominios DNS:

  1. Obtén tu PEN: la IANA lo asigna gratuitamente y es para toda la vida.
  2. Define convención de numeración: ej. 1.3.6.1.4.1.<PEN>.1.<CAID>.1000+n donde CAID es la CA emisora.
  3. Registra cada alta/baja en un CMDB o repositorio Git versionado.
  4. Automatiza la creación: usa un módulo PowerShell que lea tu CMDB y ejecute certutil -oid -add <OID> "<FriendlyName>".
  5. Audita mensualmente con certutil -enterprise -v -viewstore "OID" y compara contra tu CMDB.

Tabla de problemas y recomendaciones

ProblemaExplicaciónRecomendación práctica
Segundo objeto OID «huérfano»Se usa para EKU o Issuance Policies heredados. Puede ser referenciado por certificados previos o por otras plantillas que lo compartan.No eliminar sin analizar dependencias.
Usar certutil -oid <OID> o LDAP queries para rastrear referencias.
Sustitución por OID bajo PENEvita colisiones y profesionaliza la PKI, pero requiere gobernanza y pruebas.Registrar PEN, definir sub‑árbol, actualizar scripts y probar en laboratorio antes de producción.
Persistencia tras borrar plantillaAD CS solo limpia el Plant OID. El Policy OID permanece para no invalidar certificados existentes.Auditar con certutil -view y -restrict.
Eliminar manualmente solo si 0 referencias.

Procedimiento detallado para limpieza segura

  1. Inventario
    certutil -oid > %USERPROFILE%\Desktop\OID_inventory.txt Filtra el archivo por el sufijo del OID en cuestión.
  2. Detección de referencias en certificados vigentes
    certutil -view -restrict "Extensions=<OID>" -out "RequestID,NotAfter,SerialNumber" > OID_usage.csv Si recibes “0 certificados encontrados”, continúa.
  3. Chequeo en plantillas y CA
    Get-ADObject -LDAPFilter "(msPKI-Cert-Template-OID=<OID>)" -SearchBase "CN=Certificate Templates,CN=Public Key Services,CN=Services,CN=Configuration,DC=..." y certutil -getreg CA\PolicyModules
  4. Backup
    Exporta el nodo OID antes de borrarlo: ldifde -f backup_OID.ldf -d "CN=<FriendlyName>,CN=OID,CN=Public Key Services,CN=Services,CN=Configuration,DC=..." -p Base
  5. Eliminación
    ldifde -i -f delete_OID.ldf donde delete_OID.ldf contiene
    dn: CN=<FriendlyName>,CN=OID,CN=Public Key Services,CN=Services,CN=Configuration,DC=...
    changetype: delete
  6. Replicación
    Espera a que la eliminación replique o fuerza con repadmin /syncall /AeD.
  7. Monitorización post‑operación
    Revisa Event Viewer > Applications and Services Logs > Microsoft > Windows > CAPI2 durante 24 h para detectar fallos de validación.

Automatización con PowerShell

El siguiente fragmento consulta OIDs no referenciados y genera un informe HTML:

$oids = Get-ADObject -Filter 'objectClass -eq "msPKI-Enterprise-Oid"'
$unused = foreach ($oid in $oids) {
    $inUse = (certutil.exe -view -restrict "Extensions=$($oid.msPKI-OID)" -out "RequestID" 2>$null).Length -gt 0
    if (-not $inUse) { $oid }
}
$unused | ConvertTo-Html DistinguishedName,msPKI-OID,DisplayName |
    Out-File "$env:USERPROFILE\Desktop\UnusedOIDs.html"

Puedes programarlo con Scheduled Tasks y recibir alertas cuando el recuento supere un umbral.

Buenas prácticas operativas y checklist

  • Mantén un “catálogo de OIDs” versionado, con fecha de alta, propósito y responsable.
  • No reutilices un identificador para funciones distintas, aunque el original esté retirado.
  • Evita exponer OID internos en documentos públicos; usa un alias o Friendly Name.
  • Prueba la compatibilidad con dispositivos Linux/OpenSSL que no cargan automáticamente OIDs de AD.
  • Incluye la validación de OIDs en tus pruebas de DRP: restaura una CA en laboratorio y comprueba que el contenedor OID se replica correctamente.
  • Automatiza la creación de plantillas con certtmpl.exe -dup y suministra el OID deseado desde un JSON centralizado.
  • Establece un proceso de “gracia” mínimo de una vida de certificado + 30 días antes de purgar objetos.

Conclusión

Los objetos OID duplicados en AD CS no son un fallo, sino una consecuencia de la lógica de herencia de plantillas y la necesidad de preservar la integridad de certificados ya emitidos. La clave está en comprender la diferencia entre Plant OID y Policy OID, adoptar un esquema de numeración basado en tu PEN corporativo y aplicar procedimientos de inventario, auditoría y limpieza seguros. Con una gobernanza sólida mantendrás tu PKI ordenada, minimizarás riesgos de validación y facilitarás futuras migraciones o integraciones con PKI externas.

Windows Server
Windows Server PKI certificados digitales OIDs AD CS
Índice