Si administras entornos VMware con Secure Boot habilitado, hay una fecha que debes tener en el radar: junio de 2026. Microsoft está renovando su cadena de certificados Secure Boot y como administradores de infraestructura hay pasos que ejecutar para asegurarse de que las VMs queden preparadas.

Este tema ha generado bastante ruido en la comunidad con titulares del estilo «tus VMs van a dejar de bootear en junio» que más que informar, alarman. Sin embargo, es importante aclarar que la expiración de un certificado y su revocación son eventos distintos — sus VMs no van a dejar de bootear de un día para otro. Lo que sí se pierde sin actualizar es la capacidad de recibir futuras actualizaciones de seguridad de Secure Boot, y eso merece atención planificada, no urgencia de pánico.

La buena noticia es que Broadcom ya liberó ESXi 8.0 P09 con la solución automática. Para la mayoría de los entornos, la remediación es tan simple como parchear el host y reiniciar las VMs. En este artículo vamos a ver qué está pasando, cómo identificar las VMs afectadas, y cómo ejecutar la remediación paso a paso según el escenario.

Este contenido está basado en la documentación oficial de Broadcom y Microsoft:

• Broadcom KB 423893
• Broadcom KB 423919
• Microsoft KB 5062713

⚠️ ¡IMPORTANTE!
Este artículo es una guía informativa basada en la documentación oficial publicada por Broadcom y Microsoft a la fecha de publicación. Su objetivo es ayudarles a entender el problema y tener una referencia clara del proceso de remediación. Dicho esto, cada ambiente es diferente — versiones de ESXi, configuraciones de vTPM, cifrado de disco, hardware virtual — y es responsabilidad de cada administrador validar los pasos contra la documentación oficial vigente antes de ejecutar cualquier cambio en producción. Los KBs referenciados se actualizan periódicamente; siempre verifiquen la versión más reciente.

Contenido

1. Contenido
2. ¿Qué está pasando?
3. La cadena de confianza de Secure Boot
4. Síntomas
5. Las dos causas raíz
6. ¿Cuál es el impacto real hoy?
7. Productos y versiones afectadas
8. Tabla de certificados por versión de ESXi
9. Matriz de remediación
10. SOLUCIÓN A — ESXi 8.0 P09 (Silent PK Update)
11. SOLUCIÓN B — Actualización Manual vUEFI
12. SOLUCIÓN C — VMX Configuration para Linux con vTPM
13. VMs Windows con vTPM — Sin solución aún
14. Scripts adjuntos al KB 423893
15. Resumen

¿Qué está pasando?

Microsoft está renovando su cadena de certificados de Secure Boot. Los certificados que vienen usando desde 2011 están próximos a expirar — el KEK CA 2011 vence en junio 2026 — y necesitan ser reemplazados por los nuevos certificados 2023 en todas las VMs que tienen Secure Boot habilitado.

Hasta ahí todo suena normal. El problema específico en entornos VMware es que la mayoría de las VMs existentes tienen el Platform Key (PK) configurado como NULL (VMW.NULLPK) por diseño en versiones anteriores de ESXi. Y ese PK null es el que bloquea todo — porque sin un PK válido, la plataforma no puede autorizar ninguna actualización en la cadena de Secure Boot.

Dicho de otra forma: Windows quiere actualizar los certificados, intenta hacerlo, pero el firmware de la VM le cierra la puerta desde la raíz.

La cadena de confianza de Secure Boot

Antes de entrar a la remediación, vale la pena entender bien la cadena. Y es que si no entienden cómo funciona, no van a entender por qué el PK null es tan crítico.

Secure Boot funciona como una cadena de confianza jerárquica. Si un eslabón falla, todo lo que está debajo también falla:

PK  (Platform Key)           ← RAÍZ. Si es NULL, nada más funciona.
 └── KEK (Key Exchange Key)  ← Autoriza cambios a DB y DBX
      ├── DB  (Allowed)      ← Define qué puede bootear
      └── DBX (Revoked)      ← Define qué está bloqueado

Con el PK null, la plataforma no puede autorizar ningún cambio al KEK. Sin KEK actualizado, no se pueden actualizar DB ni DBX. Y sin esas actualizaciones, Windows no puede instalar los nuevos certificados 2023 — por eso el scheduled task de Windows falla silenciosamente y el Event ID 1801 sigue apareciendo.

