19 de May de 2026

Não ignore esse aviso do Proxmox antes de junho de 2026

Faltam menos de 30 dias. Se você administra Proxmox e nunca ouviu falar do enrollment de certificados Microsoft 2023, esse artigo é prioridade pra hoje.

Foi durante uma live migration de rotina de uma VM Windows entre dois nós do meu cluster Proxmox que me deparei com o aviso. À primeira vista, parecia uma daquelas notificações inofensivas que a gente arquiva mentalmente pra “ver depois”. Confesso que faço isso com frequência — e quase fiz dessa vez também. Mas alguma coisa no texto me chamou atenção. Resolvi investigar e descobri que esse aviso é um dos mais importantes que o Proxmox emite atualmente, e tem prazo: junho de 2026.

Estou falando da expiração dos certificados UEFI Secure Boot da Microsoft de 2011, que precisam ser substituídos pelos certificados emitidos em 2023. Se você ignorar isso e não fizer a transição, em algum momento — talvez no próximo cumulative update do Windows, talvez num boot depois de uma atualização de bootloader — máquinas com Secure Boot habilitado vão começar a falhar. E não estou falando só das VMs Windows: o problema atinge também distribuições Linux modernas, e até os próprios hosts Proxmox se você roda Secure Boot no firmware deles.

Esse artigo é um mergulho completo no tema: o que é o aviso, por que está acontecendo, quem é afetado, como detectar, como corrigir tanto no lado do Proxmox quanto no lado do guest OS, e — talvez o mais importante — qual é a armadilha do BitLocker que pode fazer suas VMs Windows pedirem chave de recuperação se você apressar o processo.

O aviso em si

O texto do aviso que apareceu no log da minha task de migration é direto:

WARN: EFI disk without 'ms-cert=2023k' option, suggesting that not all
UEFI 2023 certificates from Microsoft are enrolled yet.

The UEFI 2011 certificates expire in June 2026!

Aviso sobre certificados de boot UEFI no Proxmox — Aviso emitido durante a operação na VM — informa que os certificados Microsoft 2023 não passaram pelo registro.

Lendo com calma, a coisa fica grave. Os certificados antigos do Secure Boot da Microsoft (emitidos em 2011) expiram em junho de 2026. Sistemas que continuarem dependendo deles vão eventualmente ter problemas com:

Atualizações do bootloader (Windows e Linux)
Validações do Secure Boot a cada boot
Updates futuros de sistema operacional que dependem de componentes assinados com a nova chain
Compatibilidade entre versões diferentes de hypervisor
Live migrations entre hosts em estados diferentes de enrollment

Isso afeta praticamente todo mundo que roda algo minimamente moderno em VM com UEFI:

Windows Server 2022 e 2025
Windows 11 (que exige Secure Boot pra instalar)
Distribuições Linux modernas com Secure Boot habilitado (Ubuntu 22.04+, Debian 12+, RHEL/Rocky/AlmaLinux 9, Fedora atual)
VMs com firmware OVMF
Qualquer VM criada com a opção “pre-enrolled keys” ativa

Em um homelab médio dos dias atuais isso provavelmente cobre 60-80% das VMs. Em PME, a porcentagem é ainda maior, porque praticamente toda VM Windows Server criada nos últimos anos veio com Secure Boot ligado por padrão.

Linux também é afetado — e o motivo é o shim

Eu mesmo me fiz essa pergunta quando vi o aviso pela primeira vez. Certificado da Microsoft, problema da Microsoft, certo? Errado. A coisa é mais entrelaçada do que parece.

O ponto-chave aqui é uma peça de software chamada shim. A maioria absoluta das distribuições Linux não tem chaves próprias de Secure Boot pré-instaladas no firmware UEFI. Em vez disso, elas usam um pequeno bootloader chamado shim, que é assinado pela Microsoft. O shim, por sua vez, valida o GRUB, que valida o kernel Linux, que continua o boot normalmente.

A cadeia de confiança fica mais ou menos assim:

Firmware UEFI
  └─ confia em Microsoft UEFI CA
      └─ confia em shimx64.efi (assinado pela Microsoft)
          └─ confia em GRUB
              └─ confia em kernel Linux assinado pela distro

