Proxmox VE 9.2 ругается на EFI-диск без ms-cert=2023k: что это значит и как обновить сертификаты, не поймав BitLocker

Обновили кластер до Proxmox VE 9.2, а в веб-интерфейсе у половины виртуалок появилась жёлтая строчка про EFI-диск без ms-cert=2023k. При этом машины прекрасно стартуют, Windows работает, Secure Boot включён. Разбираю по-честному: что именно сломано, что ещё не сломано, чем отличаются маркеры 2023, 2023w и 2023k, как выглядит массовое обновление на живом кластере и в каком единственном месте вас реально ждёт запрос ключа восстановления BitLocker.

Плашка есть, а машина грузится — и это нормально

Картина знакомая: обновили узлы на 9.2 (релиз от 21 мая 2026, Debian 13.5 «Trixie», ядро 7.0, QEMU 11.0), зашли в веб-морду — и у части ВМ на вкладке Hardware напротив EFI Disk висит подсказка зачислить сертификаты UEFI 2023, а в журнале задачи запуска ВМ — предупреждение о том, что на EFI-диске нет маркера ms-cert=2023k и новые сертификаты Microsoft зачислены не полностью. Контекст простой: Microsoft Corporation KEK CA 2011 истёк 24 июня 2026, Microsoft UEFI CA 2011 — 27 июня 2026, а Microsoft Windows Production PCA 2011, которым подписан текущий загрузчик Windows, истекает 19 октября 2026. Первое, что спрашивает заказчик: «У нас всё встало?» Нет. Всё работает. И в этом главная ловушка — потому что через несколько месяцев уже может не работать, а связь между «тогда обновили загрузчик» и «сегодня чёрный экран» никто не проведёт.

Почему машина грузится с истёкшим CA. Прошивка при загрузке проверяет, что подпись загрузчика ведёт к сертификату из базы db на EFI-диске. Срок действия самого CA в подавляющем большинстве реализаций edk2/OVMF при этой проверке не является поводом отбраковать образ — иначе в июне 2026 разом легли бы миллионы машин по всему миру, чего не случилось. То есть уже подписанный shim или bootmgfw.efi из вашей текущей Windows будет грузиться и дальше. Ломается не загрузка, ломается будущее: новые загрузчики, подписанные сертификатами 2023 года, ваша прошивка не примет, потому что этих сертификатов в db просто нет.

Второй, менее очевидный слой — KEK. Обновления баз db и dbx (списка отзыва) прошивка принимает только если они подписаны действующим ключом обмена (KEK). Пока в EFI-диске лежит только KEK 2011, вы отрезаны и от будущих обновлений отзывов тоже. Именно поэтому Proxmox считает полностью обновлённым только тот диск, где есть и новые CA в db, и новый KEK 2023.

Мой приоритет по этой задаче: не аварийно, но и не «когда-нибудь». Делать до ближайшего крупного обновления гостевой ОС — до накатывания нового билда Windows Server, до апгрейда Debian/Ubuntu через мажор. Потому что момент, когда вам прилетит загрузчик, подписанный только 2023-м, вы не контролируете.

• Загрузка сегодня — работает, паниковать не надо.
• Новый загрузчик, подписанный сертификатом 2023 года, — не запустится.
• Обновления db/dbx без KEK 2023 — не применятся.
• Срочность: плановая, но до следующего мажорного обновления гостя.

Что физически лежит в EFI-диске и что значат маркеры 2023, 2023w и 2023k

EFI-диск в Proxmox — это не «диск» в бытовом смысле, а varstore прошивки edk2: небольшой образ, в котором живут NVRAM-переменные, включая иерархию ключей Secure Boot — PK, KEK, db и dbx. Именно поэтому его нельзя обновить на лету: переменные читает и пишет запущенная прошивка, и пока ВМ работает, менять их снаружи нельзя. Отсюда требование выключенной машины у команды обновления.

Создаётся такой диск командой, которую приводит официальный мануал qm. Обратите внимание на два параметра: efitype=4m (большой формат varstore, он и рассчитан на Secure Boot) и pre-enrolled-keys=1 — предзагрузка ключей дистрибутива и стандартных ключей Microsoft с включённым Secure Boot по умолчанию:

qm set <vmid> -efidisk0 <storage>:1,format=<format>,efitype=4m,pre-enrolled-keys=1

Теперь про маркеры, из-за которых весь сыр-бор. В конфиге ВМ у строки efidisk0 появляется параметр ms-cert. Его значение — это не «версия сертификата», а метка о степени зачисления, и она исторически росла вместе с кодом qemu-server. Значение 2023 — самое раннее и по сути устаревшее: оно ставилось, когда в db добавляли только «Microsoft UEFI CA 2023». Значение 2023w означает, что в db лежат оба CA — и «Microsoft UEFI CA 2023», и «Windows UEFI CA 2023» (буква w — от Windows). И только 2023k (k — от KEK) означает, что вдобавок к обоим CA зачислен ключ обмена «Microsoft Corporation KEK 2K CA 2023». Документация формулирует прямо: наличие ms-cert=2023k говорит о том, что новые сертификаты зачислены; значения ms-cert=2023 и ms-cert=2023w могут означать частичное зачисление, и к ним нужно применить ту же процедуру.

Есть ещё третье состояние — параметра ms-cert нет вообще. Это самый частый случай для машин, созданных пару лет назад: в EFI-диске только набор 2011 года. Новые диски получают оба набора сразу, если пакет pve-edk2-firmware на узле не ниже версии 4.2025.05-1. Проверить пакет и разом просканировать все конфиги на узле можно так:

dpkg -l pve-edk2-firmware | tail -n1
grep -H '^efidisk0' /etc/pve/qemu-server/*.conf | sed 's#/etc/pve/qemu-server/##'

• нет ms-cert — только сертификаты 2011 года, зачисление обязательно;
• ms-cert=2023 — исторический маркер, в db только Microsoft UEFI CA 2023, зачисление нужно;
• ms-cert=2023w — в db оба CA 2023, но KEK 2023 нет, зачисление нужно;
• ms-cert=2023k — полный комплект, db + KEK, делать ничего не надо.

Как это выглядело на живом кластере: 23 виртуалки за одно окно

Разбор из практики. Детский языковой центр «Полиглотик», 16 рабочих мест: администраторы на ресепшене, методисты, бухгалтер и директор. Вся серверная часть — один узел Proxmox в серверном шкафу офиса, обновляли его с 8.4 на 9.2 в конце июля 2026. На узле 9 ВМ: 6 из них с efidisk0 (остальные три — старые Linux-машины на SeaBIOS, их эта история вообще не касается). Из шести — четыре Windows (Server 2019 с контроллером домена, Server 2022 с 1С и файловыми шарами, Server 2022 — терминальный сервер для методистов, Windows 11 — рабочая ВМ бухгалтера) и две Linux (Debian 12 с CRM для записи учеников и Ubuntu 24.04 с архивом записей онлайн-занятий).

Первое, что я сделал, — не полез ничего чинить, а собрал картину. Вышло так: один диск уже с ms-cert=2023k (терминальный сервер пересоздавали весной, прошивка была свежая), один — с ms-cert=2023w (Ubuntu), четыре — вообще без маркера. То есть у пяти машин из шести комплект неполный. Дальше я разложил их на три корзины: Linux (две штуки — просто и быстро), Windows без BitLocker (контроллер домена — быстро, но с гостевой доработкой), Windows с BitLocker (сервер 1С и ВМ бухгалтера — единственный риск во всей задаче).

Само зачисление — это несколько секунд на машину. Требуется только выключенная ВМ. Через интерфейс: Hardware → выделить EFI Disk → Disk Action → Enroll Updated Certificates, там же выскакивает предупреждение про BitLocker. Через консоль ещё быстрее, и это удобнее, когда машин несколько:

# ВМ должна быть выключена
qm shutdown 141 && qm wait 141
qm enroll-efi-keys 141
qm config 141 | grep efidisk0
qm start 141

После команды в конфиге появляется ms-cert=2023k — это и есть критерий успеха. Никакой отдельной проверки «изнутри» на этом шаге не требуется.

Итог по «Полиглотику»: пять машин обновлены в субботнее окно за 25 минут, пока в центре не было занятий; простой — 6 минут на самую тяжёлую (сервер 1С, у него дольше всего идёт остановка служб и прогрев после старта), остальные по 40–90 секунд. Одна машина всё-таки встретила меня экраном BitLocker — про неё отдельный раздел ниже, там я честно расскажу, где сам напортачил. Плюс два вечера ушло на гостевую часть Windows, потому что зачисление на хосте — это только половина работы.

• Соберите инвентарь ДО работ: сколько машин с efidisk0, у скольких какой маркер.
• Разложите на корзины: Linux / Windows без BitLocker / Windows с BitLocker.
• Сделайте бэкап или снапшот ВМ перед зачислением — откат должен быть, даже если он не понадобится.
• Начинайте с Linux и тестовой машины, боевую 1С и терминальник делайте последними.

BitLocker: единственное место, где реально можно встать

Вот тут внимательно, потому что это вся суть предостережения в мануале. BitLocker с TPM-протектором запечатывает ключ тома на значениях PCR, и среди них есть PCR 7 — измерение состояния Secure Boot, то есть содержимого PK, KEK, db и dbx. Вы добавляете в db два новых CA и новый KEK — измерение меняется — виртуальный TPM отказывается отдавать ключ — Windows на следующем старте показывает синий экран с просьбой ввести 48-значный ключ восстановления. Никакой поломки тут нет, механизм отработал ровно так, как задуман. Просто вы его не предупредили.

Правильный порядок: приостановить протекторы на каждом томе с BitLocker, выключить ВМ, зачислить сертификаты, включить ВМ, дать Windows нормально загрузиться — у системного тома протекторы включатся сами (по умолчанию защита приостанавливается на одну перезагрузку) и перезапечатают ключ уже на новых значениях PCR. Мануал Proxmox прямо предписывает делать это для каждого тома. Команды:

# посмотреть все тома и их состояние
Get-BitLockerVolume | Select-Object MountPoint, VolumeStatus, ProtectionStatus

# приостановить защиту (вариант из мануала Proxmox)
manage-bde -protectors -disable C:

# либо родной командлет с явным числом перезагрузок
Suspend-BitLocker -MountPoint "C:" -RebootCount 1

# после загрузки убедиться, что защита вернулась
manage-bde -status C:

# если Protection Off так и осталось — вернуть вручную
manage-bde -protectors -enable C:

Моя ошибка в «Полиглотике» была ровно та, о которой я всех предупреждаю: сервер 1С я подготовил по чек-листу, а ВМ бухгалтера с Windows 11 пропустил, потому что был уверен — BitLocker там никто не включал. Включила его сама Windows: автоматическое шифрование устройства активировалось, когда бухгалтер вошла под учётной записью Microsoft. Результат: после зачисления ВМ встретила меня экраном восстановления BitLocker. Ключ нашёлся в учётной записи Microsoft, поэтому потеря составила минут двадцать, а не день работы бухгалтерии. Отсюда правило: перед работами не «вспоминаю, где есть BitLocker», а на каждой Windows-ВМ прогоняю Get-BitLockerVolume и приостанавливаю защиту на всём, что вернулось со статусом Protection On, — и системные тома, и тома данных, как требует мануал Proxmox.

И проверка, которую я делаю до всего остального: убедиться, что ключи восстановления вообще где-то есть. В AD, в Entra ID, в учётной записи Microsoft, в Bitwarden — неважно где, важно чтобы вы могли их достать за минуту, не поднимая при этом ту же самую упавшую машину. Если ключей нет нигде — сначала настраиваете их архивацию, только потом трогаете EFI-диск.

• Проверить, что ключи восстановления сохранены (AD DS / Entra ID / учётная запись Microsoft / менеджер паролей).
• Get-BitLockerVolume на КАЖДОЙ Windows-ВМ — включая клиентские Windows 11 с автоматическим шифрованием устройства.
• Приостановить протекторы на каждом таком томе.
• Выключить ВМ → qm enroll-efi-keys → включить → дождаться загрузки.
• manage-bde -status — убедиться, что Protection On вернулось само.

Хост зачислил — Windows ещё нет: гостевая половина работы

Самое частое заблуждение, которое я встречаю в чатах: «сделал qm enroll-efi-keys, маркер 2023k, всё, задача закрыта». Для Linux — да, закрыта. Для Windows — нет. Вы обновили только то, что видит прошивка снаружи. Внутри Windows есть собственный конвейер обновления Secure Boot, который отвечает за то, чтобы система перешла на загрузчик, подписанный «Windows UEFI CA 2023», и чтобы дальнейшие обновления db/dbx применялись через новый KEK.

Предварительное условие из мануала Proxmox: в госте должны стоять обновления безопасности по CVE-2023-24932 (любой актуальный накопительный пакет за 2025–2026 годы). Дальше управляется всё одним значением в реестре и одной запланированной задачей. Ветка HKLM\SYSTEM\CurrentControlSet\Control\SecureBoot, значение AvailableUpdates — битовая маска. Микрософт документирует ровно два состояния: 0 или отсутствует — обновления не выполняются, и 0x5944 — «развернуть все нужные сертификаты и перейти на загрузчик, подписанный PCA2023». Биты гасятся по мере успешной обработки, поэтому число между перезагрузками меняется — это нормально, это прогресс, а не сбой. Задача \Microsoft\Windows\PI\Secure-Boot-Update по документации Microsoft обычно запускается раз в 12 часов, но её можно пнуть руками:

Set-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Control\SecureBoot" `
  -Name "AvailableUpdates" -Value 0x5944 -Type DWord

Start-ScheduledTask -TaskName "\Microsoft\Windows\PI\Secure-Boot-Update"

Контроль результата — тоже в реестре, в подветке Servicing: значение UEFICA2023Status проходит стадии NotStarted → InProgress → Updated. Плюс можно посмотреть, что реально лежит в db, прямо из гостя — это самый честный ответ на вопрос «а точно ли зачислилось»:

Confirm-SecureBootUEFI

# AvailableUpdates лежит в SecureBoot, статус — в подветке Servicing
(Get-ItemProperty "HKLM:\SYSTEM\CurrentControlSet\Control\SecureBoot").AvailableUpdates
(Get-ItemProperty "HKLM:\SYSTEM\CurrentControlSet\Control\SecureBoot\Servicing").UEFICA2023Status

[Text.Encoding]::ASCII.GetString((Get-SecureBootUEFI db).bytes) -split '\0' |
  Select-String 'CA 2023|CA 2011'

Ожидайте несколько перезагрузок. У меня в «Полиглотике» на двух серверах цикл занял два дня — просто потому, что серверы перезагружаются по регламенту раз в сутки, а задача ждёт своего окна. Гнать это в один вечер силой я не советую: перезагрузка боевого терминальника посреди дня стоит дороже, чем два лишних дня в статусе InProgress. Заведите себе строку в чек-листе и просто проверьте состояние через неделю.

• Предварительно: установлены обновления по CVE-2023-24932 (актуальный накопительный пакет).
• AvailableUpdates = 0x5944 — включает весь конвейер целиком.
• Задача \Microsoft\Windows\PI\Secure-Boot-Update — исполнитель, ходит сама раз в ~12 часов.
• UEFICA2023Status = Updated — критерий завершения.
• Меняющееся значение AvailableUpdates между перезагрузками — это прогресс, а не ошибка.

Linux-гости: почему им проще и где всё-таки рванёт

С Linux-виртуалками история короче: хостового зачисления достаточно, внутрь гостя лезть не нужно. Никаких аналогов AvailableUpdates там нет — вы просто добавили в db сертификаты, которыми в будущем будут подписаны новые shim, и на этом всё. Две Linux-машины в «Полиглотике» я сделал за пять минут вместе с перезагрузками.

Но именно здесь спрятан момент, который многие недооценивают. Разработчики Proxmox в обсуждении на форуме отмечали, что Debian готовит shim, подписанный сразу и старым, и новым ключом, — это переходный период, буфер. Проблема начнётся, когда выйдет обновление, подписанное только новым ключом: без пересечения по сертификатам пакет откажется устанавливаться и громко предупредит; по словам разработчика Proxmox, уже установленный загрузчик при этом останется на месте, и перезагрузка с Secure Boot не сломается. Это лучше, чем тихо сломанная загрузка, но обычно такое вылезает посреди планового apt full-upgrade в пятницу вечером.

Мой практический вывод: для Linux-гостей задача не срочная ровно до момента, когда вы обновляете дистрибутив через мажорную версию или ставите новое ядро с новым shim. То есть в календаре обслуживания зачисление сертификатов должно идти строго перед апгрейдом дистрибутива, а не после. Стоит оно минуту простоя, а избавляет от отдельного расследования на тему «почему grub не грузится с включённым Secure Boot».

И отдельно про соблазн: да, для Linux-ВМ Secure Boot можно просто выключить, и всё поедет. Я так делать не советую, но и демонизировать не буду — если это внутренняя утилитарная машина без чувствительных данных и без BitLocker-подобной привязки, выключенный Secure Boot не сделает вашу инфраструктуру дырявой сам по себе. Просто вы теряете один рубеж защиты от буткитов и потом забываете, что он выключен. Мне проще потратить минуту на зачисление.

• Linux: хостовое зачисление — достаточно, гостевых шагов нет.
• Порядок: сначала qm enroll-efi-keys, потом апгрейд дистрибутива.
• Переходные shim подписаны обоими ключами — окно есть, но оно конечно.
• Выключить Secure Boot — рабочий, но плохой обходной путь; фиксируйте его в документации, если применили.

Порядок работ, который я использую, и что можно смело отложить

Собираю всё вместе в тот регламент, по которому реально работаю на клиентских кластерах. Он рассчитан на парк от пары до нескольких десятков виртуалок, то есть на типового заказчика IT-аутсорсинга, а не на сотни машин с автоматизацией через Ansible. Ключевая идея — разделить задачу на два независимых этапа: быстрый хостовой (минуты, требует окна простоя) и медленный гостевой (дни, простоя почти не требует). Смешивать их в один вечер — верный способ получить незакрытые хвосты.

Хостовой этап целиком: инвентаризация конфигов, проверка версии pve-edk2-firmware, бэкап ВМ, приостановка BitLocker там, где он есть, выключение, qm enroll-efi-keys, включение, проверка маркера. Гостевой этап для Windows: AvailableUpdates, задача, проверка UEFICA2023Status спустя неделю. Между ними — обычная эксплуатация, ничего специально ждать не надо.

Теперь честно про то, на что можно забить. Первое: не надо срочно, ночью, аварийным окном перезагружать боевые сервисы ради этой задачи — истёкшие в июне 2026 сертификаты не остановили уже работающие загрузчики и не остановит их завтра. Второе: не надо трогать машины, у которых в конфиге уже стоит ms-cert=2023k, — они в порядке по определению, никакие дополнительные хостовые действия им не нужны. Третье: не надо переделывать ВМ с SeaBIOS на UEFI «за компанию» — если машина живёт без EFI-диска, вся эта тема к ней не относится вообще.

На что забивать нельзя. Ключи восстановления BitLocker должны быть доступны до начала работ — это не формальность, это разница между двадцатью минутами и потерянным томом. Бэкап ВМ перед изменением EFI-диска — обязателен, потому что varstore вы правите на месте и «Ctrl+Z» тут нет. И гостевой этап для Windows нельзя считать необязательным: маркер 2023k на хосте без Updated внутри системы означает, что вы сделали половину работы и после 19 октября 2026, когда истечёт Windows Production PCA 2011, рискуете получить ровно ту проблему, от которой убегали.

• Проверить наличие ключей восстановления BitLocker — до всего остального.
• dpkg -l pve-edk2-firmware и pveversion — edk2 не ниже 4.2025.05-1, qemu-server не ниже 9.1.5 (там добавлен KEK 2023).
• grep по /etc/pve/qemu-server/*.conf — собрать список машин без ms-cert=2023k.
• Бэкап или снапшот каждой ВМ перед зачислением.
• Приостановить BitLocker на всех томах → выключить → qm enroll-efi-keys → включить.
• Windows: AvailableUpdates = 0x5944 + запуск задачи Secure-Boot-Update.
• Через неделю: проверить UEFICA2023Status = Updated и содержимое db.
• Записать в документацию клиента дату работ и список обработанных ВМ.

Частые вопросы