Síntomas

Estos son los síntomas que pueden estar viendo en sus ambientes:

• Event ID 1801 en Windows Event Viewer — certificados disponibles pero no aplicados al firmware
• Event ID 1769 — error invalid access to memory location al intentar actualizar KEK 2023
• Falta Microsoft Corporation KEK 2K CA 2023 en la base KEK de la VM
• Falla al instalar DB, DBX o certificados Option ROM actualizados
• El update funciona en algunas VMs pero falla en otras con diferente versión de ESXi o HW Version
• Secure Boot sigue funcionando pero futuras revocaciones DBX no se pueden aplicar

Las dos causas raíz

Hay dos causas documentadas en los KBs oficiales. Son relacionadas pero distintas — y entender la diferencia importa a la hora de elegir la remediación.

Causa 1 — KEK expirado o faltante

Microsoft Corporation KEK CA 2011 expira en junio 2026. Sin KEK válido no se pueden autorizar actualizaciones de DB ni revocaciones DBX. Windows reporta Event ID 1801 durante el intento de remediación.

Causa 2 — Platform Key NULL (la causa más profunda)

En VMs creadas en ESXi anteriores a 9.0, el PK se inicializa como VMW.NULLPK por diseño. Con el PK null la plataforma no puede autorizar ningún cambio al KEK, bloqueando toda la cadena desde la raíz. Esta es la causa que VMware resuelve con el parche de ESXi 8.0 P09.

KB 423919 — «The Platform Key (PK) on virtual machines has an invalid signature, which causes updates to the Key Exchange Key (KEK) database to fail. As a result, the automated Secure Boot update process fails and reports error events or logs.»

¿Cuál es el impacto real hoy?

Acá es donde muchos se alarman más de la cuenta. Vamos por partes:

Las VMs siguen booteando después de la expiración. Secure Boot no verifica la fecha de expiración de los certificados durante el proceso de boot — el impacto al boot ocurre solo si Microsoft revoca activamente los certificados vencidos, y a la fecha de este artículo no hay una fecha confirmada para eso.

No hay emergencia inmediata de boot, pero sí hay una ventana de tiempo para remediar antes de que Microsoft tome esa decisión.

Productos y versiones afectadas

VMs con HW Version 12 o anterior no soportan Secure Boot — no aplica este problema. VMs en HW Version 13 con Secure Boot habilitado requieren upgrade a HW Version 14+ antes de proceder con la actualización del PK.

Tabla de certificados por versión de ESXi

Esta tabla es fundamental para entender qué certificados tiene cada VM según en qué versión de ESXi fue creada. El estado del PK es lo que más importa revisar:

Como ven, el VMW.NULLPK aparece en prácticamente todas las VMs creadas antes de ESXi 9.0 o ESXi 8.0 P09 (Parche liberado recientemente). Es el denominador común del problema.

Matriz de remediación

Con el contexto claro, acá está la matriz que define qué hacer en cada escenario según la configuración de la VM. El escenario más común en producción es el #2 — Secure Boot habilitado y sin vTPM — y es exactamente el que resuelve el parche de ESXi 8.0 P09:

SOLUCIÓN A — ESXi 8.0 P09 (Silent PK Update)

Esta es la solución principal y la más simple para los escenarios 1 y 2. ESXi 8.0 P09 ya fue liberado e incluye la capacidad de Silent PK Update. Asi que la formas mas facil solucionar el problema es parchando los hosts a esta version liberada el dia 27 de Mayo de 2026.

¿Qué hace el parche exactamente?

Durante el reboot de una VM con vTPM deshabilitado, ESXi detecta que el PK es VMW.NULLPK y lo reemplaza automáticamente por Windows OEM Devices PK — sin intervención adicional del administrador, sin tocar el Guest OS, sin scripts dentro de la VM.

Ahora bien, una vez que el PK es válido, ¿quién actualiza el KEK y el DB? Acá es donde entra Microsoft. Según el KB 5062713, Windows tiene un scheduled task que corre cada 12 horas y aplica los certificados automáticamente en este orden secuencial — cada paso debe completar antes de pasar al siguiente:

1. Aplica Windows UEFI CA 2023 → DB
2. Si el dispositivo tiene Microsoft Corporation UEFI CA 2011 en el DB, aplica Microsoft Option ROM UEFI CA 2023 y Microsoft UEFI CA 2023 → DB
3. Agrega Microsoft Corporation KEK 2K CA 2023 → KEK
4. Actualiza el Windows Boot Manager al firmado con Windows UEFI CA 2023 (este último paso requiere un restart adicional — se completa en el próximo reboot natural del sistema)

El cliente no necesita intervenir en KEK ni DB. Es completamente automático una vez que ESXi corrige el PK. VMware arregla el PK, Microsoft arregla el resto.

El KB de Microsoft lo aclara perfectamente para entornos virtualizados:

MS KB 5062713 — «For Windows running long term in a VM, the updates can be applied through Windows like any other devices, if the virtualized firmware supports Secure Boot updates.»

La frase clave es «if the virtualized firmware supports Secure Boot updates» — que es exactamente lo que estaba bloqueado con el VMW.NULLPK y lo que ESXi 8.0 P09 corrige.

Con esto claro, vamos a los pasos.

Paso 1 — Identificar las VMs afectadas

Lo primero es saber con qué VMs estamos trabajando. Tienen dos opciones:

Opción A — vSphere Client (UI)

Navegar al cluster o host → pestaña VMs → clic derecho en encabezado de columna → Show/Hide Columns → activar «Secure Boot». Esto agrega una columna con el estado para todas las VMs del inventario de forma inmediata.

Opción B — PowerCLI

# 1. Conectar a vCenter
Connect-VIServer -Name <vc_fqdn / ip_address> -User <username>
# 2. Listar VMs con Secure Boot habilitado
Get-VM | Where-Object {
    $_.ExtensionData.Config.BootOptions.EfiSecureBootEnabled -eq $true
} | Select Name
# 3. Listar VMs con vTPM habilitado
Get-VM | Where-Object {
    $_.ExtensionData.Config.Hardware.Device | Where-Object {
        $_.GetType().Name -eq "VirtualTPM"
    }
}

El KB 423893 adjunta el script SecureBootExportVMList.ps1 que exporta un CSV completo con columnas: VMName, PowerStatus, VMHardwareVersion, SecureBoot, vTPM. Es lo recomendado para entornos con muchas VMs porque les da todo el contexto necesario en un solo archivo.

Paso 2 — Verificar que el PK es NULL (dentro del Guest OS)

Antes de reiniciar masivamente, vale la pena confirmar que las VMs efectivamente tienen el PK inválido. Esto se hace desde adentro del Guest OS.

En Linux

mokutil --pk
# Resultado en BLANCO → PK es NULL, necesita actualización
# Resultado con contenido → PK ya es válido, no requiere acción

En Windows (PowerShell como Administrador)

$pk = Get-SecureBootUEFI -Name PK
$bytes = $pk.Bytes
$cert = $bytes[44..($bytes.Length-1)]
[IO.File]::WriteAllBytes("PK.der", $cert)
certutil -dump PK.der

El PK es inválido si aparece alguno de estos dos resultados:

# Resultado 1 — PK completamente NULL:
Cannot index into a null array.
At line:1 char:1
+ $cert[44..($bytes.Length-1)]
    + CategoryInfo : InvalidOperation: (:) [], RuntimeException
    + FullyQualifiedErrorId : NullArray
# Resultado 2 — PK inválido (solo 45 bytes):
PS C:\> certutil -dump PK.der
00 .
CertUtil: -dump command completed successfully.
PS C:\> $bytes.Length
45

Paso 3 — Reiniciar las VMs

Con el host en ESXi 8.0 P09 confirmado y las VMs identificadas con vTPM deshabilitado, el único paso que queda es reiniciarlas. Nada más. El parche hace el resto durante el reboot.

VM individual

Get-VM <VM Name> | Restart-VMGuest -Confirm:$false

Cluster completo

Get-Cluster <my-cluster> | Get-VM | Restart-VMGuest -Confirm:$false

📝 Script incluido en el KB

El KB 423893 adjunta el script RestartMultipleVMs.ps1 que acepta un archivo .txt con los nombres de las VMs a reiniciar, se conecta al vCenter, ejecuta el reboot en cada una y exporta el resultado en CSV con columnas: VMName, PowerStatus, GuestOSRebootStatus.