Quando a Microsoft transita do certificado 2011 pro 2023, isso impacta diretamente a chain do Linux porque, eventualmente, os novos shims, novos GRUBs e novos kernels serão assinados com a chave nova. Sem o certificado 2023 registrado no firmware da VM (ou do host), esses componentes não validam, e o sistema não boota.

Então, se você roda:

Hosts Docker em VM Linux com Secure Boot
Servidores web ou de aplicação Linux com Secure Boot
Workloads de Kubernetes em nodes Linux com Secure Boot
Qualquer infraestrutura Linux moderna em virtualização com Secure Boot habilitado

…você precisa fazer o enrollment do certificado 2023 nessas máquinas também. Esse é um dos pontos que me chamou mais atenção no que pesquisei: muita gente assume que é “problema do Windows”, mas não é. É um problema do ecossistema Secure Boot, do qual o Linux mainstream é totalmente dependente da Microsoft pra funcionar.

E não para nas VMs: o host Proxmox também é afetado

Esse ponto ficou claro num comentário pertinente que vi na thread do artigo do Brandon Lee (Virtualization Howto): se você tem Secure Boot habilitado no firmware do servidor que roda o Proxmox, esse host também precisa receber os certificados novos. Não é só problema de VM.

É algo que passa fácil despercebido porque a maioria das instalações de Proxmox em homelab roda com Secure Boot desabilitado mesmo (mini PCs muitas vezes nem trazem essa opção habilitada por padrão, ou o admin desativa pra simplificar a instalação inicial). Mas em PME, especialmente em servidores Dell PowerEdge, HPE ProLiant, Lenovo ThinkSystem, é comum o Secure Boot estar ligado no BIOS por questão de hardening — algumas políticas de segurança corporativa exigem inclusive.

Nesses casos, a transição precisa ser feita em duas camadas:

Firmware do host: via interface do BIOS/UEFI do servidor, ou via ferramentas do fabricante (Dell iDRAC, HPE iLO, Lenovo XCC) que permitem gerenciar chaves de Secure Boot remotamente.
VMs e containers: via o procedimento do Proxmox que vou detalhar mais à frente.

Pra checar se o host tem Secure Boot habilitado, rode no shell do Proxmox:

mokutil --sb-state

Se a saída for SecureBoot enabled, você está na primeira camada do problema também.

O que esse aviso realmente significa

Vou explicar a fundo o que está em jogo, porque o aviso é curto mas a mecânica por trás dele é importante de entender.

Os sistemas operacionais modernos usam Secure Boot pra garantir que bootloaders e componentes críticos do sistema sejam validados (criptograficamente) antes do boot completar. Isso evita uma categoria inteira de ataque conhecida como “bootkit” — malware que se instala no caminho do boot e fica invisível pro antivírus depois que o sistema sobe.

Pra essa validação funcionar, o firmware UEFI precisa ter chaves públicas confiáveis pré-instaladas. As principais são:

PK (Platform Key): a chave-mestra do fabricante da plataforma.
KEK (Key Exchange Key): chaves que podem ser usadas pra atualizar o DB e DBX.
DB (Signature Database): assinaturas válidas, que podem bootar.
DBX (Forbidden Signatures Database): assinaturas revogadas, banidas de bootar.

Em 2011, a Microsoft emitiu o conjunto de certificados que se tornou o padrão de fato pra toda a indústria. Praticamente todo firmware UEFI do mundo, de fabricantes diversos, traz essa chain pré-instalada — porque sem ela, Windows não boota e Linux mainstream (que depende do shim) também não.

Em 2023, a Microsoft emitiu uma nova chain. Os certificados antigos têm validade contratada de 15 anos, com expiração formal em junho de 2026 — mas a transição não acontece num instante específico. Componentes novos (bootloaders, shims, kernels) já estão sendo assinados com a chain 2023, e podem começar a falhar em máquinas que não tenham o certificado incorporado, mesmo antes da data formal de expiração. O problema é gradual e já começou.

Concretamente:

Componentes assinados com a chave nova exigirão que a KEK 2023 esteja no firmware pra validar.
Bootloaders, shims e drivers UEFI assinados com a chave antiga vão eventualmente ser revogados via DBX.
Em algum momento futuro, máquinas sem a chain 2023 simplesmente não vão mais bootar componentes modernos.

