В конце июня закончился срок действия сразу двух сертификатов, на которых 15 лет держался Secure Boot на всех машинах, выпущенных с 2012 года. И знаете, что произошло? А ничего не произошло. Компьютеры, которым было давно пора на покой, включились, Windows загрузилась, Linux тоже, никто даже не заметил. Вот только успокаиваться еще рано. Потому что кое-что все-таки сломалось. Просто не там, где все искали. Ломается тут не загрузка, а возможность эту самую загрузку защищать, и происходит это молча, без единого сообщения на экране. А 19 октября истекает третий сертификат, тот самый, которым подписан загрузчик Windows. Так что давайте разбираться, что там на самом деле произошло, кому уже стоит начинать волноваться и что делать тем, у кого производитель платы последний раз выпускал BIOS в 2019 году.

Три сертификата, а не четыре

Для начала матчасть, потому что в новостях эти сертификаты путают с завидным постоянством. То пишут, что истекает четыре штуки, то валят в одну кучу KEK и загрузчик. В общем, фантазируют как хотят.

А сертификатов, между тем, ровно 3. Не больше, не меньше:

А четвертый берется вот откуда. Дело в том, что на замену второму из списка Microsoft выдала сразу два сертификата: Microsoft UEFI CA 2023 для сторонних загрузчиков вроде Linux shim и отдельный Microsoft Option ROM UEFI CA 2023 для прошивок плат расширения. В новостях эту пару часто дописывают к истекающим, и выходит четверка. То есть сертификатов 2023 года действительно четыре, а 2011-го – тех самых истекающих – три.

Иерархия там, если совсем коротко, такая:

Наверху сидит PK, платформенный ключ, и принадлежит он производителю железа. Им подписываются KEK – ключи, которые дают право менять две базы: DB, где лежит все разрешенное, и DBX, где все отозванное. Одним из таких KEK владеет Microsoft, и именно через него Windows Update дописывает в эти базы новые записи.

И вот что стоит зафиксировать сразу: PK никуда не истекает, он как был у Lenovo, Dell и ASUS, так у них и остался. То есть цепочка доверия не рушится. Рушится возможность в нее что-то добавлять.

Что именно сломалось 24 июня

Все успокоительные статьи о том, что после истечения срока действия сертификатов ничего не сломается, построены на одном простом факте. И факт этот, надо признать, верный. Заключается он в том, что прошивка, когда проверяет подпись загрузчика, на срок действия сертификата не смотрит вообще. Ей важно, валидная ли подпись и лежит ли сертификат в DB. Просрочен он или нет – ей плевать.

Поэтому все, что было подписано до 24 июня, грузится как ни в чем не бывало и будет грузиться дальше. И загрузчик Windows, и shim в Linux, и прошивки плат расширения, и черт в ступе. То есть в этом смысле действительно ничего экстраординарного не произошло.

А сломалось вот что. Дописывать в DB и DBX можно только то, что подписано KEK, которому прошивка доверяет. Старым ключом Microsoft больше ничего не подписывает – он просрочен, удостоверяющий центр им ничего не выдаст. Значит, все свежие обновления идут за подписью нового, Microsoft Corporation KEK 2K CA 2023. И дальше все зависит от того, лежит этот новый ключ у вас в прошивке или нет.

Если лежит – можно расслабиться, вы ничего не заметили и не заметите, обновления как приходили, так и приходят. Раскатывать сертификаты 2023 года Microsoft начала еще в феврале 2024-го, а массово – с октябрьскими обновлениями 2025 года. Так что у большинства машин, которые исправно обновлялись, все на месте.

А вот если не лежит, тут и начинается самое интересное. Обновление, подписанное ключом, которого у вас нет, прошивка проверить не может – и потому не принимает. А старым ключом ей больше ничего не пришлют. Круг замкнулся: машина навсегда замерзает в том состоянии, в котором ее застало 24 июня. Со своим набором разрешений и со своим списком отзывов – ровно тем, который успел приехать.

Отсюда и главное следствие, о котором почти никто не пишет: все буткиты, чьи отзывы не успели попасть в DBX до этой даты, на такой машине остаются доверенными. Навсегда. То есть Secure Boot вроде включен, галочка стоит, а очередная кампания с давно известным буткитом отработает на ней как по маслу. И BitLocker с TPM тут не помогут, это совсем про другое.

В отчете Eclypsium это сформулировали так: истечение срока действия сертификата уничтожает не цепочку доверия, а способность ее обновлять. Лучше и не скажешь.

И что будет 19 октября

С июньскими сертификатами история, как мы выяснили, тихая: ничего не упало, просто перестало обновляться. Но с октябрьским все немного иначе, потому что Windows Production PCA 2011 – это не про ключи и базы, а про сам загрузчик. Им подписан Windows Boot Manager, то есть самое начало загрузки системы. И после 19 октября Microsoft больше не сможет им ничего подписывать, а значит, исправления для загрузчика на старой цепочке закончатся.