Ejemplo de salida del script:

Paso 4 — Verificar que todo quedó correcto

Una vez reiniciadas las VMs, hay dos cosas que verificar: que el PK fue corregido por ESXi, y que el scheduled task de Microsoft ya aplicó el KEK y DB 2023.

Para el PK, repetir la verificación del Paso 2 dentro del Guest OS. El resultado ya no debe ser en blanco (Linux) ni mostrar NullArray o "00" (Windows).

Para confirmar que el scheduled task de Microsoft aplicó KEK y DB 2023 — recuerden que corre cada 12 horas, así que puede tomar un tiempo:

Windows

([System.Text.Encoding]::ASCII.GetString((Get-SecureBootUEFI db).bytes) -match 'Windows UEFI CA 2023')
# TRUE  = aplicado correctamente ✅
# FALSE = aún pendiente, esperar hasta 12 horas

Linux

mokutil --db
# o
sudo efi-readvar -v db
# Buscar en el output: "Windows UEFI CA 2023", "Microsoft UEFI CA 2023"

Monitoreo via Event Viewer en Windows

El propio Windows les dice cuándo terminó. Busquen estos Event IDs:

Cuando vean el Event ID 1808, el proceso completó exitosamente y pueden cerrar este ticket.

SOLUCIÓN B — Actualización Manual vUEFI

Si no pueden actualizar el host a ESXi 8.0 P09, esta es la alternativa. Aplica para:

• Hosts en ESXi 7.x — sin parche automatizado disponible porque ya está fuera de General Support
• Hosts en ESXi 8.0 P08 o anterior que no pueden moverse a P09 aún
• Hosts en ESXi 9.x con VMs en escenario 2 (Secure Boot Enabled + vTPM Disabled)

El proceso es más manual pero está completamente documentado en el KB 423919. La idea es agregarle temporalmente un disco FAT32 a la VM con el certificado correcto, bootear al vUEFI y desde ahí enrollar el nuevo PK.

⚠️ Antes de empezar — CAUTION del KB 423919

Si la VM tiene vTPM y disk encryption (BitLocker en Windows o LUKS en Linux) sellado a TPM PCR registers, no se salten estos pasos preparatorios: crear snapshot de la VM, guardar el recovery key, o deshabilitar temporalmente el cifrado sellado al TPM. Hacerlo sin esta preparación puede dejar el sistema en BitLocker recovery y sin poder bootear.

PRE-PASO — Preparar el disco FAT32 con el certificado PK

Se necesita un disco temporal FAT32 con el archivo WindowsOEMDevicesPK.der para que la VM lo lea desde la interfaz vUEFI. Esto hay que hacerlo antes de apagar la VM.

En Linux (Ubuntu/Debian)

# 1. Agregar disco virtual de 128 MB a la VM desde el vCenter e identificarlo
lsblk
# Asumimos que aparece como /dev/sdb
# 2. Formatear como FAT32
sudo mkfs.vfat -F 32 -n KEYUPDATE /dev/sdb
# 3. Crear punto de montaje y montar
sudo mkdir -p /mnt/keys
sudo mount /dev/sdb /mnt/keys
# 4. Verificar que quedó montado
mount | grep keys
# 5. Descargar el certificado PK desde Microsoft:
# https://github.com/microsoft/secureboot_objects/blob/main/PreSignedObjects/PK/Certificate/WindowsOEMDevicesPK.der
# 6. Copiar al disco y desmontar
sudo cp WindowsOEMDevicesPK.der /mnt/keys
sudo umount /mnt/keys

En Windows

1. Agregar disco virtual de 128 MB a la VM.
2. Formatear como FAT32:
   - GUI: Win + R → diskmgmt.msc → formatear el nuevo disco como FAT32
   - CMD: format /FS:FAT32 X:  (reemplazar X: con la letra del disco)
3. Descargar el certificado PK desde Microsoft:
   https://github.com/microsoft/secureboot_objects/blob/main/PreSignedObjects/PK/Certificate/WindowsOEMDevicesPK.der
4. Copiar WindowsOEMDevicesPK.der al volumen FAT32 de 128 MB.

Proceso — Actualización del PK via vUEFI

Con el disco FAT32 listo y adjunto a la VM, seguimos estos pasos:

1. Apagar la VM.
2. Tomar snapshot de la VM.
3. Confirmar que el disco FAT32 preparado está adjunto a la VM.
4. Habilitar Secure Boot variable update sin autenticación.
   Seleccionar la VM en vSphere Client → navegar a:
   - vCenter 7.x: Edit Settings → VM Options → Advanced → Edit Configuration
   - vCenter 8.x/9.x: Edit Settings → Advanced Parameters
   Agregar:
     Nombre: uefi.allowAuthBypass
     Valor:  TRUE
5. Forzar entrada al Setup Mode:
   Edit Settings → VM Options → Boot Options
   Habilitar "Force EFI Setup"
6. Encender la VM.
   Arrancará directamente en la interfaz vUEFI en lugar del OS.
7. Navegar en la interfaz vUEFI y enrollar el PK:
   Enter Setup
    └── Secure Boot Configuration
         └── PK Options
              └── Enroll PK
                   ├── Seleccionar WindowsOEMDevicesPK.der desde el disco FAT32
                   ├── Review
                   └── Commit Changes and Exit
8. Remover el parámetro VMX agregado en el paso 4:
   Eliminar uefi.allowAuthBypass = TRUE desde Advanced Parameters.
9. Remover el disco FAT32 de la VM.
10. Reiniciar la VM — ahora bootea normalmente con el PK corregido.
11. Verificar que el PK fue actualizado correctamente:
    - Linux:   mokutil --pk  (debe retornar contenido, ya no en blanco)
    - Windows: ejecutar nuevamente el bloque PowerShell del Paso 2
               (debe mostrar un certificado válido, no "00" ni NullArray)

Una vez el PK es válido, el scheduled task de Microsoft descrito en la Solución A aplica el KEK y DB 2023 automáticamente en las siguientes 12 horas — el flujo de verificación es exactamente el mismo.

Actualización Manual del KEK

Para escenarios donde el scheduled task de Microsoft no puede correr — principalmente VMs Linux o entornos sin Windows Update activo — el KEK también puede actualizarse manualmente usando el mismo mecanismo del disco FAT32.

1. Descargar el certificado KEK 2023 desde Microsoft:
https://go.microsoft.com/fwlink/?linkid=2239775
2. Convertir a formato DER
openssl x509 -inform der -in KEK.cer -outform der -out KEK-2023.der
3. Copiar KEK-2023.der al disco FAT32
4. Bootear la VM al EFI Setup nuevamente
   (repetir pasos 4, 5 y 6 del proceso anterior)
5. Navegar en vUEFI y enrollar el KEK:
   Secure Boot Configuration
    └── KEK Options
         └── Enroll KEK
              ├── Seleccionar KEK-2023.der
              └── Commit Changes and Exit

Troubleshooting — Error al aplicar el certificado PK

Por si pasa algún problema, la documentación oficial nos dice. Si al intentar enrollar el PK aparece este error:

Only DER encoded certificate file (*.cer/der/crt) is supported

Probablemente el archivo se corrompió durante la descarga. Descargarlo nuevamente. Como alternativa, descargar la versión PEM y convertirla manualmente:

# Descargar versión PEM desde:
# https://go.microsoft.com/fwlink/?linkid=2255361
# Convertir a DER
openssl x509 -inform der -in PK.cer -outform der -out PK.der

SOLUCIÓN C — VMX Configuration para Linux con vTPM

Esta solución aplica para el Escenario 3 en ESXi 8.0 P09: VMs Linux con Secure Boot habilitado y vTPM habilitado. Es un punto medio entre la automatización del parche y el proceso manual completo del vUEFI.

⚠️ Antes de empezar — CAUTION del KB 423893

Si hay LUKS sellado a TPM PCR registers, seguir los pasos preparatorios: crear snapshot, guardar recovery key, o deshabilitar el cifrado sellado al TPM antes de proceder.

🚨 Solo para Linux

Este método aplica únicamente para VMs Linux con vTPM habilitado. Para Windows con vTPM, Broadcom recomienda esperar la solución automatizada — más detalle en la siguiente sección.