Hoje, em maio de 2026, a maioria dos sistemas continua funcionando porque o certificado 2011 ainda é válido. Mas plataformas como o Proxmox já estão avisando, exatamente pra dar tempo de fazer a transição sem incidente. Eu acho um movimento ótimo, sinceramente — em outras plataformas o usuário descobre o problema só quando dá pau.

Por que muita gente está vendo esse aviso agora

Alguns fatores convergiram pra esse aviso aparecer mais agressivamente nos últimos meses:

Primeiro, a migração maciça de VMware pra Proxmox que aconteceu depois da virada da Broadcom em 2023-2024. Muita gente, eu inclusive, mudou todo o ambiente pra Proxmox e está agora descobrindo os detalhes operacionais que antes nem se passava pela cabeça — Secure Boot era uma coisa “configurada e esquecida” no vSphere, no Proxmox você tem mais visibilidade do que está rolando.

Segundo, Secure Boot está muito mais comum hoje do que há 3 ou 4 anos. Windows 11 exige, Windows Server 2025 traz ligado por padrão, distros Linux corporativas vêm com Secure Boot habilitado nos templates. A base afetada é maior.

Terceiro, as versões recentes do Proxmox (9.x) ficaram mais agressivas em mostrar esse aviso durante várias operações: migration, boot da VM, operações em disk EFI, e agora — com o 9.2 — também durante o enrollment guiado pela GUI. É proposital. O Proxmox quer que você veja, porque o prazo está se aproximando.

Como descobrir quais VMs estão afetadas

Antes de sair fazendo enrollment de certificado VM por VM, o primeiro passo é mapear o ambiente. Em homelab de 5-10 VMs dá pra fazer no olho, abrindo a interface de cada uma. Em PME com 50, 100, 300 VMs, isso vira projeto.

Verificação manual (uma VM por vez)

No shell do Proxmox, rode:

qm config <VMID>

Procure por linhas como:

bios: ovmf
efidisk0: local-lvm:vm-100-disk-1,efitype=4m,pre-enrolled-keys=1,size=4M,ms-cert=2023k

Se você ver bios: ovmf e tem uma linha efidisk0:, essa VM usa UEFI. Se tem pre-enrolled-keys=1, Secure Boot foi habilitado quando o disco EFI foi criado. E o ponto-chave: se tem ms-cert=2023k, o certificado Microsoft 2023 já foi aplicado. Se essa flag não aparece, essa VM ainda precisa ser tratada.

Pela UI:

VM → Hardware
BIOS = OVMF (UEFI)
EFI Disk presente

Script de inventário pra todos os nós do cluster

Se você quer um relatório consolidado, esse script Bash rodando em cada nó dá uma tabela limpa de quais VMs têm EFI/Secure Boot, quais já receberam o certificado 2023, e — o que mais importa — quais ainda estão pendentes. Essa última coluna transforma o inventário num checklist de trabalho. Cola no shell do Proxmox e roda:

#!/usr/bin/env bash
# Inventario de VMs com UEFI/Secure Boot no host Proxmox
# Identifica quais VMs ja tiveram o enrollment do cert Microsoft 2023

echo "VMID  | Nome                      | BIOS  | EFI Disk | SecBoot | Cert 2023 | Acao"
echo "-----------------------------------------------------------------------------------"

for vmid in $(qm list | awk 'NR>1 {print $1}'); do

    config=$(qm config "$vmid")

    name=$(echo "$config"    | awk -F': ' '/^name:/ {print $2}')
    bios=$(echo "$config"    | awk -F': ' '/^bios:/ {print $2}')
    efidisk=$(echo "$config" | grep '^efidisk0:')

    # Secure Boot habilitado?
    secureboot="Nao"
    if echo "$efidisk" | grep -q "pre-enrolled-keys=1"; then
        secureboot="Sim"
    fi

    # Certificado 2023 ja com enrollment?
    cert2023="Nao"
    if echo "$efidisk" | grep -q "ms-cert=2023k"; then
        cert2023="Sim"
    fi

    # Acao recomendada
    if [[ "$secureboot" == "Sim" && "$cert2023" == "Nao" ]]; then
        acao="PENDENTE"
    elif [[ "$secureboot" == "Sim" && "$cert2023" == "Sim" ]]; then
        acao="OK"
    elif [[ "$secureboot" == "Nao" ]]; then
        acao="N/A"
    else
        acao="-"
    fi

    if [[ "$bios" == "ovmf" ]]; then
        if [[ -n "$efidisk" ]]; then
            efistatus="Presente"
        else
            efistatus="Ausente"
        fi

        printf "%-5s | %-25s | %-5s | %-8s | %-7s | %-9s | %-8s\n" \
            "$vmid" "$name" "$bios" "$efistatus" "$secureboot" "$cert2023" "$acao"
    fi