Нет, конечно, в кирпич вашу машину не превратит. Уже подписанный загрузчик как грузился, так и будет грузиться. Просто если завтра в нем найдут очередную дыру уровня CVE-2023-24932, заплатка до вас не доедет. Ни сейчас, ни потом. Даже если воспользоваться оптимизаторами Windows.

А вот что действительно стоит проверить заранее, так это загрузочные флешки. Тот самый диск аварийного восстановления, который вы сделали года три назад и с тех пор ни разу не доставали. Или образ WinPE, которым чинили соседу компьютер. Или, если речь про работу, PXE-сервер, с которого раскатываются свежие установки. Все они несут на себе загрузчик, подписанный сертификатом 2011 года.

Пока в DB лежат оба сертификата, все это грузится нормально. Но история на 19 октября не заканчивается. Следующим шагом Microsoft планирует отзыв PCA 2011, то есть внесение его в DBX, и вот тогда любой носитель со старым загрузчиком превращается в тыкву. Причем в самый неподходящий момент: машина не грузится, вы достаете флешку, а она тоже не грузится, потому что Secure Boot ее больше не пускает. Проверять это в такой момент уже поздновато.

Лечится это просто – пересобрать носители заново после того, как у вас появились сертификаты 2023 года. Macrium, Veeam, обычная установочная флешка из Media Creation Tool: все, что делается сейчас, уже несет новый загрузчик. Для тех, кто не хочет пересобирать образ целиком, есть вариант подменить один файл – и носитель снова рабочий.

Ну и заодно проверьте, что штатная среда восстановления на месте и запускается. У части машин она сломалась еще осенью прошлого года после кривого обновления, и починили это только в марте. А WinRE – это ровно та вещь, отсутствие которой обнаруживается в момент, когда она нужна.

Почему 2023-й – это не просто новые даты

Казалось бы, что тут думать: истек сертификат – выпусти такой же, только с новой датой, и живи дальше. Но Microsoft, раз уж все равно пришлось трогать эту конструкцию, заодно перекроила и саму схему. И вот почему.

Если раньше у нас был один UEFI CA 2011 на все случаи жизни, которым мы подписывали все подряд, то теперь это две отдельные истории: Microsoft UEFI CA 2023 отвечает за загрузчики, а Microsoft Option ROM UEFI CA 2023 – за прошивки плат.

Решение, если разобраться, здравое. Администратору, которому нужно, чтобы работали карты расширения, но совершенно не нужно, чтобы с его машин грузился какой-нибудь посторонний Linux, теперь достаточно положить в DB один сертификат вместо одного на все.

Вот только у этой красоты есть и обратная сторона, до которой мы еще дойдем. Раньше карта и загрузчик ехали по одному пропуску, и если пропуск был – работало все. Теперь пропусков два, и выдают их по отдельности. А значит, вполне возможна ситуация, когда в прошивке платы новый сертификат для загрузчиков уже лежит, а для option ROM – еще нет. И тогда начинаются интересные вещи.

Как проверить, что у вас

Но хватит теории, переходим к практике. Раз уж все зависит от того, доехали до вашей машины сертификаты 2023 года или нет, с этого и начнем. Проще всего посмотреть, что вообще лежит в прошивке. В PowerShell с правами админа:

[System.Text.Encoding]::ASCII.GetString((Get-SecureBootUEFI KEK).bytes) -match 'Microsoft'

Правда, куда человечнее смотреть на ключи реестра, которые Microsoft добавила еще в октябрьских обновлениях 2025 года:

Get-ItemProperty -Path HKLM:\SYSTEM\CurrentControlSet\Control\SecureBoot\Servicing\

Интересуют нас три значения. UEFICA2023Status – это NotStarted, InProgress или Updated. WindowsUEFICA2023Capable показывает, добрался ли до вас новый загрузчик: 0x20 означает, что сертификат в DB и система уже стартует с загрузчика, подписанного по-новому. UEFICA2023Error в идеале должен отсутствовать вовсе.

Если статус Updated, а ошибок нет, то можно выдохнуть и дальше не читать.

Если статус не меняется

Хуже, если статус так и висит в NotStarted, хотя обновления вы ставите исправно. Вариантов тут два, и они принципиально разные.

Первый – до вас просто не доехало. Это лечится руками. Ставим AvailableUpdates в 0x5944 (это битовая маска всех этапов разом) и пинаем задачу, которая сама по себе запускается раз в 12 часов:

reg add HKLM\SYSTEM\CurrentControlSet\Control\Secureboot /v AvailableUpdates /t REG_DWORD /d 0x5944 /f

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

Дальше следим за прогрессией: 0x5944 превращается в 0x4100, перезагружаемся, задача отрабатывает еще раз, получаем 0x4000. А событие 1808 в системном журнале скажет, что все прошло успешно.

Второй вариант куда неприятнее. Событие 1795 в журнале означает, что прошивка отказалась принимать сертификаты, и тут понадобится новая версия BIOS. А вот 1803 с текстом про ненайденный PK-подписанный KEK – это уже совсем грустно. Означает оно, что производитель платы не передал Microsoft KEK, подписанный своим платформенным ключом. Без этого обновление невозможно в принципе, и никакими манипуляциями с реестром вы это не вылечите. Только прошивка от вендора, если он ее вообще выпустит.

И вот здесь мы подходим к самому больному.

Кому не повезло

На событии 1803 мы, собственно, и упираемся в главную беду всей этой истории. Проблема-то ведь не в Microsoft и даже не в Windows. Проблема в том, что нижняя часть цепочки принадлежит производителям железа, а они, как мы все прекрасно знаем, поддерживают свои изделия ровно столько, сколько сами считают нужным.

Плата 2017 года, последний BIOS от 2019-го, вендор про нее давно забыл – история известная. Обновление придет, упрется в отсутствие KEK, и на этом все. Живите как есть.

Отдельная песня – видеокарты. На форумах уже вовсю ловят случаи, когда после появления сертификатов 2023 года машина при включении начинает жаловаться на несовместимость видеокарты с Secure Boot. А причина в том, что VBIOS у карты старый, подписан по-старому, и нового для какой-нибудь GTX 1050 Ti уже никогда не будет. Сценария тут три, по возрастанию боли: раздражающее сообщение при каждом включении, отсутствие картинки до момента загрузки системы или отсутствие картинки вообще и отказ грузиться. Обход обычно один – включить обратно CSM, что само по себе решение так себе.

С сетевыми картами то же самое, только организованнее. NVIDIA в феврале перевела прошивки ConnectX и BlueField на 2023-й CA и прямым текстом написала: чтобы ExpROM загрузился при включенном Secure Boot, в BIOS и в хранилище доверия должен лежать Microsoft Option ROM UEFI CA 2023. Нет его – не будет и загрузки прошивки карты.

Ну и совсем грустная категория – машины на Windows 10. Новые сертификаты приезжают только тем, кто подписан на ESU. Не подписан – значит, не получишь, при этом система продолжает работать и создавать полное ощущение, что все в порядке. А учитывая, что у нас на десятке до сих пор сидит больше половины пользователей, да и официальный доступ к ESU в России закрыт, картина вырисовывается специфическая.

Что с Linux

Пока владельцы старых плат считают убытки, у линуксоидов все, как ни странно, вышло аккуратнее. Начиная с октября 2025 года Microsoft подписывает shim сразу обоими сертификатами, старым и новым, поэтому грузится он и там, и там. Ubuntu, Fedora, AlmaLinux – все свежие shim двойные.

Сертификаты 2023 года в прошивку ставятся через fwupd:

fwupdmgr refresh && fwupdmgr update

Проверить, что лежит в хранилище, можно через mokutil --db. Если видите только 2011-й, стоит сходить за прошивкой к вендору.

Есть, правда, один нюанс, который стоит держать в голове. Если кто-то надумает добавить 2011-й сертификат в DBX, то есть отозвать его, двойной shim грузиться перестанет, потому что отзыв срабатывает по любой из подписей. Пока этого никто не делал, но Microsoft уже вносила в DBX одиннадцать уязвимых shim задним числом, так что механизм вполне рабочий.

Что делать по итогу

Если собрать все вышесказанное в один список, порядок действий получается такой:

1. Проверить статус. UEFICA2023Status в реестре. Updated – вопросов нет. Все остальное требует разбирательства.

2. Если NotStarted – попробовать руками. AvailableUpdates = 0x5944, запустить задачу Secure-Boot-Update, перезагрузиться, повторить.

3. Посмотреть журнал. 1808 – успех. 1795 – нужна новая прошивка. 1803 – вендор не сделал свою часть работы, и это приговор.

4. Сходить за BIOS. Даже если вы не обновляли его с момента покупки. Сейчас тот случай, когда стоит.

5. Проверить видеокарту и сетевые карты, если они старше 2020 года и у вас Secure Boot включен.

А чего делать не стоит, так это лезть в BIOS и чистить ключи через Restore Factory Keys в надежде, что после этого все встанет само. Не встанет. А вот заблокировать себе загрузку таким способом очень даже можно.

Ну и напоследок. Если ваша машина попала в категорию безнадежных, где прошивки не будет уже никогда, выбор выходит простой. Либо вы живете с Secure Boot, который больше не обновляется и защищает ровно от вчерашних угроз. Либо признаете, что в вашей схеме безопасности он больше не участвует, и выстраиваете защиту на других уровнях. А вот третий вариант – считать, что раз галочка стоит, то все под контролем – самый плохой. Потому что это ровно то состояние, на которое авторы буткитов и рассчитывают.