Problema

En muchos entornos de Active Directory se utiliza un alias DNS (por ejemplo ad.contoso.com) para referenciar al controlador de dominio principal. Cuando se migra a LDAP sobre SSL (LDAPS, puerto 636) los clientes verifican que el nombre que aparecen en la conexión exista dentro del certificado del DC. Si el certificado solo contiene el FQDN real del servidor (dc01.contoso.com) la validación falla y aparece un aviso de “nombre no encontrado en el certificado”.

El síntoma típico es una advertencia en aplicaciones o scripts que usan LDAPS, o un error de conexión que menciona que el nombre del host no coincide con el Subject CN ni con ningún Subject Alternative Name (SAN) del certificado. La solución pasa por crear un certificado que incluya tanto el nombre real del DC como el alias que usan los clientes.

Causa

  1. Plantilla de certificado predeterminada
    Las plantillas de “Domain Controller” que vienen con Windows Server rellenan automáticamente el CN y los SAN a partir de la información de AD. El campo “Build from this Active Directory information” está bloqueado, por lo que no se pueden añadir nombres adicionales durante la solicitud.

  2. Restricciones de seguridad en la plantilla
    Cambiar la plantilla para permitir “Supply in the request” elimina la protección que impide que cualquier usuario añada nombres arbitrarios, lo que suele considerarse una mala práctica.

  3. Uso de alias DNS sin reflejo en el certificado
    El alias (ad.contoso.com) no está registrado como un registro de servicio (SRV) ni como un nombre alternativo en el certificado, por lo que la cadena de confianza se rompe en la fase de validación del cliente.

  4. Múltiples certificados en el mismo DC
    Algunas implementaciones crean un certificado “Web Server” con SAN manuales y lo enlazan al servicio LDAP. Aunque funciona, deja dos certificados diferentes en el mismo DC, lo que complica la gestión y la rotación.

Solución

La estrategia más limpia es crear una plantilla de certificado personalizada que permita inyectar SANs específicos sin abrir la puerta a cualquier solicitud. El proceso se divide en tres pasos:

  1. Clonar la plantilla “Domain Controller”

    • En el servidor de certificación (CA), abre la consola de Certification Authority.
    • Botón derecho → All Tasks → Submit new request → Duplicate Template.
    • Selecciona “Domain Controller” como base y asigna un nombre descriptivo (p. ej. DC‑SAN).

  2. Ajustar la plantilla

    • En la pestaña General, marca Publish certificate in Active Directory si no está activado.
    • En Request Handling, cambia Subject name a Supply in the request y habilita la casilla Allow any subject name solo para el grupo de equipos que ejecutan los DC (por ejemplo, Domain Controllers).
    • En Extensions, abre Application Policies y verifica que incluya Domain Controller Authentication.
    • En Subject Name, agrega los campos SAN que necesitas:
      • DNS=dc01.contoso.com (nombre real)
      • DNS=ad.contoso.com (alias).
    • Guarda y publica la plantilla.

  3. Solicitar el certificado desde el DC

    • Usa certreq o PowerShell para generar una solicitud que incluya los SAN deseados.
    • La solicitud debe especificar el CN que coincida con el nombre real del DC (p. ej. CN=dc01.contoso.com). Los SAN se añaden en la sección [Extensions] del archivo INF.

Ejemplo de archivo INF

[Version]
Signature="$Windows NT$"

[NewRequest]
Subject = "CN=dc01.contoso.com"
KeySpec = 1
KeyLength = 2048
Exportable = TRUE
MachineKeySet = TRUE
ProviderName = "Microsoft RSA SChannel Cryptographic Provider"
HashAlgorithm = sha256

[Extensions]
2.5.29.17 = "{text}"
_continue_ = "dns=dc01.contoso.com&dns=ad.contoso.com"

Con este INF, ejecutas:

certreq -new dc_san.inf dc_san.req
certreq -submit -config "CA-Server\EnterpriseCA" dc_san.req