done

A saída fica algo como:

VMID  | Nome                      | BIOS  | EFI Disk | SecBoot | Cert 2023 | Acao
-----------------------------------------------------------------------------------
100   | win-srv-fileserver        | ovmf  | Presente | Sim     | Nao       | PENDENTE
102   | win11-rdp-jumphost        | ovmf  | Presente | Sim     | Sim       | OK
115   | ubuntu-docker-prod        | ovmf  | Presente | Sim     | Nao       | PENDENTE
203   | rocky9-app01              | ovmf  | Presente | Nao     | Nao       | N/A

Em PME, vale rodar isso em todos os nós, juntar a saída em um arquivo, e usar como checklist. Toda linha marcada como PENDENTE entra na fila de trabalho. As marcadas como OK você só monitora — já estão prontas pra junho de 2026. As N/A (sem Secure Boot) ficam fora do escopo dessa operação, mas vale anotar à parte porque, em algum momento futuro, pode fazer sentido habilitar Secure Boot nelas também — e aí vão entrar no mesmo fluxo.

Pra gerar uma lista limpa só das pendentes, dá pra filtrar a saída do script direto:

./inventario-secureboot.sh | grep PENDENTE

Esse é o ponto de partida do rollout.

O processo recomendado pelo Proxmox

A boa notícia é que o Proxmox já entrega a ferramenta pronta. O procedimento básico é:

Desligar a VM (shutdown limpo, não force-off).
Executar o comando de registro das chaves.
Ligar a VM e validar.

Pelo shell:

qm enroll-efi-keys <VMID>

Substituindo <VMID> pelo ID da VM. Esse comando atualiza o disco EFI da VM com os novos certificados Microsoft 2023, mantendo os 2011 ainda presentes (pra compatibilidade durante a transição).

Pela interface gráfica, o caminho é:

VM → Hardware
Selecionar o EFI Disk
Botão Disk Action → Enroll Updated Certificates

Enrollment dos certificados atualizados via GUI do Proxmox

O Proxmox abre um diálogo de confirmação explicando o que vai fazer. Clica em Yes.

Confirmação do enrollment dos novos certificados

Aí roda como uma task do Proxmox normal, que você acompanha no painel de tasks:

Task de enrollment no Proxmox web UI

Em condições normais, isso leva 2 a 5 segundos. A VM volta a ligar sem problema, agora com a chain 2023 incorporada ao firmware. Do lado do Proxmox, está feito.

Mas — e aqui é onde 90% dos tutoriais param e 90% dos problemas começam — tem mais coisa a fazer do lado do sistema operacional convidado, especialmente em Windows.

O lado do guest OS Windows: a armadilha do BitLocker

Esse é o ponto que considero mais crítico de todo o artigo. Se você usa BitLocker nas suas VMs Windows (e em PME, em VM Windows Server com dados corporativos, isso é praticamente regra), e roda o registro do certificado sem preparar o Windows antes, na próxima inicialização o Windows vai detectar mudança no ambiente de Secure Boot e entrar em modo de recuperação do BitLocker.

Traduzindo: a VM vai pedir a chave de recuperação do BitLocker pra continuar bootando. Se você não tem essa chave guardada (e, vamos ser honestos, em muito ambiente PME a chave foi gerada uma vez, mostrada na tela, e nunca foi anotada nem exportada), você acabou de transformar uma operação de manutenção em um incidente sério de recuperação de dados.

O fluxo correto com BitLocker

O Proxmox até menciona isso no diálogo, mas é fácil passar batido. A sequência segura é:

Com a VM ainda ligada, abrir PowerShell como administrador.
Suspender (não desabilitar permanentemente) a proteção do BitLocker:
```
manage-bde -protectors -disable C:
```
Se a VM tem múltiplos drives criptografados (D:, E:, etc), repete pra cada um.
Desligar a VM (shutdown limpo).
No Proxmox, rodar qm enroll-efi-keys <VMID> ou usar a opção pela GUI.
Ligar a VM, esperar bootar normalmente.
Validar que o sistema está estável (login, acesso aos drives criptografados etc).
Reabilitar o BitLocker:
```
manage-bde -protectors -enable C:
```

