Информация
Услуги
  • Внедрение
  • Настройка
  • Поддержка
  • Ремонт
Контакты
Оплата
Новости
Доставка
Загрузки
Форум
Настройка
    info@proxmox.su
    +7 (495) 320-70-49
    Заказать звонок
    Аспро: ЛайтШоп
    Войти
    0 Сравнение
    0 Избранное
    0 Корзина
    Аспро: ЛайтШоп
    Войти
    0 Сравнение
    0 Избранное
    0 Корзина
    Аспро: ЛайтШоп
    Телефоны
    +7 (495) 320-70-49
    Заказать звонок
    0
    0
    0
    Аспро: ЛайтШоп
    • +7 (495) 320-70-49
      • Назад
      • Телефоны
      • +7 (495) 320-70-49
      • Заказать звонок
    • info@proxmox.su
    • Москва, Бакунинская улица, 69с1
    • Пн-Пт: 09-00 до 18-00
      Сб-Вс: выходной
    • 0 Сравнение
    • 0 Избранное
    • 0 Корзина
    Главная
    Форум
    Proxmox Виртуальная Среда
    Secure Boot – сертификат Microsoft UEFI CA 2023 не включён в EFI диск

    Форумы: Proxmox Виртуальная Среда, Proxmox Backup Server, Proxmox Mail Gateway, Proxmox Datacenter Manager
    Поиск  Пользователи  Правила  Войти
    Страницы: 1
    RSS
    Secure Boot – сертификат Microsoft UEFI CA 2023 не включён в EFI диск, Proxmox Виртуальная Среда
     
    powersupport
    Guest
    #1
    0
    07.10.2025 00:05:00
    Привет! Мы сейчас готовим наши Windows Server VM к обновлению сертификатов Secure Boot от Microsoft. Согласно объявлению Microsoft (ссылка: https://support.microsoft.com/en-us...-updates-7ff40d33-95dc-4c3c-8725-a9b95457578e), существующий сертификат Microsoft UEFI CA 2011 истекает в 2026 году, и для продолжения работы Secure Boot нужно зарегистрировать новый сертификат (Windows UEFI CA 2023). Мы используем Proxmox VE и создаём Windows VM с включенным Secure Boot и EFI-дисками с заранее зарегистрированными ключами (согласно документации https://pve.proxmox.com/pve-docs/chapter-qm.html#qm_bios_and_uefi) командой: qm set <vmid> --efidisk0 local-lvm:vm-<vmid>-disk-1,efitype=4m,pre-enroll-keys=1 После тестирования Windows Server 2022 VM мы заметили, что сертификат Windows UEFI CA 2023 отсутствует в базе Secure Boot (db). Проверили через PowerShell: [System.Text.Encoding]::ASCII.GetString((Get-SecureBootUEFI db).bytes) -match 'Windows UEFI CA 2023' → возвращает False Хотели бы спросить: планируется ли обновление EFI-дисков Proxmox с добавлением сертификата Microsoft Windows UEFI CA 2023 в будущих релизах? Если да, есть ли примерная дата или версия Proxmox VE, в которой появится эта функция? Если нет, то какой рекомендуемый способ вручную зарегистрировать этот сертификат в EFI-окружении Windows VM, созданной через Proxmox? Существует ли официально поддерживаемый метод для добавления сертификата в db или dbx в EFI? Есть ли инструменты или утилиты EFI shell, которые Proxmox советует использовать для этого (например, KeyTool.efi или что-то подобное)? Хотим убедиться, что все будущие VM — особенно Windows VM с Secure Boot — будут безопасно загружаться после истечения срока сертификата в 2026 году, и по возможности автоматизировать этот процесс при создании VM. Спасибо!
     
     
     
    powersupport
    Guest
    #2
    0
    28.10.2025 23:11:00
    Привет, спасибо за предоставленную информацию и подробные шаги — это очень помогло! Однако меня больше всего беспокоит сторона Proxmox, а именно: будет ли новый сертификат Microsoft Secure Boot (упомянутый в уведомлении об обновлении от Microsoft) включён в EFI-диск Proxmox при использовании опции pre-enroll-keys. По моим тестам, даже с последней версией Proxmox, EFI-диск пока не содержит обновлённый сертификат. Поэтому хотел бы уточнить у команды Proxmox — добавят ли новый сертификат Microsoft Secure Boot в EFI-диск в будущих релизах, или нужно будет выполнять ручное добавление пользователям? Ещё раз спасибо за помощь!
     
     
     
    uzumo
    Guest
    #3
    0
    29.10.2025 14:57:00
    Внесение таких изменений приведёт к тому, что более старые операционные системы даже не смогут загрузиться, поэтому если Proxmox это изменит, у большинства пользователей возникнут проблемы. Системы с устаревшим загрузчиком вообще не будут стартовать. *Почти все Windows ISO — это загрузчики, использующие устаревшие сертификаты. В таких условиях нужно создать обновлённый ISO и использовать именно его. В таких случаях невозможно установить ОС с помощью почти всех ISO-файлов, распространяемых Microsoft. Это надо решать для каждого гостевого Windows. https://support.microsoft.com/en-au...23-24932-88b8f034-20b7-4a45-80cb-c6049b0f9967 *Не могу представить ситуацию, когда необходима только Митигaция 1. Меры 2–4 обязательны, при этом меры 2 и 4 выполняются не в Proxmox. Кроме того, Мера 3 (отклонение 2011 CA (регистрация в DBX)) вызывает вышеописанные эффекты.
     
     
     
    gfngfn256
    Guest
    #4
    0
    29.10.2025 16:45:00
    Ты что-нибудь делал с этим на самом компьютере? Я провёл тот же тест на своём ПК — тоже вернуло 'false'. Потом проверил следующее:  
    Код: PS C:\WINDOWS\system32> [System.Text.Encoding]::ASCII.GetString((Get-SecureBootUEFI db).bytes) -match 'Microsoft Windows Production PCA 2011'
    True — похоже, это подтверждает, что мой сертификат Secure Boot истечёт в октябре 2026, согласно этому документу. Стоит ли волноваться?
     
     
     
    janus57
    Guest
    #5
    0
    29.10.2025 19:46:00
    Привет! Только что обновил BIOS, чтобы проверить, но результат тот же. Да и нет: компьютер всё ещё может загрузиться, но проблемы будут значительно серьёзнее.

    Источники:  
    https://techcommunity.microsoft.com...boot-certificates-expire-in-june-2026/4426856  
    https://borncity.com/win/2025/06/30/microsofts-uefi-secure-boot-certificate-expires-in-june-2026/

    Как я понимаю ситуацию, для физической машины сертификат должен быть обновлён через обновление BIOS от производителя. Если производитель ничего не сделает, то обновление можно принудительно установить прямо из Windows (я проверял на виртуальной машине Proxmox — работает). И новый ISO Windows перестанет загружаться с использованием старого CA (похоже, это уже актуально для Windows 11 25h2 — сам не тестировал).

    Для справки: https://bugzilla.proxmox.com/show_bug.cgi?id=6985

    С уважением,
     
     
     
    gfngfn256
    Guest
    #6
    0
    29.10.2025 20:12:00
    Основываясь на различных сайтах поддержки Microsoft и объявлениях в базе знаний, которые я быстро просмотрел, можно было бы подумать, что обычные ПК с «нормальными» обновлениями Windows (то есть не управляемые какой-то корпоративной ИТ-инфраструктурой) должны автоматически обновляться через стандартные обновления Windows. Однако, похоже, дело обстоит иначе. Это нужно проверить на практике. (Возможно, вам придётся скорректировать отчёт об ошибке). Даже если это работает, проблема всё равно может сохраняться (как отметил автор темы) в случае с уже установленными Windows в виртуальных машинах, хотя я не уверен, что физические ПК сильно отличаются (см. выше), так что, возможно, это не проблема PVE.
     
     
     
    janus57
    Guest
    #7
    0
    29.10.2025 20:28:00
    Привет, насколько я понимаю, это страховка от Microsoft, но Microsoft всё равно старается получить обновление от производителя (OEM) и включить его в своё объявление/KB, по крайней мере, насколько мне известно. Для меня это не проблема для уже существующих виртуальных машин — они обновятся через Windows Update, как и указано, и будут работать «как обычно». Проблема появится с «новыми» виртуальными машинами (после истечения срока действия) и после переподписывания ISO Windows. Другие ссылки: https://github.com/tianocore/edk2/issues/11281. Важно: в посте от 26 июня 2025 года видно, что Microsoft начинает сотрудничать с OEM за год до истечения срока (что, на мой взгляд, немного поздновато). С уважением,
     
     
     
    gfngfn256
    Guest
    #8
    0
    29.10.2025 20:39:00
    Итак, наши компьютеры уже обновлены с помощью обновления от Microsoft («аварийное обновление»)? Тот тест, который мы оба сделали (поиск по строке «Windows UEFI CA 2023»), показывает что-то? Сколько там вообще компьютеров, которые не получат обновления BIOS — наверное, таких больше, чем тех, кто их получит! Похоже на новый Y2K, который вот-вот взорвётся... Кстати, support.microsoft.com сейчас не работает! Может, их сертификаты уже истекли!
     
     
     
    janus57
    Guest
    #9
    0
    29.10.2025 21:09:00
    Привет! Нет, без ручного редактирования реестра, чтобы принудительно включить это, не получится (пока Microsoft, как я понимаю, ждёт OEM-производителей). Да, если возвращается false — значит на компьютере ещё не установлен новый сертификат UEFI CA. Компьютер продолжит работать, если отключён Secure Boot, так что для домашнего использования это напрягает. Для профессионального же сценария, если крупные компании (HP/DELL/Lenovo и прочие) не выпустят обновление BIOS, многие будут сильно недовольны. В общем, они практически облажались с DNS-записью (да и с TLS-сертификатом ранее тоже). С наилучшими пожеланиями!
     
     
     
    alexhaydock
    Guest
    #10
    0
    30.10.2025 18:10:00
    Думаю, стоит подытожить некоторые моменты из обсуждения, как я их понял:

    Опция EFI Vars `pre-enroll-keys` в Proxmox использует EnrollDefaultKeys.efi из пакета edk2 upstream: https://github.com/tianocore/edk2/tree/master/OvmfPkg/EnrollDefaultKeys. На данный момент в этом пакете зарегистрированы только ключи 2011 года. Win11 25H2 ISO не подписан ключами 2023 года, поэтому он нормально загрузится с EFI Vars, содержащим только ключи 2011 года.

    После установки VM с Win11 25H2 обновляется загрузчик, подписанный ключом 2023 года, из-за чего на EFI Vars с одними только ключами 2011 года загрузка уже не проходит. Я точно не выяснил, с какого обновления это появилось, но скорее всего это связано с KB5036210 или похожим апдейтом. Для ручных установок обычно это не проблема: ISO запускается на ключах 2011 года, а KB5036210 регистрирует новые ключи 2023 года в EFI Vars, и ОС продолжает нормально работать.

    Проблема возникает, если вы собираете образы для развёртывания, где у вас есть полностью обновлённый Win11 25H2 (или, вероятно, Server 2025), но EFI Vars не сохраняется на этапе развёртывания. Тогда при запуске новой VM с зарегистрированными только ключами 2011 года загрузчик, подписанный ключом 2023 года, не стартует — VM не загружается.

    Сегодня я внес коммит в edk2 upstream, добавляющий ключи 2023 года в поток EnrollDefaultKeys. Это значит, что будущие версии edk2 будут содержать новые ключи, и всё будет работать как нужно для полностью обновлённых Win11/2025 VM.

    Дальше ситуация может быть немного сложнее:

    - Пакет `edk2` выйдет в новой версии, вероятно, в конце ноября, согласно их обычному циклу.
    - Debian возьмёт эту версию.
    - Судя по прошлому опыту, скорее всего это не попадёт в Trixie stable, но, возможно, окажется в `trixie-backports`.
    - Proxmox сможет использовать обновлённый пакет edk2 из Trixie.
    - Если Debian не внесёт изменения в стабильный Trixie, Proxmox придётся либо взять патч из `trixie-backports` (если он появится там), либо сделать бэкпорт напрямую из upstream.
     
    Я считаю, что эта проблема достаточно серьёзная, чтобы Proxmox взял на себя задачу с бэкпортом, если понадобится.

    Есть и другие варианты:

    - Proxmox мог бы использовать более гибкий и современный подход Fedora для пакета `edk2-ovmf`, который применяет `virt-firmware` для сборки qcow2-образов размером 4М с зарегистрированными Microsoft ключами: https://gitlab.com/kraxel/virt-firmware
    - Proxmox мог бы полностью перейти на современный подход QEMU 10, где вместо EFI Vars в виде образа, подключаемого как эмулируемый pflash-диск (требующий SMM режима), QEMU напрямую передаёт переменные в VM через отдельное устройство `uefi-vars-x64`, используя JSON-файл на хосте в качестве хранилища (https://www.qemu.org/docs/master/devel/uefi-vars.html).

    Лично для меня второй вариант интереснее — он бы значительно упростил создание образов с пользовательскими цепочками Secure Boot. Это могло бы открыть классные возможности при поддержке в API, например, использование декларативных инструментов для развёртывания кастомных подписанных образов вместе с цепочкой верификации. Но это большой инженерный проект, скорее всего для PVE 10.

    В любом случае, надеюсь, мы найдём путь вперёд, теперь когда появилась правка в upstream. Это важный момент, потому что именно это блокирует мои пайплайны сборки и развёртывания Windows 11/2025.
     
     
     
    t.lamprecht
    Guest
    #11
    0
    17.11.2025 23:30:00
    В данный момент мы выпускаем новую версию qemu-server 9.0.28, которая включает изменения для автоматической регистрации нового CA на затронутых Windows-виртуальных машинах при их следующем чистом запуске.
     
     
     
    jo_strasser
    Guest
    #12
    0
    18.11.2025 08:25:00
    @t.lamprecht С тех пор как я обновил свои PVE серверы до версии 9.0.17 (с qemu-server 9.0.29), все мои Windows 11 виртуальные машины застревают на экране восстановления Bitlocker. Это как-то связано с обновлением? Как можно исправить это без ввода ключа восстановления?
     
     
     
    fiona
    Guest
    #13
    0
    18.11.2025 10:07:00
    Привет, спасибо за отчёт! Я смог воспроизвести проблему. Это значит, что мы не можем автоматически зарегистрировать новый сертификат для существующих дисков с переменными EFI :/ Скорее всего, мы предоставим команду для выполнения этой операции вручную и предупредим пользователей, что это нужно сделать, а также о том, что Bitlocker может потребовать восстановление.
     
     
     
    jo_strasser
    Guest
    #14
    0
    18.11.2025 10:27:00
    Спасибо за подтверждение, @fiona! Да, нужно избегать ситуации, чтобы у клиентов не возникали большие проблемы. Чтобы восстановить мои виртуальные машины, я ввёл ключ. После этого системы работают как положено.
     
     
     
    gfngfn256
    Guest
    #15
    0
    18.11.2025 10:32:00
    Возможно, это также может привести к сбросу активации или лицензии Windows?
     
     
     
    jo_strasser
    Guest
    #16
    0
    18.11.2025 10:38:00
    Нет, у меня всё выглядит нормально (на нескольких машинах после автоматической регистрации).
     
     
     
    fiona
    Guest
    #17
    0
    18.11.2025 10:39:00
    Это довольно странно, потому что старая CA 2011 тоже всё ещё зарегистрирована. Не понимаю, почему Windows считает наличие нового сертификата проблемой, у меня нет доступа к внутренним процессам там. Возможно, это слишком осторожная проверка изменений или что-то в этом роде.
     
     
     
    gfngfn256
    Guest
    #18
    0
    18.11.2025 10:43:00
    Мои точные подозрения и мой последующий пост. Да, именно так! Это как современное здание сегодня, где ни одно "окно" физически открыть нельзя!
     
     
     
    lucius_the
    Guest
    #19
    0
    18.11.2025 19:10:00
    Только что обновился до PVE 9.0.18, в котором есть qemu-server (9.0.30). В примечаниях к выпуску вижу следующее:  
    Код: qm cli: добавлена команда enroll-efi-keys для обновления efidisk в Windows ВМ, у которых ещё не добавлен новый Microsoft UEFI CA 2023.  

    Понимая, что обновление не произойдёт автоматически, кто-нибудь может объяснить, что конкретно нужно сделать, чтобы обновить эти ключи и подготовить Windows-гости к работе?
     
     
     
    Страницы: 1
    Читают тему
    +7 (495) 320-70-49
    info@proxmox.su

    Конфиденциальность Оферта
    © 2026 Proxmox.su
    Главная Каталог 0 Корзина 0 Избранные Кабинет 0 Сравнение Акции Контакты Услуги Бренды Отзывы Компания Лицензии Документы Реквизиты Поиск Блог Обзоры