How to check if your Secure Boot certs are updated. (three methods)

garlin said:

You shouldn't be required to type "powershell -ep bypass -f script.ps1" from inside a PS 7 window. That's lame.

That's why I had to go back, and retest everything so it worked on both PowerShell's.

Click to expand...

That's why I made you, Method Three... in post #3 of this thread.
See posts 1 and 3 in this topic. I edited them.

Personally, I like Method One in this topic.

garlin said:

You shouldn't be required to type "powershell -ep bypass -f script.ps1" from inside a PS 7 window. That's lame.

That's why I had to go back, and retest everything so it worked on both PowerShell's.

Click to expand...

I for one appreciate all the work you've put into this, thanks for all the effort to make this painless!

gunrunnerjohn said:

I for one appreciate all the work you've put into this, thanks for all the effort to make this painless!

Click to expand...

I got 2 out of three machines updated using these scripts, just 1 doorstop to contend with.

Could this be related?
Unable to enter Safe Mode: The digital signature for winload.efi couldn't be verified

Thanks in advance.

Why under UEFI DBX Certs does the first line say (NONE)?

"(NONE)" means you don't have the CA 2011 cert revoked.

I choose to print "(NONE)" so it's more obvious that nothing's installed, rather than someone trying to figure a reason why there are no certs listed for that variable.

garlin said:

"(NONE)" means you don't have the CA 2011 cert revoked.

I choose to print "(NONE)" so it's more obvious that nothing's installed, rather than someone trying to figure a reason why there are no certs listed for that variable.

Click to expand...

Gotcha. Thanks.

Hello could someone just check the results I posted a few days ago here and let me know what (if anything) I should do?

Thanks a lot.

Coresus said:

Hello could someone just check the results I posted a few days ago here and let me know what (if anything) I should do?

Thanks a lot.

Click to expand...

You need to perform the revocation steps. Run the script Check_UEFI-CA2023.ps1 from this post.

It will give you exact instructions on how to finish the process.

what am I suppose to do here I am lost
I had it set for Other OS just before had more green

** What is we use Macrium BCDEDIT Fix ? it will clear the bootloader and such, would that cause issues? on my old computer intel 8xxx I can use secure boot on the windows for some reason it says secure boot violention

this is with Windows Maximum security










This was just before with Other OS









now after I did the Windows commands

it checkmark one more

You must create a recovery drive for computers that don't have a BIOS for 2023 certificates, and therefore the values may be reset to the Secure Boot defaults. The computer will no longer boot. Disabling Secure Boot will work, but you won't be able to update the 2023 certificates with or without scripts because there will be errors in the Event Viewer, such as a TPM/WMI error.

Create a recovery drive from a device where the July 8, 2025 update, or a later update, and the first mitigation step (updating the Secure Boot DB) have been applied. Type "recovery drive" in the Windows search bar to create it. Once finished, in a command prompt as administrator, type these lines (replace the drive letter with the one corresponding to your recovery drive):



You will boot from this USB recovery drive, and upon startup, you will see 4 to 5 lines indicating either that the certificate does not need to be reinstalled (it is already present) or that it has been reinstalled.

This recovery drive will be useful as long as you still have computers without BIOS support for 2023 certificates.

Once the 2023 certificate has been applied using this recovery drive, you will need to repeat the entire procedure to apply the other 2023 certificates and the SVN.

Microsoft calls this the recovery app, the file is securebootrecovery.efi.
If I remember correctly, it's version 1.0. Perhaps there will be other versions to reapply all certificates (even SVN) from this recovery drive in one go.

Edit: If the response from the first command tells you something like "the path already exists," don't worry, just do the second one, it'll work.

securebootrecovery.efi installs a temporary Production CA 2023 into the UEFI so you can continue booting up.

Normally the CA 2023 DB certs are signed by the KEK CA 2023 cert. This recovery Production CA 2023 is signed by a KEK CA 2011, ensuring your CA 2023 boot file is allowed without the presence of a KEK CA 2023.

