Problema

En entornos Windows 11 con TPM habilitado y Secure Boot activo, es frecuente observar en el Visor de eventos la entrada CertificateServicesClient‑CertEnroll (Event ID 87) que indica un fallo de SCEP Certificate enrollment. El mensaje suele incluir:

SCEPDispositionPendingChallenge EnrollStatus(32): EnrollUnknown
Bad Request {"Message":"V2 Protocol AIK certificate requests with P‑256 ECC public keys are not supported..."}
HTTP/1.1 400 Bad Request

A la par pueden aparecer eventos TPM‑WMI (Event ID 1040) que señalan “Pre‑attestation health checks confirm a critical component has failed”. El síntoma visible para el usuario es un RestartPending permanente en Get‑TPM, aunque el TPM aparece como “Ready” en tpm.msc. El problema afecta a la generación automática de certificados AIK (Attestation Identity Key) y, por consiguiente, a cualquier solución que dependa de la cadena de confianza del hardware, como BitLocker, Microsoft Defender for Endpoint o soluciones de gestión de dispositivos.

Causa

Los fallos de SCEP enrollment en Windows 11 se originan típicamente por una combinación de factores:

  1. Incompatibilidad de algoritmos ECC
    Desde la versión 2 del protocolo SCEP, Microsoft descontinúa el soporte para solicitudes AIK con claves P‑256. Si el firmware del TPM expone solo ECC P‑256, el servidor SCEP (por ejemplo, Azure Attestation) rechaza la petición con 400 Bad Request.

  2. Estado inconsistente del TPM
    Después de una actualización de BIOS/UEFI o de una reinstalación limpia, el TPM puede quedar en modo “Ready” pero con flags de reinicio pendientes (RestartPending = True). Esto impide que el subsistema de attestation vuelva a inicializar los objetos de clave.

  3. Claves de arranque seguro corruptas o desincronizadas
    Restablecer las Secure Boot keys sin volver a reprovisionar el TPM deja una brecha entre la base de confianza del firmware y la de Windows. El medidor de arranque (MeasuredBoot) reporta valores falsos para campos como VirtualSecureMemory o EkCertEccP384IsAvailable.

  4. Política de grupo o configuración de MDM que fuerza SCEP con ECC P‑256
    Algunas plantillas de inscripción (por ejemplo, templates/Aik/scep) están configuradas para solicitar P‑256 por defecto. Si la política no se actualiza, el cliente sigue enviando la petición incompatible.

  5. Firmware TPM que no expone claves ECC P‑384
    Los módulos TPM más antiguos o con firmware desactualizado solo soportan P‑256. Sin una actualización del firmware, el sistema nunca podrá generar la clave requerida.

Solución

La estrategia consiste en alinear tres componentes: firmware TPM, configuración de SCEP y estado del TPM en Windows. Los pasos siguientes cubren los escenarios más habituales y pueden combinarse según el diagnóstico previo.

1. Verificar y actualizar el firmware del TPM

  1. Accede al BIOS/UEFI y localiza la sección de TPM/Firmware Update.
  2. Si el fabricante ofrece una versión que menciona soporte para ECC P‑384 o “TPM 2.0 firmware 5.x”, aplícala.
  3. Reinicia y confirma que tpm.msc muestra Version ≥ 2.0 y Specification Revision ≥ 1.3.

2. Restablecer y reprovisionar el TPM

Ejecuta los siguientes comandos en PowerShell con privilegios de administrador:

# Borrar la configuración actual del TPM (preserva la clave de arranque)
Clear‑TPM -Force

# Reiniciar el equipo para que el TPM se inicialice limpio
shutdown /r /t 0

Después del reinicio, verifica que Get‑TPM muestre RestartPending : False. Si sigue activo, repite el borrado y, en la BIOS, habilita Clear TPM on next boot antes del arranque.

3. Regenerar claves de Secure Boot

  1. En el BIOS, selecciona Restore Factory Keys o Reset Secure Boot Keys.
  2. Guarda y reinicia.
  3. En Windows, abre bcdedit /set {current} safeboot minimal y arranca en modo seguro para forzar la re‑creación de los certificados de arranque. Luego vuelve al modo normal con bcdedit /deletevalue {current} safeboot.

