Cuando la directiva de inscripción de certificados (Certificate Enrollment Policy, CEP) se publica en un puerto HTTPS no estándar, los clientes dejan de mostrar plantillas disponibles y la inscripción manual muestra el mensaje “Certificate types are not available”. A continuación encontrarás un análisis exhaustivo de las causas, los pasos de diagnóstico y las buenas prácticas para corregir este problema sin reinstalar la autoridad de certificación.
Modelo de arquitectura y flujo de inscripción
En un entorno Active Directory moderno, la obtención de certificados X.509 pasa por varias capas:
- El cliente localiza la CEP a través de la directiva de grupo, la descarga y la almacena en caché.
- El cliente autentica la sesión con el rol Certificate Enrollment Web Services (CEP y CES) usando Kerberos o NTLM, según la configuración.
- Se recupera la lista de plantillas publicadas por la CA para ese usuario o equipo.
- El cliente crea o selecciona la solicitud (CSR) y la envía al servidor CES.
- La CA procesa la petición y devuelve el certificado, que se instala en el almacén local.
¿Por qué falla al usar un puerto personalizado?
El puerto 443 está preconfigurado en muchos componentes de Windows. Cuando cambias a 50000 (u otro), introduces dependencias que no siempre se actualizan de forma automática:
- La URL del CEP (
https://servidor:50000/ADPolicyProviderCEPKerberos/service.svc/CEP
) debe actualizarse en todas las políticas de grupo aplicables. - El Service Principal Name (SPN) del servicio web deja de coincidir con lo que el cliente espera: Kerberos requiere que el SPN incluya host + puerto.
- Algunos cortafuegos internos y filtros de inspección TLS bloquean puertos altos que no estén en la lista de permitidos.
- Las bibliotecas cliente de enrolamiento (
certenroll.dll
) almacenan en caché la última CEP válida; si la caché no se limpia, continúan buscando la vieja ruta.
Señales de alerta en el registro de eventos
Antes de tocar nada comprueba estos registros:
Registro | ID de evento frecuente | Descripción típica |
---|---|---|
Microsoft‑Windows‑CertificateServicesClient‑CertificateEnrollment | 0x500 (0) / 0x30 | Fallo al descargar directiva (URL incorrecta o inaccesible) |
Microsoft‑Windows‑CertificateServicesClient‑UserTask | 86 / 76 | Plantilla XYZ no disponible para el usuario |
System > Schannel | 36874 / 36888 | Error de negociación TLS con el servidor CEP |
Paso a paso para la solución de problemas
Comprobar la ruta de la directiva
certutil –policyserver "https://servidor:50000/ADPolicyProviderCEPKerberos/service.svc/CEP"
Este comando realiza la descarga completa de la directiva y verifica la autenticidad del certificado servidor. Si muestra “Error 0x80070057 (EINVALIDARG)” o “0x80072F8F (ERRORINTERNETSECCERTDATEINVALID)”, el problema está en la URL o en la cadena de confianza.
Validar la autenticación Kerberos/NTLM
- Ejecuta
klist get HTTP/servidor:50000
. Si la obtención del ticket falla, el SPN del servicio es incorrecto. - Comprueba con
setspn -L CuentaServicio
que aparezcaHTTP/servidor:50000
oHTTP/FQDN:50000
. - Si se usa autenticación basada en certificados o cuentas locales, asegúrate de que el binding IIS permita TLS 1.2 y suites modernas.
Revisar la caché de enrolamiento
Los clientes guardan la CEP en %SystemRoot%\System32\GroupPolicy\Machine\Registry.pol
y %ProgramData%\Microsoft\Crypto\RSA\MachineKeys
. Para forzar una actualización:
gpupdate /force
certutil –policy –urlfetch –verify
Confirmar los permisos de plantilla
Aun cuando los usuarios tengan Read, Enroll y Autoenroll, la versión de la plantilla debe ser compatible con la CA (v2 mínimo en Windows Server 2008; v3/v4 para características avanzadas). Utiliza certtmpl.msc
:
- Cambia la compatibilidad en la pestaña General.
- Pulsa Reenviar a la CA para que la vuelva a publicar.
Inspeccionar la configuración de grupo (GPO)
Confirma que en Computer Configuration › Policies › Windows Settings › Security Settings › Public Key Policies exista la preferencia:
- Automatically enroll and renew certificates = Enabled
- Update certificates that use certificate templates = Yes
Pruebas de fuego rápidas
certutil –ping CA
para comprobar RPC DCOM/135 y 445.pkiwiz.exe
oPKIView.msc
para auditoría global AIA/CDP.- Escaneo de puertos con
Test‑NetConnection servidor –Port 50000
.
Errores típicos y cómo resolverlos
El servidor CEP responde con 404
Verifica en IIS que el virtual directory /ADPolicyProviderCEPKerberos
esté asignado correctamente al puerto 50000 y que el binding utilice el certificado adecuado (CN coincidente).
Los usuarios externos no ven plantillas pero los internos sí
Probablemente el Firewall de Borde permite el tráfico 443 pero no 50000. Solución: realizar port forwarding o encapsular en 443 con Application Request Routing de IIS.
Event ID 13: The certificate XYZ already exists in store
Significa que la inscripción previa se completó pero no se eliminó el estado pendiente; usa certutil –delstore My "serial"
para limpiar.
Checklist definitiva antes de reinstalar la PKI
Elemento | ¿Por qué importa? | Herramienta de validación |
---|---|---|
Cadena de confianza OK | Sin raíz confiable no hay TLS mutuo | certutil –verify –urlfetch |
SPN incluye puerto | Kerberos solo funciona con SPN exacto | setspn -Q "HTTP/servidor:50000" |
CEP accesible | Proveedor de directivas devuelve plantillas | certutil –policyserver |
Plantillas publicadas | CA debe conocerlas para exponerlas | certtmpl.msc |
GPO actualizada | Ruta de CEP distribuida a los equipos | gpresult /R |
Buenas prácticas para entornos productivos
Aislar la PKI en una VLAN segura
Facilita el trazado de paquetes y minimiza la superficie de ataque. Un switch con ACL permite abrir únicamente:
- TCP 135, 445, RPC dinámico
- TCP 80 (CRL HTTP), 443 o 50000 (CEP/CES)
Documentar cada cambio
Con un puerto no estándar es fácil que las futuras auditorías olviden ajustar scripts y automatizaciones. Mantén un archivo Run Book con:
- Fecha y autor del cambio
- SPN registrados
- Thumbprint de los certificados usados en IIS
- Scripts PowerShell de aprovisionamiento
Automatizar las pruebas después de parches
Actualizaciones de seguridad de IIS o del protocolo TLS pueden revertir bindings o deshabilitar suites criptográficas antiguas. Implementa un job en Azure DevOps o GitHub Actions que ejecute semanalmente:
Invoke-WebRequest -Uri "https://servidor:50000/ADPolicyProviderCEPKerberos/service.svc/CEP" -UseDefaultCredentials
y notifique por correo si el código de estado HTTP ≠ 200.
Conclusión
Perder la lista de plantillas tras mover la CEP a un puerto personalizado suele deberse a un detalle de configuración — SPN incompleto, GPO desactualizada o certificado de servidor erróneo —, más que a un fallo intrínseco de AD CS. Siguiendo la lista de verificación de este artículo podrás restaurar la visibilidad de las plantillas en minutos y evitar la reinstalación de la PKI. Solo opta por reconstruir la infraestructura cuando:
- Los registros evidencian corrupción de la base de datos de la CA,
- Se han perdido claves privadas de la CA, o
- La CA está instalada en un sistema operativo sin soporte.
Mantener documentación clara y tests automatizados es la mejor defensa frente a problemas similares en el futuro.