But it's an emergency hack. It's not designed to do anything except to allow an emergency boot. But unless there's a BIOS password, you can always temporarily disable Secure Boot.

https://uefi.org/sites/default/file...ecure Boot Ecosystem_Flick and Sutherland.pdf

If Windows cannot detect the 2023 Certificates in DB_DEFAULT, Windows update will place a 2011 KEK signed SecureBootRecovery.efi application immediately after Bootmgfw.efi in the boot order carrying a 2011 KEK signed 2023 Production CA

•This ensures the system continues to boot windows if Secure Boot Keys are accidently cleared

Click to expand...

Honestly, you should follow the process outlined:

Because the recovery EFI doesn't restore the other missing certs (it's intended for an accident where you factory reset the UEFI and lose all the CA 2023 changes), it's better you follow the original steps for completeness. The point of this exercise is not just to refresh the certs to 2023, but also to properly ban UEFI exploits using the CA 2011-signed files.

garlin said:

securebootrecovery.efi installs a temporary Production CA 2023 into the UEFI so you can continue booting up.

Normally the CA 2023 DB certs are signed by the KEK CA 2023 cert. This recovery Production CA 2023 is signed by a KEK CA 2011, ensuring your CA 2023 boot file is allowed without the presence of a KEK CA 2023.

But it's an emergency hack. It's not designed to do anything except to allow an emergency boot. But unless there's a BIOS password, you can always temporarily disable Secure Boot.

https://uefi.org/sites/default/files/resources/Evolving the Secure Boot Ecosystem_Flick and Sutherland.pdf


Honestly, you should follow the process outlined:

1. Temporarily disable Secure Boot in BIOS​

2. Boot normally.​

3. Repeat the original Secure Boot update procedure.​

4. Re-enable Secure Boot in BIOS​

Because the recovery EFI doesn't restore the other missing certs (it's intended for an accident where you factory reset the UEFI and lose all the CA 2023 changes), it's better you follow the original steps for completeness. The point of this exercise is not just to refresh the certs to 2023, but also to properly ban UEFI exploits using the CA 2011-signed files.

Click to expand...

It's late... Yes, what you're saying is possible. I experimented with booting using the BIOS without a 2023 certificate. I could not boot without the 2023 certificate, I had to boot from the recovery disk. And I also tried updating the certificates without Secure Boot enabled. I got tpm-wmi errors because Secure Boot wasn't enabled.

The existing MS docs are poor, which is why you have to read the UEFI slides. And it's still confusing.

@garlin i wonder if this is of help updating the secure boot certs
just as a heads up and something you may wish to check please ..

within the Group Policy Editor
Computer Configuration > Administrative Templates > Windows Components

there is a 'Secure Boot' folder with these settings ..
1. Enable Secure Boot Certificate Deployment
2. Automatic Certificate Deployment via Update
3. Certificate Deployment via Controlled Feature Rollout

i have mine all set to 'Enabled'

would these settings/features be of any use to the average user.
best of luck Steve ..

XxXxX said:

@garlin i wonder if this is of help updating the secure boot certs
just as a heads up and something you may wish to check please ..

within the Group Policy Editor
Computer Configuration > Administrative Templates > Windows Components

there is a 'Secure Boot' folder with these settings ..
1. Enable Secure Boot Certificate Deployment
2. Automatic Certificate Deployment via Update
3. Certificate Deployment via Controlled Feature Rollout

i have mine all set to 'Enabled'

would these settings/features be of any use to the average user.
best of luck Steve ..

Click to expand...

Enabling them appears to prevent automatic updating.

I opened up the SecureBoot.admx file, and it reveals:

So these reg values are already referenced here:
Registry key updates for Secure Boot: Windows devices with IT-managed updates

AvailableUpdates = 0x5944 (add CA 2023, but do not revoke CA 2011)

