Компьютер исправно запускает Windows 11, Secure Boot включён, антивирус не жалуется. Казалось бы, с защитой загрузки всё нормально. Но внутри UEFI могут оставаться сертификаты Microsoft, выпущенные ещё в 2011 году. Срок действия последних из них закончился 19 октября 2026 года. Windows продолжает работать, только новые механизмы защиты загрузчика могут больше не доходить до компьютера.
Microsoft постепенно переводит устройства на сертификаты поколения 2023 года. Обновляются не только доверенные подписи загрузчика Windows, но и ключи, которыми разрешено изменять системные списки доверия и блокировать опасные загрузочные программы. Без обновления компьютер рискует застрять на старой конфигурации безопасности.
Переход оказался сложнее обычной установки исправлений Windows. На части компьютеров требуется новая прошивка UEFI, некоторые производители не предоставили необходимые подписанные ключи, а неудачная смена сертификатов способна привести к запросу восстановления BitLocker или даже отказу загрузки.
Есть и хорошая новость. Истечение срока сертификатов не означает, что миллионы компьютеров одновременно перестали запускаться. Microsoft продолжает поэтапно распространять новые сертификаты через Windows Update. В октябрьских обновлениях компания расширила круг устройств, для которых автоматический переход признан достаточно безопасным.
Разберёмся, как проверить собственный компьютер, какие сертификаты действительно нужны, почему ошибка 1801 не всегда означает поломку и когда без производителя материнской платы проблему не решить.
Команды проверки ниже не меняют настройки UEFI. Обновление сертификатов, перепрошивка BIOS и изменение ключей Secure Boot уже затрагивают загрузочную цепочку. Работайте только со своими устройствами или системами, которые вам разрешено администрировать. Перед изменениями сохраните важные данные и ключ восстановления BitLocker.
Какие сертификаты Secure Boot устарели и почему Windows продолжает загружаться
Secure Boot работает ещё до запуска операционной системы. Прошивка UEFI проверяет цифровые подписи исполняемых компонентов и решает, можно ли передать им управление. Проверку проходят загрузчики операционных систем, некоторые драйверы UEFI и дополнительные программы, запускаемые до Windows.
Прошивка не обращается при каждой загрузке к серверу Microsoft за разрешением. Решение принимается локально на основе ключей, сертификатов и списков запрещённых подписей, которые хранятся в энергонезависимых переменных UEFI.
У механизма четыре основных элемента.
| Элемент | Назначение | Почему важен |
|---|---|---|
| PK (Platform Key) | Главный ключ платформы, которым обычно управляет производитель компьютера | Контролирует смену KEK и принадлежность платформы |
| KEK (Key Exchange Key) | Набор ключей для разрешения обновлений DB и DBX | Позволяет безопасно обновлять правила доверия |
| DB (Signature Database) | База разрешённых сертификатов, ключей и хешей | Определяет, какие подписанные загрузочные компоненты можно запускать |
| DBX (Forbidden Signature Database) | База запрещённых сертификатов, подписей и хешей | Блокирует отозванные и потенциально опасные компоненты |
Представьте, что UEFI доверяет загрузчику, подписанному сертификатом Microsoft. Позже исследователи находят в загрузчике уязвимость, позволяющую обойти защиту. Пока соответствующая подпись или версия не запрещена через базу DBX, старый подписанный файл может оставаться допустимым для запуска.
Именно поэтому одной цифровой подписи недостаточно. Система должна не только распознавать доверенный код, но и своевременно отзывать доверие к опасным компонентам.
Показательный пример связан с буткитом BlackLotus. Вредоносная программа использовала уязвимости в загрузочной цепочке для обхода Secure Boot. Microsoft пришлось выстраивать многоэтапную защиту, включая новые подписи загрузчиков и механизмы отзыва доверия к старым компонентам.
Истечение срока сертификата само по себе не делает криптографическую подпись неправильной. Уже подписанные загрузчики могут продолжать работать, пока сертификат присутствует в DB, а сам компонент не заблокирован политикой отзыва.
Проблема возникает с будущими обновлениями. Старый сертификат больше не подходит для нормального выпуска новых подписей, поэтому Microsoft меняет удостоверяющие центры, а компьютерам требуется научиться доверять новым сертификатам.
Какие сертификаты Microsoft заменяет
| Старый сертификат | Срок действия | Замена |
|---|---|---|
| Microsoft Corporation KEK CA 2011 | 24 июня 2026 | Microsoft Corporation KEK 2K CA 2023 |
| Microsoft UEFI CA 2011 | 27 июня 2026 | Microsoft UEFI CA 2023 |
| Microsoft UEFI CA 2011 | 27 июня 2026 | Microsoft Option ROM UEFI CA 2023 |
| Microsoft Windows Production PCA 2011 | 19 октября 2026 | Windows UEFI CA 2023 |
В таблице четыре новых сертификата вместо трёх старых. Microsoft разделила доверие к сторонним загрузочным приложениям и дополнительным микропрограммам оборудования. Раньше за обе категории отвечал Microsoft UEFI CA 2011. Теперь для загрузочных приложений предусмотрен Microsoft UEFI CA 2023, а для Option ROM используется отдельный Microsoft Option ROM UEFI CA 2023.
Такое разделение позволяет производителю компьютера доверять сторонним загрузчикам, но не обязательно разрешать весь класс дополнительных микропрограмм, или наоборот. Конкретный набор зависит от конфигурации платформы.
Особое значение имеет новый KEK. Microsoft Corporation KEK 2K CA 2023 обеспечивает возможность принимать будущие обновления разрешённых и запрещённых подписей. Но установить KEK недостаточно простым копированием сертификата в Windows. Для изменения соответствующей переменной UEFI требуется авторизация через Platform Key.
Производитель платформы обычно подписывает обновление KEK собственным PK и передаёт пакет Microsoft. Поэтому обновление через Windows Update зависит не только от самой Microsoft, но и от работы производителя оборудования.
Схему перехода и требования к новым компьютерам Microsoft закрепила в правилах управления ключами. Для устройств с Windows 11 начиная с версии 25H2, поставляемых с предустановленной системой, предусмотрены новые сертификаты KEK и Windows UEFI CA 2023. Для компьютеров с Linux и сторонними UEFI-компонентами разрешена более широкая конфигурация доверия.
Главный вывод. Наличие сертификата 2011 года ещё не доказывает, что компьютер небезопасен. Во время перехода старые и новые сертификаты могут сосуществовать. Гораздо важнее наличие актуальных доверенных сертификатов, успешное обновление Windows Boot Manager и возможность продолжать обновлять DBX.
Как проверить сертификаты Secure Boot в Windows 11 и Windows 10
Начать лучше с обычной диагностики. Ничего скачивать и менять в BIOS пока не требуется. Windows позволяет проверить несколько уровней состояния защиты.
Проверяем, включён ли Secure Boot
Нажмите Win + R, введите msinfo32 и откройте окно «Сведения о системе».
Найдите два параметра. «Режим BIOS» должен показывать UEFI, а «Состояние безопасной загрузки» должно иметь значение «Вкл.».
Аналогичная проверка через PowerShell, запущенный от имени администратора, выглядит так.
Confirm-SecureBootUEFIРезультат True означает, что Secure Boot активен. False показывает, что функция поддерживается, но отключена. Ошибка Cmdlet not supported on this platform обычно означает загрузку в режиме Legacy BIOS либо отсутствие поддержки Secure Boot.
Однако True ничего не говорит о поколении сертификатов. Компьютер может использовать старую базу доверия и при этом успешно проходить проверку состояния Secure Boot.
Самый простой способ через «Безопасность Windows»
Начиная с апреля 2026 года Microsoft постепенно добавляет в приложение «Безопасность Windows» отдельные сведения о сертификатах Secure Boot.
Откройте «Безопасность Windows», перейдите в «Безопасность устройства» и найдите раздел Secure Boot. В актуальном интерфейсе можно увидеть, завершён ли переход на новые сертификаты, ожидается ли обновление или требуется действие пользователя.
Есть тонкость. Зелёная отметка возле Secure Boot не всегда подтверждает, что сертификаты обновлены. Нужно проверить текст сообщения. Полностью обновлённая система должна сообщать, что все необходимые обновления сертификатов применены и дальнейшие действия не нужны.
Новые индикаторы внедряются постепенно. Отсутствие дополнительной строки в интерфейсе ещё не доказывает неисправность. Более точные сведения можно получить через реестр и PowerShell.
Проверяем статус обновления в реестре
Откройте PowerShell от имени администратора и выполните команду.
Get-ItemProperty -Path 'HKLM:SYSTEMCurrentControlSetControlSecureBootServicing' |
Select-Object UEFICA2023Status, UEFICA2023Error, UEFICA2023ErrorEventОбратите внимание на UEFICA2023Status. Возможны три основных значения.
| Значение | Что означает |
|---|---|
| Updated | Все необходимые этапы перехода завершены |
| InProgress | Обновление началось, но ещё не завершено |
| NotStarted | Механизм обновления пока не запускал переход |
Параметр UEFICA2023Error содержит код ошибки, если Windows столкнулась с проблемой. Нулевое значение означает, что ошибка не зарегистрирована. UEFICA2023ErrorEvent помогает определить связанный с ошибкой идентификатор события.
На отдельных системах раздел реестра или соответствующие значения могут отсутствовать. Причиной бывает старая версия Windows, отсутствие необходимых накопительных обновлений или ещё не начавшаяся процедура перехода. Не создавайте диагностические параметры вручную.
Проверяем сертификаты непосредственно в UEFI
Реестр показывает состояние работы Windows, а команда Get-SecureBootUEFI читает переменные прошивки. Для проверки базовых сертификатов достаточно двух команд.
[Text.Encoding]::ASCII.GetString((Get-SecureBootUEFI -Name db).Bytes) -match 'Windows UEFI CA 2023'
[Text.Encoding]::ASCII.GetString((Get-SecureBootUEFI -Name KEK).Bytes) -match 'Microsoft Corporation KEK 2K CA 2023'Обе команды должны вернуть True, если соответствующие сертификаты обнаружены в активных переменных DB и KEK.
Проверка через поиск строки в бинарном содержимом подходит для быстрой диагностики. Для строгого аудита большого парка компьютеров лучше разбирать записи UEFI как структуры EFI Signature List и проверять сертификаты по содержимому и отпечаткам.
Даже два результата True не подтверждают автоматически, что Windows уже загрузилась с Boot Manager, подписанным новым сертификатом, и что все этапы закончены. Сверяйте результат с UEFICA2023Status и событием 1808.
После успешного обновления можно также посмотреть, какие значения содержит переменная DBX.
Get-SecureBootUEFI -Name dbxКоманда возвращает бинарные данные списка отзыва, но не показывает простой статус «защита актуальна». Для такого вывода необходимо сравнивать записи с действующей политикой отзыва. Наличие DBX само по себе не подтверждает свежесть базы.
Как обновить Secure Boot и устранить ошибки 1795 и 1801
Большинству владельцев домашних компьютеров достаточно устанавливать накопительные обновления Windows и доступные прошивки производителя. Microsoft распространяет новые сертификаты постепенно, выбирая устройства, для которых имеются подтверждённые данные об успешных обновлениях.
При ручном администрировании порядок другой. Сначала нужно проверить версию прошивки и наличие нужных ключей, затем запустить поддерживаемый механизм обновления Windows и убедиться, что переход завершился.
Почему нельзя просто импортировать сертификат
Сертификаты Secure Boot не работают как обычные доверенные корневые сертификаты Windows. Импорт через certmgr.msc или оснастку управления сертификатами не добавит необходимое доверие в UEFI.
Переменные DB, DBX и KEK защищены правилами авторизации. Изменения должны поступать в формате, который принимает прошивка, и с соответствующими цифровыми подписями.
Windows выполняет работу через системное задание Secure-Boot-Update. Задание запускается при старте системы и регулярно, примерно раз в 12 часов, проверяет, нужны ли дополнительные операции.
Проверить наличие задания можно командой.
Get-ScheduledTask -TaskPath 'MicrosoftWindowsPI' -TaskName 'Secure-Boot-Update'Если задание отсутствует или отключено, обновление сертификатов может не продвигаться. В таком случае нужно разобраться с состоянием Windows и системных компонентов, а не пытаться напрямую переписывать DB и KEK.
Ручной запуск обновления для администраторов
Для управляемых компьютеров Microsoft предусмотрела механизм через параметр AvailableUpdates. Значение 0x5944 запускает последовательность необходимых операций, включая добавление сертификатов 2023 года, обновление KEK и установку нового Windows Boot Manager.
Перед применением команды убедитесь, что устройство действительно нуждается в переходе, Windows обновлена, прошивка совместима, ключ BitLocker сохранён, а конфигурация загрузки проверена. На корпоративных компьютерах процедуру сначала испытывают на нескольких типовых моделях.
reg add "HKLMSYSTEMCurrentControlSetControlSecureBoot" /v AvailableUpdates /t REG_DWORD /d 0x5944 /f
Start-ScheduledTask -TaskName "MicrosoftWindowsPISecure-Boot-Update"Первой командой администратор задаёт необходимые операции, второй запускает системное задание. Для завершения последовательности требуется как минимум одна перезагрузка. После перезапуска можно повторно запустить задание и проверить состояние обновления.
Параметр AvailableUpdates представляет собой битовую маску. По мере успешного выполнения операций Windows сбрасывает соответствующие биты. При стандартном переходе значения могут последовательно изменяться от 0x5944 до 0x4100, а затем до 0x4000.
Значение 0x4000 может оставаться после успешного завершения. Сам по себе ненулевой AvailableUpdates не означает ошибку.
Полную последовательность и значения битов Microsoft описывает в инструкции по реестру. На управляемых устройствах параметры также можно задавать через групповые политики, Microsoft Intune и другие поддерживаемые средства.
Как найти ошибки Secure Boot в журнале Windows
Откройте «Просмотр событий» через eventvwr.msc, выберите «Журналы Windows» и «Система». Ищите сообщения источника TPM-WMI.
Для быстрой проверки последних событий выполните PowerShell от имени администратора.
Get-WinEvent -FilterHashtable @{
LogName = 'System'
ProviderName = 'Microsoft-Windows-TPM-WMI'
Id = 1795,1800,1801,1802,1803,1808,1799,1043
StartTime = (Get-Date).AddDays(-30)
} -ErrorAction SilentlyContinue |
Select-Object TimeCreated, Id, LevelDisplayName, Message |
Format-ListКоманда показывает сообщения за последние 30 дней. Если подходящих событий нет, PowerShell ничего не выведет. Старые записи могли быть удалены при очистке журнала, поэтому отсутствие события 1808 не доказывает отсутствие обновления.
| Событие | Значение и действия |
|---|---|
| 1795 | Прошивка вернула ошибку при изменении DB, DBX или KEK. Проверить код и обновления UEFI производителя |
| 1800 | Для продолжения требуется перезагрузка |
| 1801 | Новые сертификаты и загрузчик ещё не применены полностью |
| 1802 | Обновление заблокировано из-за известной проблемы оборудования или прошивки |
| 1803 | Отсутствует необходимый пакет обновления KEK, подписанный PK производителя |
| 1043 | Новый Microsoft KEK успешно установлен |
| 1799 | Установлен Windows Boot Manager с подписью Windows UEFI CA 2023 |
| 1808 | Все необходимые сертификаты применены, переход завершён |
Ошибка Secure Boot 1801
Событие 1801 часто вызывает лишнюю тревогу. Windows сообщает, что обновлённые сертификаты и загрузчик ещё не применены к устройству полностью. Причина может заключаться в ожидающей операции, поэтапном развёртывании или проблеме, которая мешает завершить обновление.
Само событие 1801 не доказывает, что UEFI повреждён. Сначала посмотрите UEFICA2023Status, наличие ошибок и последние события TPM-WMI. Если обновления Windows установлены, полезно выполнить обычную перезагрузку и снова проверить состояние.
Если журнал показывает 1801 снова и снова, а статус не меняется, проверьте системное задание Secure-Boot-Update, версию BIOS и наличие отдельных событий 1795, 1802 или 1803.
Ошибка 1795 и несовместимость прошивки
При событии 1795 Windows пыталась записать изменения в переменные Secure Boot, но прошивка сообщила об ошибке. Причиной может быть дефект реализации UEFI, несовместимость формата обновления или проблемы с обработкой защищённых переменных.
Начните с определения модели компьютера и версии BIOS.
Get-CimInstance Win32_BIOS |
Select-Object Manufacturer, SMBIOSBIOSVersion, ReleaseDate
Get-CimInstance Win32_ComputerSystem |
Select-Object Manufacturer, ModelЗатем проверьте раздел поддержки конкретной модели на сайте ASUS, MSI, Gigabyte, ASRock, Lenovo, Dell, HP или другого производителя. Ищите обновления с упоминанием Secure Boot certificates, KEK, DBX, UEFI security или исправления ошибок прошивки.
Не устанавливайте BIOS от похожей материнской платы. Если производитель не выпустил исправление, многократное повторение одной команды Windows может ничего не изменить.
Ошибка 1803 и отсутствующий KEK
Событие 1803 имеет более конкретную причину. Windows не нашла подходящий пакет обновления KEK, подписанный ключом PK платформы.
Microsoft не может самостоятельно подписать такой пакет чужим закрытым ключом. Производитель должен предоставить соответствующий материал авторизации.
На старых компьютерах, снятых с поддержки, проблема иногда оказывается неразрешимой стандартными средствами Windows. Даже полностью исправная операционная система не способна заменить отсутствующую подпись производителя.
В отдельных корпоративных конфигурациях владелец платформы самостоятельно управляет PK и может подготовить нужное обновление. Для обычного домашнего компьютера такой путь практически неприменим.
Если ошибка 1803 повторяется, проверьте публикации производителя, доступность свежей прошивки и статус поддержки модели. Случайная загрузка KEK-файлов с форумов не заменяет корректный пакет, подписанный необходимым PK.
BitLocker, Linux и старые BIOS. Где переход на новые сертификаты может сломать загрузку
Переход на новые сертификаты затрагивает не только Windows. Все компоненты, которые запускаются до операционной системы и зависят от текущей политики UEFI, могут столкнуться с изменением доверия.
BitLocker может запросить ключ восстановления
BitLocker использует TPM для защиты ключей шифрования и учитывает состояние загрузочной среды. После изменения Secure Boot, прошивки или порядка запуска параметры измеряемой загрузки могут измениться.
В таком случае компьютер иногда запрашивает 48-значный ключ восстановления BitLocker. Файлы не обязательно повреждены, но без правильного ключа доступ к зашифрованному системному разделу может оказаться невозможным.
Перед прошивкой BIOS проверьте, включено ли шифрование.
Get-BitLockerVolume -MountPoint 'C:'Если BitLocker активен, заранее сохраните ключ восстановления отдельно от самого компьютера. Для личного устройства ключ может храниться в учётной записи Microsoft, а для корпоративного в системе управления ключами организации.
При плановом обновлении UEFI администратор может временно приостановить защиту BitLocker.
Suspend-BitLocker -MountPoint 'C:' -RebootCount 0Значение 0 означает, что защита останется приостановленной до ручного возобновления. Такой режим подходит только для контролируемого обслуживания. На время приостановки снижается защита зашифрованного тома, поэтому компьютер нельзя оставлять без присмотра.
После завершения обновления и успешной загрузки Windows выполните команду.
Resume-BitLocker -MountPoint 'C:'Microsoft отдельно описывает риски восстановления BitLocker при обновлениях UEFI и TPM. Если процесс требует нескольких перезагрузок, приостановка на одну перезагрузку может оказаться недостаточной.
Особенно интересен случай с сетевой загрузкой PXE. Если компьютер сначала пытается загрузиться по сети через старую цепочку доверия, а затем переходит к локальному Windows Boot Manager с новым сертификатом, BitLocker может запрашивать ключ при каждом старте. В такой ситуации помогает правильный порядок загрузки, когда Windows Boot Manager с внутреннего диска стоит первым, либо обновление сетевого загрузчика.
Linux и двойная загрузка Windows
Многие дистрибутивы Linux используют загрузочный компонент shim, подписанный Microsoft. Shim проверяет следующие компоненты загрузочной цепочки, включая GRUB, с учётом соответствующих ключей и политик.
После перехода на сертификаты 2023 года возникают два противоположных сценария. Старый shim, подписанный сертификатом 2011 года, не запустится на компьютере, где доверяют только сертификатам 2023 года. Новый shim с подписью 2023 года не запустится на компьютере, где прошивка по-прежнему доверяет только старому удостоверяющему центру.
Для Linux Microsoft рекомендует сохранять согласованность сертификатов в DB, загрузочных компонентов и механизмов отзыва, включая SBAT. Подробные правила перехода для Linux прямо предусматривают оба сценария.
Проверить состояние Secure Boot внутри Linux можно командой.
mokutil --sb-stateДля просмотра доступных обновлений прошивки на системах с fwupd используйте следующие команды.
sudo fwupdmgr refresh
sudo fwupdmgr get-updatesКоманды не устанавливают обновления автоматически. Параметры доверия в самой UEFI можно дополнительно изучать средствами пакета efitools, например через efi-readvar. При этом список MOK, которым управляет shim, не следует путать с базами DB и KEK самой прошивки.
Перед обновлением на компьютере с двойной загрузкой стоит проверить версии shim и GRUB, обновить дистрибутив и убедиться, что производитель поддерживает необходимую цепочку доверия. Особенно внимательно нужно обращаться с собственными ключами Secure Boot и нестандартными загрузчиками.
Опасность сброса Secure Boot к заводским настройкам
Одна из самых неприятных проблем проявляется уже после успешного обновления. Windows установила новый Boot Manager, подписанный Windows UEFI CA 2023, а пользователь зашёл в BIOS и выбрал Restore Factory Keys.
На старой прошивке заводская база может содержать только сертификаты поколения 2011 года. Сброс возвращает старые записи, стирая новые доверенные сертификаты из активной DB.
Результат выглядит парадоксально. Windows недавно успешно обновилась, но UEFI перестал доверять её загрузчику. Компьютер показывает ошибку Secure Boot или отказывается запускать операционную систему.
Microsoft предусмотрела специальный способ восстановления. Если проблема вызвана отсутствием Windows UEFI CA 2023 после сброса, можно воспользоваться утилитой SecureBootRecovery.efi.
На другом исправном компьютере с Windows, получившем обновления не старше июля 2024 года, найдите файл C:WindowsBootEFISecureBootRecovery.efi. Скопируйте файл на флешку FAT32 в каталог EFIBOOT и переименуйте копию в bootx64.efi. Затем запустите проблемный компьютер с флешки в режиме UEFI.
Утилита восстанавливает доверие к Windows UEFI CA 2023 в базе DB. После успешной загрузки нужно ещё раз проверить состояние остальных сертификатов и установить исправление прошивки, если производитель его выпустил.
Процедура не заменяет полного обновления Secure Boot, поскольку восстанавливает только один сертификат. Использовать её стоит при подтверждённой проблеме с отсутствующим доверием к загрузчику Windows, а не при любой ошибке запуска.
Другой известный дефект возникает, когда прошивка при добавлении нового сертификата перезаписывает всю DB вместо дополнения существующих записей. Если старый загрузчик всё ещё нужен, компьютер может перестать запускаться. Восстанавливать подобную систему следует по инструкции производителя, поскольку обычный сброс ключей не всегда подходит.
Для виртуальных машин также существует отдельный риск. На Hyper-V некоторые ошибки обновления Secure Boot зависят одновременно от версии Windows внутри гостевой системы и от обновлений самого узла виртуализации. Администратору недостаточно проверять только виртуальную машину.
Частые вопросы о сертификатах Secure Boot
Перестанет ли Windows загружаться после окончания срока сертификатов Secure Boot?
Нет, само истечение срока сертификата не приводит к немедленной блокировке Windows. Уже подписанные загрузчики могут оставаться доверенными. Основной риск связан с отсутствием будущих обновлений загрузочной цепочки и списков отзыва. Отказы загрузки возможны при несовместимой прошивке, некорректном сбросе ключей или изменении политик доверия.
Нужно ли срочно менять материнскую плату со старыми сертификатами?
Нет. Возраст компьютера сам по себе не определяет возможность обновления. Некоторые старые системы успешно принимают сертификаты 2023 года через Windows Update. Замена оборудования становится разумным вариантом, когда производитель прекратил поддержку, необходимый PK-подписанный KEK отсутствует, а прошивка не позволяет безопасно обновить конфигурацию доверия.
Достаточно ли включить Secure Boot в BIOS?
Нет. Включённый Secure Boot означает, что UEFI применяет текущую политику доверия. Для полноценной защиты нужны актуальные сертификаты, исправные загрузочные компоненты и своевременно обновляемая DBX. Команда Confirm-SecureBootUEFI не проверяет завершение перехода на сертификаты 2023 года.
Можно ли получить сертификаты Secure Boot 2023 через Windows Update?
Да. Microsoft распространяет новые сертификаты через накопительные обновления Windows и связанные механизмы обслуживания Secure Boot. На части устройств требуется прошивка производителя, а корпоративные администраторы могут управлять переходом через поддерживаемые политики и средства развёртывания.
Почему событие 1801 появляется после установки всех обновлений Windows?
Установка накопительного обновления Windows и применение новых сертификатов в UEFI представляют собой разные этапы. Windows может уже содержать необходимые компоненты, пока прошивка ещё не приняла ключи. Проверьте UEFICA2023Status, работу задания Secure-Boot-Update и наличие событий 1795, 1802 или 1803.
Почему компьютер с Windows и Linux перестал загружать Linux после обновления Secure Boot?
Возможна несовместимость подписи установленного shim с сертификатами, которым доверяет UEFI. Также причиной бывает отзыв старой версии shim или GRUB через DBX либо политику SBAT. Необходимо проверить журнал ошибки, действующие сертификаты, версии загрузочных компонентов и доступные обновления дистрибутива.
Нужно ли удалять старые сертификаты 2011 года после обновления?
Нет. В переходный период старые сертификаты могут сохраняться ради совместимости с существующими загрузчиками, установочными носителями и сторонними EFI-приложениями. Принудительное удаление способно нарушить загрузку. Для запрета конкретных опасных компонентов применяются политики отзыва, а не простое удаление всех старых сертификатов.
Что делать, если Windows 10 не получает новые сертификаты?
Проверьте редакцию Windows 10, условия поддержки, наличие программы расширенных обновлений безопасности ESU или действующей поддержки LTSC, а также доступность обновлений прошивки. Обычная поддержка Windows 10 завершилась 14 октября 2025 года. Обновлённые сертификаты Secure Boot не заменяют регулярные исправления безопасности самой операционной системы.
Можно ли обновить сертификаты Secure Boot после окончания срока старых?
Да, окончание срока не закрывает возможность перехода навсегда. Если производитель предоставил необходимые подписанные пакеты, а UEFI поддерживает обновление, устройство может получить сертификаты 2023 года и после истечения срока предыдущих. Точный способ зависит от прошивки и состояния системы.
Что делать на практике. Начните с трёх проверок. Убедитесь, что Secure Boot включён, посмотрите значение UEFICA2023Status и проверьте наличие события 1808. Если статус Updated, новые сертификаты присутствуют и Windows загружается нормально, ручное вмешательство не требуется.
При статусе InProgress сначала установите доступные обновления Windows, выполните обычную перезагрузку и повторите проверку. Если обнаружены события 1795 или 1803, ищите причину в поддержке прошивки и подписанных ключах производителя. Не сбрасывайте Secure Boot к заводским настройкам наугад и не отключайте защиту ради исчезновения предупреждения.
Мой вывод простой. Главная проблема Secure Boot после окончания срока сертификатов 2011 года заключается не в том, что старая защита внезапно перестала работать. Проблема в постепенной потере возможности защищаться от новых атак на загрузочную цепочку. Поэтому задача владельца компьютера не просто увидеть надпись «Secure Boot включён», а убедиться, что UEFI доверяет актуальному загрузчику Windows, принимает новые ключи и может получать обновления DBX. Именно такой результат имеет смысл считать успешным переходом.
