Error when creating new ISO with Updated Secure Boot Certs

mvalpreda

mvalpreda

New Member
Messages
28
Reaction score
5
Did a new Windows 11 25H2 ISO and saw the option for the new secure boot certs - so I added that option to the ISO. Added the lastest 2026-06 (optional) updates as well. Went to boot on a PC and it immediately goes to

Recovery
You PC/Device needs to be repaired
An unexpected error has occured.
Error code: 0xc043001

Secure Boot is enabled.

If I turn off Secure Boot, it gets a little further but then says I am missing \windows\System32\drivers\nvstor.sys after a few minutes. If I use an RTM ISO, it boots fine.

Is this because the BIOS on the machine is old? Or something else going on?
 
Depends, check what the Host is and use that boot manager/sector for the image.

Host's Secure Boot readiness can be seen either by loading C:\Windows as the target and going to Updates / Secure Boot tab.
Or glance at Images page, under C:\Windows operating system, click Secure Boot Host Readiness.

If it states 2011, use that for the image as well.
 
The proper terminology is boot manager (or boot file). "Boot sector" sounds like something from DOS.

A boot device can only have one boot manager (or boot file). If your BIOS hasn't added the new CA 2023 certs, you can't use the newer (CA 2023) boot manager when Secure Boot is enabled. In that case, don't choose the new boot manager.

PC example 1:
- Has CA 2011 certs installed, but missing CA 2023 certs​
- Must not choose new boot manager (accept default of CA 2011 boot file from the ISO)​

PC example 2:
- Has both CA 2011 and CA 2023 certs installed​
- Can choose either default or new boot manager (both are valid)​

PC example 3:
- Has both CA 2011 and CA 2023 certs, but CA 2011 has been revoked (banned)​
- Must choose new boot manager​

NTLite might highlight that a prepared image won't be able to boot on the same host, but if you're using this ISO for another device, that PC might not have the same Secure Boot certs installed. You can make a new ISO with a different boot manager, or just temporarily disable Secure Boot to install Windows and then re-enable it after installation.
 
Thanks garlin for that. I just looked and the PC I am running NTLite on does not have Secure Boot enabled. I'm going to enable that, then make sure I have the new certs installed.
 
Oh....just saw in NTLite
Boot sector: 2011 Windows (Expiring)
So....need to get that updated. Would think that is automatic with updates or something.

EDIT - I checked and it says they are installed....but because Secure Boot is off, that is maybe my issue.
 
When Secure Boot is disabled, you can boot anything you want.
 
Sorry....what I was saying is that PC I ran NTLite on did not have Secure Boot enabled. The PC that I was trying to install Windows 11 does have Secure Boot enabled, but would not boot with it enabled or disabled with the first ISO I created.

I have since enabled Secure Boot on the PC I run NTLite on and going to try creating an ISO again with the new boot manager/certs/etc. Windows 11 25H2 + 2026-06 CU Preview (6/19/2026). Choosing the defaults that NTLite does for updates and adding Windows Package Manager. Then under Secure Boot choosing 2011 for now....since I don't think this PC I want to rebuild has the latest certs installed.
 
garlin said:
The proper terminology is boot manager (or boot file). "Boot sector" sounds like something from DOS.
Click to expand...
The ISO has a separate option for an actual boot sector, unfortunately it needs to be updated as well, Create ISO gives a choice if 2023 is detected.
Of course if you know that's mistaken, please review how the Create ISO presents it on an updated ISO and let me know what to correct.
Thanks.
 
If you have a physical DVD, there is a special boot sector. But everyone uses some tool to convert the ISO image into an USB drive, and the BIOS doesn't use a boot sector on removable USB drives. I honestly don't know what happens if you were to create an actual physical DVD, because no one discusses that procedure.

Instead the UEFI searches on a FAT32 filesystem, for a file named bootmfgw.efi or bootx64.efi (as the fallback if bootmgfw.efi is missing). This file chain boots into winload.efi, which ultimately starts up Windows.

For Windows, bootmgfw.efi and bootx64.efi are identical files, but are sometimes copied to into different locations if the boot media is WinPE-based (bootx64.efi) or WinRE-based (bootmgfw.efi). WinRE implies basically you get a copy of almost all of the extra files (ie. fonts, policy files).

Every W10 22H2 and W11 release has both sets of boot files in parallel folders, \Windows\Boot\EFI and \Windows\Boot\EFI_EX. The only difference being which signing cert is used for each version. The ISO defaults to having the CA 2011 version written to \EFI\Boot\bootx64.efi.

What Rufus or the official MS script Make2023BootableMedia.ps1 does is pick boot files from the EFI_EX (CA 2023) folder.

Suppose we're outside of NTLite or another tool. If you have a pre-existing USB boot device you can switch the boot manager with:

WinPE:
copy C:\Windows\Boot\EFI_EX\bootmgfw_EX.efi E:\EFI\boot\bootx64.efi

WinPE:
bcdboot /s E: /f UEFI /bootex

The difference being if you used bcdboot, don't forget to preserve the original BCD file under \EFI\Microsoft\Boot, because it will get overwritten. Technically you could just remember exactly which files that bcdboot copies, but it's easily to run bcdboot. The rules for updating the boot media equally apply to if you're using Macrium or Hasleo to build a recovery USB.

Old Macrium 8 is too dumb (because it's outdated) to known about the new boot files. Macrium X and Hasleo do know about them.
 
mvalpreda said:
Did a new Windows 11 25H2 ISO and saw the option for the new secure boot certs - so I added that option to the ISO. Added the lastest 2026-06 (optional) updates as well. Went to boot on a PC and it immediately goes to

Recovery
You PC/Device needs to be repaired
An unexpected error has occured.
Error code: 0xc043001

Secure Boot is enabled.

If I turn off Secure Boot, it gets a little further but then says I am missing \windows\System32\drivers\nvstor.sys after a few minutes. If I use an RTM ISO, it boots fine.

Is this because the BIOS on the machine is old? Or something else going on?
Click to expand...
I'm having same issue as well. Custom ISO made using NTLITE has boot manager set to 2023 and has latest update optional updates. The Update boot manager option is selected as well as the option to deploy 2023 cert option under secure boot section. Not sure what I'm missing here. Host machine has 2023 cert loaded in firmware and boot manger is using 2023 cert. To test im using virtual box to create a vm.
 

Attachments

  • Screenshot 2026-07-03 034551.png
    Screenshot 2026-07-03 034551.png
    10.8 KB
  • Screenshot 2026-07-03 034320.png
    Screenshot 2026-07-03 034320.png
    43.8 KB
garlin said:
If you have a physical DVD, there is a special boot sector. But everyone uses some tool to convert the ISO image into an USB drive, and the BIOS doesn't use a boot sector on removable USB drives. I honestly don't know what happens if you were to create an actual physical DVD, because no one discusses that procedure.
Click to expand...
On the "boot sector" term - in NTLite it means the El Torito boot image (efisys.bin / efisys_EX.bin).
That's the embedded FAT image with its own BOOTX64.EFI inside, used when the ISO boots as a DVD or virtual optical drive.
Different file from the loose \efi\boot\bootx64.efi that USB boot reads, and the two can drift apart - you can get a 2023-signed manager sitting over a 2011 sector, then USB boots but
the ISO doesn't (or the other way around).
VMs and network deployments still boot ISOs directly, so that path matters.

No need to verify any of this by hand - NTLite reads it out on the image itself: Boot Manager and Boot Sector as two rows, each with its own signer, the sector one parsed from the El
Torito image directly rather than the filename.
When updating to 2023 it writes both paths, so a split disc can't happen.
Same for the host side: there's a built-in readiness check showing which CA generation the firmware trusts, so you know before choosing 2023 media.

2023 stays opt-in with 2011 as default, same as stock Microsoft ISOs.
For most people the better route is keeping 2011 media and staging the cert update on the installed OS - it enrolls the 2023 CA on first boot, no brick risk.
 
On the topic of building the ISO (or an ISO-to-USB-via-RUFUS) with updated SecureBoot Bootloader/BootManager:

Build host is a WinSvr2025 VM with 2026-Jun SSU/CU (kb5094125)

I have yet to find a mainstream Type-1 or Type-2 HyperVisor that is properly loaded with the DB/DBX; All Hypervisors give the same with NTLite-updated ISOs error 0xC0430001 (*)
  • Hyper-V on the latest Server 2025
  • VMWare Workstation 26H1
  • VMWare vSphere / ESXi 9.1.0.0100.25433460
  • Oracle VirtualBox 7.2.14
(all the latest versions as of the moment of this comment being posted)

(*) This suggests the SVN minimum floor is not met, correct?

Well, if I disable secure boot, install the OS, and run a check - The SecureBoot Floor is set to zero on all three platforms. At least according to PowerShell reporting.

None of these VMs have a comprehensive UEFI setup menu where I can explore closely the status of Certificates in DB or DBX, so we just have to trust the Vendor Documentation and PowerShell reporting or not.

I'm at a loss to explain that.

Conversely, a Dell/EMC PowerMax 16 (MB1625) and Dell/EMC Precision 7780 with the latest BIOS/Firmware boots just fine ( with the same NTLite ISO that fails inside VMs. )
 
Last edited:
bseklecki_ge said:
On the topic of building the ISO (or an ISO-to-USB-via-RUFUS) with updated SecureBoot Bootloader/BootManager:

Build host is a WinSvr2025 VM with 2026-Jun SSU/CU (kb5094125)

I have yet to find a mainstream Type-1 or Type-2 HyperVisor that is properly loaded with the DB/DBX; All Hypervisors give the same with NTLite-updated ISOs error 0xC0430001 (*)
  • Hyper-V on the latest Server 2025
  • VMWare Workstation 26H1
  • VMWare vSphere / ESXi 9.1.0.0100.25433460
  • Oracle VirtualBox 7.2.14
Click to expand...
VMWare at least works fine here.
What does NTLite Host Secure Boot Readiness (link under the Image page C:\Windows) reports on those VMs? If they have an OS that is, or disable Secure Boot, install and skip to step 2.

1. Start with a VM, direct ISO to avoid USB conversion complications for now.
Add latest update and update boot managers ticked.
Then for the ISO boot sector toggle under Create ISO try both 2011 and 2023, depending what the VM is currently.
One must boot.

2. Then after it's installed, track the state from NTLite's Readiness tool to see when it is fully deplyoyed to 2023 and which SVN (should be 9.0 at this point).
 
I will continue to investigate.

I'm eager to hear others` experiences.

I was really surprised to find out that, late last night, Microsoft's approach here is incremental.....all of this is very still a W.I.P. being deployed in a transitional nature.

That can complicate that which I assumed to be a simple test for my client:
  1. Install the latest version of a Type-2 Hypervisor
  2. Install the latest firmware/patches to a Type-1 Hypervisor
  3. Create a brand-new VM container, instantiating a new virtual UEFI instance from the latest template (which is assumed to have:
  • Both he 2023 and 2011 certs in DB
  • The 2011 certs not yet revoked in DBX
  • An SVN of 9.0

But that may not be the case as of 2026-07-24.

I'll go back and boot a LiveCD in each of those HyperVisors and let you know what I find for all three (3x) values above.

I was also surprised to learn that, as part of Microsoft's strategy, they're using "EUFI variables" to temporarily publish new DB and DBX entries into the EUFI firmware that supports this method, e.g., the "Staging" option, so even if that EUFI firmware is dangerously out-of-date (*), it can still accept BootLoaders signed with the new 2023 certs (and optionally they can revoke the 2011)

..... st least until someone goes in an does a BIOS/SETUP reset-to-defaults, then those changes are lost.

(*) (as it tends to be in OT environments with unresponsive and irresponsible OEM hardware vendors selling poorly maintained embedded appliances, like PanelPCs and DIN-rail mounting equipment)
 
bseklecki_ge said:
I was also surprised to learn that, as part of Microsoft's strategy, they're using "EUFI variables" to temporarily publish new DB and DBX entries into the EUFI firmware that supports this method, e.g., the "Staging" option, so even if that EUFI firmware is dangerously out-of-date (*), it can still accept BootLoaders signed with the new 2023 certs (and optionally they can revoke the 2011)

..... st least until someone goes in an does a BIOS/SETUP reset-to-defaults, then those changes are lost.
Click to expand...
There are three methods to adding new Secure Boot keys:

1. Wait for a BIOS update, where the new certs are included as factory defaults. Hope the BIOS update process correctly adds the new certs to current NVRAM. This is the best solution because a "factory reset" will always include the CA 2023 certs.

2. OEM submits a KEK CA 2023 signed by their PK to MS. MS pushes the KEK CA 2023 to your BIOS, but all changes will be lost if a factory reset is invoked (but you can repeat the same process from scratch).

3. Manual enrollment of the KEK CA 2023. Obviously nobody in IT wants this option because it's not scalable in the real world.

For a VM instance, the next best workaround is "cheating" by shutting down the VM, and appending (or replacing) the Secure Boot keys in the VM's copy of UEFI NVRAM. Everyone's got the same problem whether it's Hyper-V, VMware or VirtualBox. But the supported fixes are different.

https://cldlbs.com/blog/secure-boot-2023-certificates-hyper-v-gen2-vms.html
 
Might not be related - but I have been trying to install a clean Win 11 25H2 ISO here for several hours now - one ISO was built yesterday - using the new boot certs and one I did a month ago - without the new certs.

In both cases here today - installing to a known good ASUS Prime z790-A - to a Samsung Pro 990 - this ISO runs the first setup screen to the 78% mark and then does it's first restart and then upon returning - Win Setup displays "Please Wait" - like forever. Can't even Shift-F10 - nothing while this first black screen is being displayed.

I am struggling to understand just what is going on here.

Both ISOs were prepped via Rufus 4.14p as I always do. Both ISOs install successfully in 4 mins flat to a VM

What am I missing here - have never been jammed out like this.

S
 
You must log in or register to reply here.
Back
Top