Problema

En entornos con controladores de dominio (DC) basados en Windows Server Core, la obtención de un certificado para LDAPS suele ser más engorrosa que en servidores con GUI. La ausencia del MMC certlm.msc y de la opción “Request New Certificate” obliga a los administradores a recurrir a la línea de comandos o a herramientas remotas que no siempre rellenan automáticamente los campos de Subject y SAN. El síntoma típico es la imposibilidad de establecer una conexión LDAP sobre TLS (puerto 636) porque el DC no tiene un certificado válido o el certificado no está ubicado en el almacén correcto.

Causa

  1. Falta de auto‑enrollment
    En Server Core, la política de auto‑enrollment no se ejecuta de forma automática a menos que esté habilitada explícitamente en una GPO que se aplique al equipo. Sin la política, el DC no solicita el certificado ni lo coloca en Local Machine\Personal.

  2. Plantilla de certificado no disponible para el DC
    La plantilla de AD CS debe estar configurada para permitir el enrollment de equipos y, específicamente, de controladores de dominio. Si la plantilla está restringida a usuarios o a grupos que no incluyen a los DC, la solicitud falla.

  3. Uso de certreq sin los atributos de Subject/ SAN
    Cuando se genera un archivo .inf manualmente, omitir los campos Subject y SubjectAltName provoca errores como “DNS name unavailable” porque el CA no puede completar la información requerida.

  4. Almacén de certificados incorrecto
    Incluso con un certificado emitido, si se importa en el almacén de Current User o en Local Machine\Trusted Root en lugar de Local Machine\Personal, el servicio LDAP no lo reconoce.

  5. Puerto 636 bloqueado o no escuchando
    En Server Core, el firewall puede estar configurado para bloquear el tráfico TLS, o el servicio LDAP no está configurado para escuchar en el puerto seguro.

Solución

1. Preparar la plantilla de AD CS

  1. En el servidor CA, abre la consola Certification Authority.
  2. Duplica la plantilla DomainController (o Web Server) y nómbrala, por ejemplo, LDAPS‑DC.
  3. En Properties → Request Handling, marca Allow private key to be exported (opcional) y Subject Name → Supply in the request.
  4. En Security, añade Authenticated Users con permiso Enroll y Autoenroll.
  5. Publica la nueva plantilla: clic derecho en Certificate Templates → New → Certificate Template to Issue, selecciona LDAPS‑DC.

2. Configurar la GPO de auto‑enrollment

  1. Crea o edita una GPO que se aplique a los Domain Controllers.
  2. Ruta: Computer Configuration → Policies → Windows Settings → Security Settings → Public Key Policies → Certificate Services Client – Auto-Enrollment.
  3. Habilita Enroll certificates automatically y Renew expired certificates, update pending certificates, and remove revoked certificates.
  4. En Computer Configuration → Policies → Administrative Templates → System → Group Policy, habilita Turn on Group Policy loopback processing (modo Replace) si la GPO está vinculada a una OU distinta a la de los DC.

3. Forzar la aplicación de la política

gpupdate /force
certutil -pulse

El comando certutil -pulse obliga a que el cliente solicite los certificados pendientes.

4. Verificar la solicitud y la instalación

  1. Abre una sesión PowerShell en el DC Core:
Get-ChildItem -Path Cert:\LocalMachine\My | Where-Object {$_.Subject -like "*CN=YOURDC*"}

Debería aparecer un certificado con la plantilla LDAPS‑DC y los SAN que incluyen el nombre DNS del DC.

  1. Si la solicitud no aparece, revisa el registro de AD CS (Event Viewer → Applications and Services Logs → Microsoft → Windows → CertificateServices‑Client → Operational) para detectar errores de política.

5. Configuración del firewall (si es necesario)

netsh advfirewall firewall add rule name="LDAPS" dir=in action=allow protocol=TCP localport=636

6. Alternativa: uso de certreq con archivo INF

Si prefieres no depender de GPO, crea un archivo ldaps.inf:

[Version]
Signature="$Windows NT$"

[NewRequest]
Subject = "CN=YOURDC"
KeySpec = 1
KeyLength = 2048
Exportable = TRUE
MachineKeySet = TRUE
SMIME = FALSE
PrivateKeyArchive = FALSE
UserProtected = FALSE
UseExistingKeySet = FALSE
ProviderName = "Microsoft RSA SChannel Cryptographic Provider"
ProviderType = 12
RequestType = PKCS10
HashAlgorithm = sha256

[Extensions]
2.5.29.17 = "{text}"
_continue_ = "dns=YOURDC.yourdomain.local&dns=YOURDC"

Ejecuta:

certreq -new ldaps.inf ldaps.req
certreq -submit -config "CAHOST\CAName" ldaps.req ldaps.cer
certreq -accept ldaps.cer

El certificado se instalará en Local Machine\Personal y, si la plantilla permite auto‑enrollment, los SAN se rellenarán automáticamente.

7. Habilitar LDAPS en AD DS

El servicio LDAP ya escucha en 636 siempre que exista un certificado válido en el almacén correcto. No se requieren cambios adicionales en el registro.

Cuándo aplicar esta solución

  • Entorno Core: Cuando los DC no tienen GUI y el MMC de certificados está ausente.
  • Política de seguridad: Cuando la organización requiere que todos los DC usen LDAPS y que los certificados se renueven automáticamente.
  • Fallo de conexión LDAP TLS: Si ldp.exe o cualquier cliente LDAP devuelve “Cannot connect to server” al usar el puerto 636.

No aplicar si ya dispones de una infraestructura de PKI basada en certificados de terceros que no soporta auto‑enrollment de Windows, o si el DC está en una red aislada sin acceso al CA.

Código

# Forzar políticas y solicitar certificado automáticamente
gpupdate /force
certutil -pulse

# Verificar certificado en el almacén local del equipo
Get-ChildItem -Path Cert:\LocalMachine\My |
  Where-Object {$_.Subject -like "*CN=YOURDC*"} |
  Format-List Subject, Thumbprint, NotAfter

# Abrir puerto 636 en el firewall
netsh advfirewall firewall add rule name="LDAPS" dir=in action=allow protocol=TCP localport=636

Verificación

  1. Comprobar que el servicio LDAP escucha en 636
netstat -ano | findstr :636

Debería aparecer una línea con LISTENING y el PID del proceso lsass.exe.

  1. Probar la conexión con LDP

    • Ejecuta ldp.exe desde cualquier máquina Windows.
    • Conecta a YOURDC.yourdomain.local:636 y marca SSL.
    • Si la conexión se establece sin error, el certificado está funcionando.

  2. Validar la cadena de confianza

certutil -verify -urlfetch Cert:\LocalMachine\My\<thumbprint>

No debe haber errores de revocación ni de cadena incompleta.

Notas adicionales

  • Renovación automática: La política de auto‑enrollment renueva el certificado 30 días antes de su expiración. No es necesario programar tareas manuales.
  • Claves exportables: Habilitar Exportable en la plantilla facilita la exportación del certificado para pruebas, pero en producción suele desactivarse por motivos de seguridad.
  • Múltiples SAN: Si el DC tiene varios nombres DNS (por ejemplo, DC01, DC01.contoso.com), añádelos en la sección [Extensions] del INF separados por &dns=.
  • Registro de eventos: Los errores de auto‑enrollment aparecen en el log de System con el origen CertificateServicesClient. Revisar allí ahorra tiempo de diagnóstico.
  • Compatibilidad con versiones futuras: La misma metodología funciona en Windows Server 2022 y versiones posteriores; solo cambia el nombre de la plantilla base si Microsoft introduce una nueva.