O comando -disable não descriptografa o disco — ele suspende a proteção, fazendo o Windows liberar a chave de descriptografia automaticamente durante o boot, sem checar o Secure Boot. Isso permite que a mudança no firmware aconteça sem disparar o modo de recuperação. Depois você reabilita e a proteção volta ao normal.

Em ambiente de PME com muitas VMs Windows criptografadas, isso vira um workflow que vale a pena automatizar. Um exemplo de procedimento que dá pra rodar em massa via WinRM ou Ansible:

# Pre-enrollment: suspender BitLocker em todos os drives criptografados
Get-BitLockerVolume | Where-Object { $_.ProtectionStatus -eq 'On' } | ForEach-Object {
    Suspend-BitLocker -MountPoint $_.MountPoint -RebootCount 0
    Write-Host "BitLocker suspenso em $($_.MountPoint)"
}

# (Depois do enrollment e reboot)

# Post-enrollment: reativar BitLocker
Get-BitLockerVolume | Where-Object { $_.ProtectionStatus -eq 'Off' } | ForEach-Object {
    Resume-BitLocker -MountPoint $_.MountPoint
    Write-Host "BitLocker reativado em $($_.MountPoint)"
}

Mas independente de automação, sempre tenha a chave de recuperação salva em local seguro antes de mexer com Secure Boot em máquina com BitLocker. É o mínimo de margem que você quer ter num cenário desses.

Confirmando que o lado Windows também completou o enrollment

Fazer o registro pelo Proxmox atualiza o disco EFI virtual. Mas o Windows também precisa estar com a atualização cumulativa de março de 2026 instalada — é essa atualização que o Windows usa pra processar e validar a presença do certificado 2023 no firmware. Se a VM está com Windows Update atrasado, o sistema operacional pode não reconhecer corretamente a mudança.

Pra checar status do certificado 2023 dentro de uma VM Windows, esse script PowerShell (rodado como admin) dá um diagnóstico completo:

# Status do certificado Secure Boot 2023 no Windows
# Executar como administrador
# Acentos removidos para compatibilidade com PowerShell em consoles legados.

# 1. Confirma que Secure Boot esta ativo
$secureBoot = Confirm-SecureBootUEFI
Write-Host "Secure Boot Habilitado: $secureBoot" -ForegroundColor Cyan

# 2. Verifica se o cert 2023 ja esta no DB
$has2023Cert = [System.Text.Encoding]::ASCII.GetString(
    (Get-SecureBootUEFI db).bytes
) -match 'Windows UEFI CA 2023'
Write-Host "Certificado 2023 presente: $has2023Cert" `
    -ForegroundColor $(if ($has2023Cert) { "Green" } else { "Yellow" })

# 3. Verifica chaves de servicing do Windows
$servicing = Get-ItemProperty `
    "HKLM:\SYSTEM\CurrentControlSet\Control\SecureBoot\Servicing" `
    -ErrorAction SilentlyContinue

if ($servicing) {
    [PSCustomObject]@{
        UEFICA2023Status = switch ($servicing.UEFICA2023Status) {
            0 { "Nao iniciado" }
            1 { "Em andamento" }
            2 { "Concluido" }
            default { "Desconhecido ($($servicing.UEFICA2023Status))" }
        }
        UEFICA2023Error = if ($servicing.UEFICA2023Error) {
            '0x' + '{0:x}' -f $servicing.UEFICA2023Error
        } else { "Nenhum" }
        AvailableUpdates = if ($servicing.AvailableUpdates) {
            '0x' + '{0:x}' -f $servicing.AvailableUpdates
        } else { "Nao configurado" }
    } | Format-List
} else {
    Write-Host "Chave de servicing nao encontrada - Windows Update " `
        "ainda nao preparou a atualizacao." -ForegroundColor Yellow
}

# 4. Eventos relevantes no log do sistema
Write-Host "`nEventos recentes de Secure Boot:" -ForegroundColor Cyan
Get-WinEvent -LogName System -ErrorAction SilentlyContinue |
    Where-Object { $_.Id -in @(1801, 1803, 1808) } |
    Select-Object TimeCreated, Id, Message |
    Sort-Object TimeCreated -Descending |
    Select-Object -First 10 |
    Format-Table -AutoSize -Wrap