El CA emitirá un certificado que contiene ambos nombres en la extensión SAN. El DC lo instalará automáticamente si la solicitud se hizo bajo la cuenta de equipo del controlador.

Alternativas prácticas

  • Uso de la plantilla “Web Server”: Si no se dispone de una CA interna o no se quiere tocar la plantilla de DC, se puede crear un certificado con la plantilla “Web Server” y asignarle los SAN necesarios. Luego, enlazarlo al servicio LDAP mediante la política de registro de certificados (certutil -setreg ca\DSConfigDN). Esta opción es válida para entornos pequeños, pero aumenta la carga administrativa.

  • Registro de alias como registro SRV: Añadir un registro _ldap._tcp.ad.contoso.com que apunte al DC permite que algunos clientes resuelvan el alias sin necesidad de SAN, pero no elimina la validación de nombre en el certificado. Es una solución complementaria, no sustituta.

Cuándo aplicar esta solución

  • Se usan alias DNS para los controladores y se planea migrar a LDAPS.
  • Los clientes generan errores de nombre no coincidente al iniciar sesión o al establecer conexiones LDAP.
  • Se dispone de una CA interna que permite crear plantillas personalizadas.
  • Se quiere evitar la proliferación de certificados (más de uno por DC).

No es necesario si:

  • Todos los clientes usan el FQDN real del DC.
  • No se requiere LDAPS (se mantiene LDAP sin cifrar).
  • La infraestructura no cuenta con una CA que permita crear plantillas (en ese caso, la opción “Web Server” es la única viable).

Código

# 1. Crear archivo INF con SAN
cat > dc_san.inf <<'EOF'
[Version]
Signature="$Windows NT$"

[NewRequest]
Subject = "CN=dc01.contoso.com"
KeySpec = 1
KeyLength = 2048
Exportable = TRUE
MachineKeySet = TRUE
ProviderName = "Microsoft RSA SChannel Cryptographic Provider"
HashAlgorithm = sha256

[Extensions]
2.5.29.17 = "{text}"
_continue_ = "dns=dc01.contoso.com&dns=ad.contoso.com"
EOF

# 2. Generar solicitud
certreq -new dc_san.inf dc_san.req

# 3. Enviar a la CA (reemplazar CA-Server\EnterpriseCA por el nombre real)
certreq -submit -config "CA-Server\EnterpriseCA" dc_san.req

# 4. Instalar automáticamente (si la solicitud se ejecuta bajo la cuenta del DC)
certreq -accept dc_san.req

Verificación

  1. Revisar el certificado instalado
    Ejecuta certutil -store my en el DC y busca el certificado emitido. Verifica que la línea Subject Alternative Name contenga ambos DNS.

  2. Probar la conexión LDAPS
    Desde una máquina cliente, usa ldp.exe o openssl s_client -connect ad.contoso.com:636. La negociación TLS debe completarse sin advertencias de nombre.

  3. Comprobar eventos de seguridad
    En el visor de eventos, bajo Directory Service → Certificate Services, no deben aparecer errores de “certificate name mismatch”.

Notas adicionales

  • Renovación automática: Si la plantilla está configurada con renovación automática, los SAN se volverán a generar en cada ciclo sin intervención manual.
  • Control de acceso a la plantilla: Limita la asignación de la plantilla a los grupos Domain Controllers para evitar que usuarios normales soliciten certificados con SAN arbitrarios.
  • Impacto en replicación: Un certificado con SAN no afecta la replicación de AD, pero sí puede influir en la detección de controladores por parte de clientes que usan el alias.
  • Auditoría: Registra los cambios de plantilla en la política de auditoría de AD para rastrear quién crea o modifica certificados de DC.

Con esta configuración, los alias DNS dejan de ser un punto de fricción al pasar a LDAPS y se mantiene una única cadena de confianza por controlador, simplificando la gestión y reduciendo la superficie de error.