4. Ajustar la plantilla SCEP para usar ECC P‑384

Si la organización controla el servidor SCEP (Azure Attestation, Intune, etc.):

  • Modifica la plantilla templates/Aik/scep para que el campo Key Algorithm sea ECDSA_P384.
  • Publica la nueva plantilla y asegura que los clientes reciban la política actualizada mediante gpupdate /force o la sincronización de MDM.

Si no tienes control del servidor, la alternativa es forzar al cliente a usar RSA 2048 (compatible con todas las versiones). En PowerShell:

# Cambiar la configuración local de la política de inscripción
Set-ItemProperty -Path "HKLM:\SOFTWARE\Microsoft\Cryptography\CertificateTemplateCache\{GUID}" -Name "KeySpec" -Value 1

Reemplaza {GUID} por el identificador de la plantilla que está fallando (obtenible con certutil -template).

5. Confirmar la disponibilidad de certificados ECC P‑384

Ejecuta:

Get-ChildItem -Path Cert:\LocalMachine\My | Where-Object {$_.PublicKey.Oid.FriendlyName -eq "ECC P-384"}

Si el listado está vacío, el TPM aún no está exponiendo la clave adecuada; vuelve al paso 1.

Cuándo aplicar esta solución

  • Síntomas: Event ID 87 con mensaje “V2 Protocol AIK certificate requests with P‑256 ECC public keys are not supported”, RestartPending = True, y campos de MeasuredBoot marcados como false.
  • Entorno: Windows 11, TPM 2.0 habilitado, Secure Boot activo, uso de SCEP para AIK (Azure Attestation, Intune, etc.).
  • No aplicar: Si el servidor SCEP solo acepta RSA y la política ya está configurada para RSA, o si el hardware no soporta ECC P‑384 y no es posible actualizar el firmware. En esos casos, la solución consiste en migrar a RSA en lugar de intentar forzar ECC P‑384.

Código

# 1. Borrar TPM y reiniciar
Clear-TPM -Force
shutdown /r /t 0

# 2. Verificar estado después del arranque
Get-TPM | Format-List RestartPending, TpmPresent, ManufacturerId

# 3. Forzar uso de RSA 2048 en la plantilla (ejemplo)
$tplGuid = (certutil -template | Where-Object {$_ -match "MyTemplate"}).Split()[0]
Set-ItemProperty -Path "HKLM:\SOFTWARE\Microsoft\Cryptography\CertificateTemplateCache\$tplGuid" -Name "KeySpec" -Value 1

Verificación

  1. Visor de eventos: Busca nuevamente CertificateServicesClient‑CertEnroll. La entrada debe desaparecer o cambiar a “Successful”.
  2. PowerShell: Ejecuta Get-TPM y confirma RestartPending : False.
  3. Medición de arranque: Revisa los archivos bajo C:\Windows\System32\MeasuredBoot y verifica que los campos VirtualSecureMemory, SecureCorePCCompliant y los certificados ECC aparecen como true.
  4. AIK: Usa certutil -getattestation (o la herramienta de tu MDM) para comprobar que el certificado AIK se ha emitido sin errores.

Notas adicionales

  • Algunos fabricantes (ASUS, Dell) requieren habilitar explícitamente “TPM Firmware Update” en la BIOS; de lo contrario, el instalador de firmware será ignorado.
  • Después de una actualización de BIOS, es buena práctica volver a ejecutar gpupdate /force para que las políticas de seguridad se vuelvan a aplicar.
  • Si el error persiste y el servidor SCEP no puede modificarse, considera desactivar temporalmente la inscripción automática de AIK y gestionar los certificados manualmente mediante certreq.
  • Mantener una copia de la clave de recuperación del TPM (tpmtool.exe /export) facilita la recuperación en caso de que el borrado del TPM cause pérdida de datos cifrados (BitLocker).

Con estos pasos, la mayoría de los entornos Windows 11 con TPM 2.0 pueden volver a generar certificados AIK válidos y eliminar los eventos de error que saturan el Visor de eventos.