Misinterpretation of the Secure Boot revocation alert of Rufus 4.6

[Creeper2042]

Hi, I downloader the Windows 10 ISO from the official website, but when I try to start the installation it tells me that the ISO may not be official. I checked the SHA code and it is the same instead with the 4.5p version the problem does not arise.

[JonnyTech]

Please do not ignore the issue checklist, especially:

3. If you are reporting an issue when trying to run Rufus, or when trying to
   boot a media created by Rufus, you *MUST* provide a log, period. Please do
   not assume that the developer(s) will be able to "guess" the specifics of
   your environment, what image you used, what type of media you used it with
   or the many many other critical parameters that the log provides data for.
   To investigate an issue, a log from Rufus is ALWAYS required.

4. If you still *choose* not to provide a log when reporting a problem, you
   agree that your issue will be closed without any further investigation.

[pineapple63]

If Rufus gave you a warning about the boot manager, its because the current Windows 10 ISO uses an older, vulnerable boot manager

[pbatard]

To add on @pineapple63's reply:

it tells me that the ISO may not be official.

It is NOT telling you this at all. Instead it is telling you that, on a fully up to date system in terms of Secure Boot security, you may get a Security Violation when booting with Secure Boot enabled, on account that the bootloader has been revoked.

ALL of the official Windows 10 retails ISOs have that issue because they all use a bootloader that is vulnerable to the BlackLotus vulnerability, and Microsoft has not released any updated ISOs for Windows 10 which means that they still use UEFI bootloaders from before when that vulnerability was discovered.

The warning about Secure Boot revocation from Rufus were improved in version 4.6, but please make sure that you read them carefully and do not interpret them to mean something they aren't stating at all.

For more information, see #2244 as well as KB5025885.

[Creeper2042]

So can I safely use that version, I disable secure boot and ignore the warning?

[pbatard]

Yes. Once Windows is installed with Secure Boot disabled, it will update its bootloaders to non-vulnerable versions and you can turn Secure Boot back on again.

[DrStrange]

Yes. Once Windows is installed with Secure Boot disabled, it will update its bootloaders to non-vulnerable versions and you can turn Secure Boot back on again.

I didn't think that Windows automatically updated the bootloader to the CA 2023 certificate? The guidance at https://support.microsoft.com/en-us/topic/kb5025885-how-to-manage-the-windows-boot-manager-revocations-for-secure-boot-changes-associated-with-cve-2023-24932-41a975df-beb2-40c1-99a3-b3ff139f832d states that the date for the Enforcement Phase for permanent mitigation will be issued at a later date, so until then, if you want to install the CA 2023 cert to the secure boot database, sign the bootloader with the CA 2023 cert then add the CA 2011 cert to the UEFI Forbidden List, don't you have to perform these steps yourself as per this guidance?

[pbatard]

don't you have to perform these steps yourself as per this guidance?

Yes. And Rufus does not yet warn about the revocation of the 2011 certificate enacted by following all the steps from KB5025885, otherwise, since Microsoft has not yet produced a single public ISO signed by anything else but the 2011 cert, every single Windows ISO would produce a warning.

So, please be mindful that there are quite a few revocation conditions that Rufus will warn you about, and that despite what many people may think, Rufus does not yet warn about all the revocations it could warn you about, as we are also waiting for the date when enforcement will be mandatory.

[MNLierman]

don't you have to perform these steps yourself as per this guidance?

Yes. And Rufus does not yet warn about the revocation of the 2011 certificate enacted by following all the steps from KB5025885, otherwise, since Microsoft has not yet produced a single public ISO signed by anything else but the 2011 cert, every single Windows ISO would produce a warning.

So, please be mindful that there are quite a few revocation conditions that Rufus will warn you about, and that despite what many people may think, Rufus does not yet warn about all the revocations it could warn you about, as we are also waiting for the date when enforcement will be mandatory.

It's ASTONISHING that we're over a year out and the official DISM and ISO creator tools for creating an unattended Windows 11 ISO, pulled straight from Aria2 contains 5 revoked certs. I don't think this will boot on my laptop, as I'm pretty positive that it's taken the update during the last "unsafe" install. I watched Win 11 24H2, an insecure one, patch the BIOS during install, not even joking, I have a video saved of it doing it. Patched itself because it knew it was an insecure revoked bootloader? To prevent me from ever doing it again? Thanks Microsoft for patching my BIOS but not releasing updating ISO and DISM tools. Assholes. The place ran better with Gates around.

[MNLierman]

I just checked, and it boots, but I'm also correct that during the 24H2 update, which created a Bitlocker Pin Delay (takes 5-7 seconds to fully display all the UI eleements), my BIOS and IMEI firmware was patched. The audit logs indicate in Nov that the keys were updated.

Also, since a few years ago, on all PCs with fTPMs, a maintenance task runs at boot which connects to a Microsoft-run key attestation, update, and SCEP enrollment server hosted on Azure. However, it appears that Microsoft changes these subdomains, and it invalidates chips that haven't been updated with the new URL. It's said that a BIOS / firmware update is required to update the Azure CESP domain. Unfortunately, Microsoft doesn't see this as a priority, there are hundreds of threads online about boot errors due to Microsoft not giving two craps about our security and creating redirectors to the new attestation and update domains, or working closely with OEMs to have the SAME subdomain for all chips. There aren't that many OEMs that they have to work with to make sure they are notified in advance any time they feel the need to revoke a domain.

Here is a sample of that error on my desktop:

SCEP Certificate enrollment initialization for Local system via https://AMD-KeyId-907d65e9b562315997dd5ad086b2b7598957b92c.microsoftaik.azure.net/templates/Aik/scep failed:

GetCACaps
GetCACaps: Not Found
{"Message":"The authority "amd-keyid-907d65e9b562315997dd5ad086b2b7598957b92c.microsoftaik.azure.net" does not exist."}
HTTP/1.1 404 Not Found
Date: Thu, 09 Jan 2025 07:46:58 GMT

Just Googling that keyid you'll find thousands of reports.

Here's from my install just now, I'm on the desktop now and looking at Event Viewer, sure enough, it updated Secure Boot again. I guess they're not revoking the old certs yet.

[github-actions]

This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue if you think you have a related problem or query.