# 1. Suspender aplicaciones TPM dentro del Guest OS
#    (seguir documentación específica del OS o aplicación)
# 2. Apagar la VM
# 3. Conectar a vCenter
Connect-VIServer -Name <vc_fqdn / ip_address> -User <username>
# 4a. Agregar parámetro advanced — VM individual
Get-VM <VM Name> | New-AdvancedSetting `
    -Name 'uefi.secureBoot.PK.resetOnce' `
    -Value "TRUE" `
    -Confirm:$false
# 4b. O para todas las VMs de un Cluster (deben estar apagadas)
Get-Cluster <my-cluster> | Get-VM | New-AdvancedSetting `
    -Name 'uefi.secureBoot.PK.resetOnce' `
    -Value "TRUE" `
    -Confirm:$false
# 5. Encender la VM
# 6. Re-habilitar aplicaciones TPM dentro del Guest OS

📝 Script incluido en el KB

El KB 423893 adjunta el script AddResetOnceVMAdvancedParam.ps1 que acepta una lista de VMs en archivo .txt, agrega el parámetro solo en VMs que estén apagadas y tengan vTPM habilitado, y exporta el resultado en CSV. Importante: el script muestra una advertencia explícita sobre el riesgo de BitLocker/LUKS y solicita confirmación y/n antes de proceder — no se salten esa advertencia.

Ejemplo de salida del script:

VMs Windows con vTPM — Sin solución aún

Este es el escenario donde hay que tener paciencia. El KB 423893 es muy explícito: Broadcom recomienda esperar la solución automatizada para VMs Windows con vTPM habilitado.

¿Por qué no hacer el update manual igual? Porque actualizar el PK desde fuera del Guest OS en una VM Windows con vTPM activo altera las variables de Secure Boot y las mediciones del vTPM sin que el OS tenga conocimiento — y eso puede dejar el sistema en BitLocker recovery, requiriendo la recovery key para poder volver a bootear. No es un riesgo que valga la pena tomar cuando la solución automatizada está en camino.

La solución planificada se llama Capsule PK Update y está pendiente de liberación en:

• Próximo patch de ESXi 8.x
• Próximo patch de ESXi 9.1.x

El KB 423893 se actualizará cuando estos patches estén disponibles.

Scripts adjuntos al KB 423893

Los tres scripts están disponibles para descarga directamente en el KB 423893. Vale la pena tenerlos a la mano antes de arrancar cualquier remediación:

Conclusion

La transición de certificados Secure Boot de Microsoft es un proceso de ciclo de vida normal que la industria maneja periódicamente. Lo que hace este caso particular es que requiere coordinación entre el firmware virtual de VMware y el mecanismo de actualización del guest OS de Microsoft — y esa coordinación tiene matices dependiendo de la versión de ESXi y la configuración de la VM.
VMware by Broadcom está liderando la solución con múltiples mecanismos de automatización en camino. Mientras tanto, los mecanismo de remediacion Automatico y workaround manual está bien documentados.

El resumen de lo que hay que hacer:

¿El host está en ESXi 8.0 P09 o superior?
│
├── SÍ → ¿La VM tiene vTPM habilitado?
│         │
│         ├── NO  → ✅ Reiniciar la VM
│         │         ESXi corrige el PK automáticamente durante el reboot.
│         │         Microsoft Scheduled Task aplica KEK + DB 2023
│         │         en las siguientes 12 horas. Sin intervención adicional.
│         │
│         ├── SÍ (Linux)   → Solución C — VMX Configuration
│         │
│         └── SÍ (Windows) → ⏳ Esperar Capsule Update
│                             (riesgo de BitLocker recovery si se hace manual)
│
└── NO → ESXi 7.x o 8.0 ≤ P08
          └── Solución B — Actualización Manual vUEFI (KB 423919)
              Nota: vSphere 7 está fuera de General Support —
              no habrá parches automatizados para esa versión.

⚠️ ¡IMPORTANTE!
Este artículo es una guía informativa basada en la documentación oficial publicada por Broadcom y Microsoft a la fecha de publicación. Su objetivo es ayudarles a entender el problema y tener una referencia clara del proceso de remediación. Dicho esto, cada ambiente es diferente — versiones de ESXi, configuraciones de vTPM, cifrado de disco, hardware virtual — y es responsabilidad de cada administrador validar los pasos contra la documentación oficial vigente antes de ejecutar cualquier cambio en producción. Los KBs referenciados se actualizan periódicamente; siempre verifiquen la versión más reciente.