Enabling AvailableUpdatesPolicy does the same as the "reg add". Since the scheduled task runs periodically, it will invoke the "add CA 2023 certs" process in the background at some point. I don't see the advantage of using the GPO, unless someone is scared of copying & pasting commands from an online guide.

garlin said:

I opened up the SecureBoot.admx file, and it reveals:

Spoiler

Code:

    <policy name="SecureBoot_AvailableUpdatesPolicy"
        class="Machine"
        displayName="$(string.SecureBoot_AvailableUpdatesPolicy)"
        explainText="$(string.SecureBoot_AvailableUpdatesPolicy_Help)"
        key="SYSTEM\CurrentControlSet\Control\SecureBoot"
        valueName="AvailableUpdatesPolicy">
      <parentCategory ref="SecureBootCategory" />
      <supportedOn ref="windows:SUPPORTED_Windows8" />

      <enabledValue>
        <decimal value="22852" />
      </enabledValue>
      <disabledValue>
         <decimal value="0" />
      </disabledValue>
    </policy>

    <policy name="SecureBoot_HighConfidenceOptOut"
        class="Machine"
        displayName="$(string.SecureBoot_HighConfidenceOptOut)"
        explainText="$(string.SecureBoot_HighConfidenceOptOut_Help)"
        key="SYSTEM\CurrentControlSet\Control\SecureBoot"
        valueName="HighConfidenceOptOut">
      <parentCategory ref="SecureBootCategory" />
      <supportedOn ref="windows:SUPPORTED_Windows8" />

      <enabledValue>
        <decimal value="1" />
      </enabledValue>
      <disabledValue>
         <decimal value="0" />
      </disabledValue>
    </policy>

    <policy name="SecureBoot_MicrosoftUpdateManagedOptIn"
        class="Machine"
        displayName="$(string.SecureBoot_MicrosoftUpdateManagedOptIn)"
        explainText="$(string.SecureBoot_MicrosoftUpdateManagedOptIn_Help)"
        key="SYSTEM\CurrentControlSet\Control\SecureBoot"
        valueName="MicrosoftUpdateManagedOptIn">
      <parentCategory ref="SecureBootCategory" />
      <supportedOn ref="windows:SUPPORTED_Windows8" />

      <enabledValue>
        <decimal value="22852" />
      </enabledValue>
      <disabledValue>
         <decimal value="0" />
      </disabledValue>
    </policy>

So these reg values are already referenced here:
Registry key updates for Secure Boot: Windows devices with IT-managed updates

AvailableUpdates = 0x5944 (add CA 2023, but do not revoke CA 2011)

Enabling AvailableUpdatesPolicy does the same as the "reg add". Since the scheduled task runs periodically, it will invoke the "add CA 2023 certs" process in the background at some point. I don't see the advantage of using the GPO, unless someone is scared of copying & pasting commands from an online guide.

Click to expand...

i was enquiring because MS has made things regarding secure boot update as clear as mud for most people
so trying to find out exactly what these GPO secure entries do are somewhat vague.

but thank you for taking the time to look at them.
best of luck Steve ..

XxXxX said:

i was enquiring because MS has made things regarding secure boot update as clear as mud for most people
so trying to find out exactly what these GPO secure entries do are somewhat vague.

but thank you for taking the time to look at them.
best of luck Steve ..

Click to expand...

It's annoying that MS has now offered 4 different solutions for forcing updates (by order by release date):

1. Fiddling with AvailableUpdates reg value.
2. Intune policy for enterprises to give control of Secure Boot updates to MS (they push to your site based on telemetry)
3. GPO policy for enterprises (which is AvailableUpdates=0x5944, mirroring the current advice for option 1)
4. WinCSFlags.exe tool (which is even more cryptic about its flag values)

They probably all do the same thing: Allow "\Microsoft\Windows\PI\Secure-Boot-Update" to do the actual work.

The difference is how they feed AvailableUpdates in the background (directly or remotely triggered by some threshold).