O ideal é ver:

Secure Boot Habilitado: True
Certificado 2023 presente: True
UEFICA2023Status: Concluido

Se aparecer “Em andamento” ou “Nao iniciado”, aguarde o próximo ciclo de Windows Update, ou force wuauclt /detectnow seguido de reboot, e rode o script de novo.

Linux: como ficar tranquilo do lado do guest

No Linux a coisa é mais simples porque a maioria das distros já está distribuindo shims assinados que aceitam tanto a chain 2011 quanto a 2023, e a atualização dos certificados no firmware EFI virtual (feita pelo Proxmox) basicamente resolve o problema.

Ainda assim, dá pra validar o que foi registrado (pós-enrollment) dentro da VM Linux com:

# Listar certificados no DB do Secure Boot
mokutil --db | grep -i "2023"

# Estado geral do Secure Boot
mokutil --sb-state

# Listar certificados pendentes para enrollment via shim
mokutil --list-enrolled

Se você ver referência a “Windows UEFI CA 2023” ou “Microsoft UEFI CA 2023” na saída do mokutil --db, a VM tem o certificado novo com enrollment e está pronta pro pós-junho 2026.

Mantenha as distros atualizadas (apt update && apt upgrade, dnf upgrade) que os shims e GRUBs vão sendo atualizados naturalmente e o suporte ao 2023 vem com eles. Em PME, isso reforça a importância de ter um workflow de patching Linux ativo — não dá pra deixar máquina Linux 6 meses sem update e esperar que tudo funcione na transição.

Por que o Proxmox está lidando com isso melhor que outros

Vale dar um destaque pro Proxmox aqui. O processo todo é, do lado da plataforma, basicamente um comando ou um clique. Compare com o que tem que ser feito em VMware ESXi pré-9.0:

Anexar um VMDK extra à VM com os arquivos de certificado.
Bootar a VM no modo de configuração EFI (apertar F2 ou Esc no boot).
Navegar no menu de Secure Boot Configuration.
Importar manualmente PK, KEK, DB pelos arquivos no VMDK.
Sair do setup, deixar a VM bootar.

Vezes 50, 100, 300 VMs. Imagine.

No VMware é preciso trocar PK e KEK manualmente pela EFI setup — No VMware ESXi pré-9.0 é necessário trocar PK e KEK manualmente entrando na configuração EFI.

O motivo técnico é interessante. A própria Broadcom explica que em VMs criadas em versões de ESXi anteriores à 9.0, a Platform Key (PK) foi configurada com uma assinatura nula por design. Sem PK válida, o firmware não autoriza atualizações de KEK, e sem KEK atualizada, não dá pra atualizar DB e DBX. Isso transforma o que devia ser uma operação automatizável em uma ginástica manual VM por VM.

No Proxmox, a PK é configurada corretamente por padrão, e o comando qm enroll-efi-keys usa a chain válida pra atualizar tudo de forma transparente. É o tipo de detalhe arquitetural que faz diferença real em ambiente com escala.

Não estou dizendo isso pra fazer torcida — VMware tem méritos próprios — mas pra quem está em PME planejando migração e olhando esse tipo de problema operacional como parte do critério de decisão, vale pesar.

Plano de ação sugerido para PME

Se você administra um ambiente Proxmox em PME, esse é o plano que eu sugiro seguir nos próximos 30 dias:

Semana 1 — Inventário. Rode o script de inventário em todos os nós do cluster. Liste todas as VMs com Secure Boot habilitado. Identifique quais rodam BitLocker (em Windows) ou criptografia equivalente.
Semana 1 — Backup das chaves. Pra cada VM com BitLocker, valide que a chave de recuperação está documentada em local seguro (cofre de senhas corporativo, Active Directory, Azure AD, ou um cofre físico). Não pule essa etapa.
Semana 2 — Validação do host. Em cada host Proxmox, cheque se o Secure Boot está habilitado no firmware. Se sim, planeje a atualização das chaves no firmware do servidor (consulte o manual do fabricante — Dell, HPE, Lenovo, Supermicro têm procedimentos próprios).
Semana 2 — Atualização do Proxmox. Se ainda não estiver no 9.2, planeje o upgrade. A interface de enrollment na GUI faz muita diferença operacional.
Semana 3 — Piloto. Faça o enrollment em 2 ou 3 VMs não críticas (uma Windows com BitLocker, uma Linux, uma sem criptografia). Valide o fluxo completo: suspender BitLocker, fazer enrollment, bootar, reativar BitLocker, confirmar via PowerShell que o cert 2023 está presente.
Semana 3-4 — Rollout. Com o fluxo validado, programe janelas pra atacar o resto do ambiente. Priorize VMs críticas pra que estejam protegidas antes de junho.
Semana 4 — Patching. Garanta que todas as VMs Windows estão com o cumulative update de março de 2026 ou posterior. Distribuições Linux com pacotes atualizados (shim, grub, kernel).

Em homelab, o plano é mais simples mas a lógica é a mesma: inventário, valida BitLocker se aplicável, faz enrollment, atualiza guests. Pode rodar em fim de semana com calma.

O que pode dar errado, e como reagir

Pra fechar com pé no chão, lista de problemas reais que podem aparecer e como tratar:

VM Windows não boota e pede chave do BitLocker

Aconteceu porque você esqueceu de suspender o BitLocker antes do enrollment. Solução: digita a chave de recuperação que você guardou em local seguro antes de fazer essa operação. Depois que a VM subir, valida que está tudo OK e reabilita o BitLocker normalmente. Aprendizado: nunca mais sem suspender antes.

VM Linux com Secure Boot não boota

Provavelmente o shim instalado é antigo. Bootar com Secure Boot temporariamente desabilitado (via opções da VM no Proxmox), entrar no sistema, atualizar pacotes (apt upgrade ou equivalente), e religar Secure Boot.

Live migration continua dando warning depois do enrollment

Provavelmente a VM não foi reiniciada depois do enrollment, ou o enrollment foi feito pela GUI mas não aplicado. Confirma com qm config <VMID> que o disco EFI tem a flag ms-cert=2023k ou similar. Se não tem, repete o procedimento e dá um reboot na VM.

Host Proxmox com Secure Boot não boota depois de mexer no firmware

Esse é o pior cenário porque você fica sem o host. Por isso eu recomendo fortemente, em PME, ter console out-of-band (iDRAC, iLO, IPMI, KVM-over-IP) configurado antes de tocar em qualquer config de Secure Boot do firmware do servidor. Sem console remoto, se algo der errado e o servidor estiver em outro andar, em uma filial, ou num datacenter terceirizado, você fica refém de visita técnica.

Encerrando

Esse é o tipo de aviso que tem cara de “ignora que dá pra ver depois”, mas que vai morder muita gente se for ignorado. A boa notícia é que o Proxmox dá ferramenta pronta, mostra o aviso de forma clara, e — com o 9.2 — coloca o workflow direto na GUI sem precisar saber linha de comando. A má notícia é que tem nuances importantes (BitLocker, host com Secure Boot, atualização cumulativa do Windows, shim no Linux) que não são óbvias se você só ler a mensagem do warning.

Resumo do que importa lembrar:

Os certificados Microsoft 2011 expiram em junho de 2026.
VMs Windows e Linux com Secure Boot habilitado precisam de enrollment do certificado 2023.
O host Proxmox também precisa de atenção se rodar Secure Boot no firmware.
Se a VM Windows tem BitLocker, suspender antes de fazer o enrollment — senão prepara pra recuperação.
Windows precisa do cumulative update de março de 2026 instalado pra processar a transição.
Linux precisa de pacotes atualizados (shim, grub, kernel).
O Proxmox VE 9.2 expõe o enrollment direto na GUI — atualizar pra essa versão antes de fazer em escala economiza tempo.

Em homelab, é um sábado de manutenção. Em PME, é um projeto de 30 dias que precisa de planejamento, inventário, piloto, rollout. Em qualquer cenário, é trabalho que precisa ser feito antes que o calendário queime.

Já passou pelo enrollment no seu ambiente? Como foi, especialmente se rodou em parque com BitLocker — essa é a parte onde dá mais história. Esse tipo de projeto de transição — inventário, planejamento, rollout em janela — é o pão de cada dia de quem vive de infraestrutura.

Artigos relacionados: