Act now: Secure Boot certificates expire in June 2026

gunrunnerjohn · Jul 28, 2025

uncyler825 said:
No one told me what problems I might encounter if I forbidden CA 2011. They just tell you that there are risks if you don't do it. As a result, I followed these instructions and encountered some problems.

I contacted the manufacturer in my area, and the staff told me that I could manually import the new certificate according to this article.

You're joking right? That reference is over 800 lines long!

garlin · Jul 28, 2025

That's the MS manual for OEM's. If your OEM's support team provided you that link, they're just lazy.

uncyler825 · Jul 28, 2025

If you are still missing the CA 2023 certificate and you see Event ID 1795 in the Event Viewer. This means Windows is trying to update the certificate but access is denied. Your firmware may be missing the Microsoft KEK certificate, so the Secure Boot denies Windows certificate access.

You can check this with an additional KEK script based on @garlin PowerShell script.

If your "EFI KEK Certificates" is empty. You need to manually download the KEK certificate and add *.der in BIOS. Otherwise you will never get the CA 2023 certificate updated.

Download "MicCorKEKCA2011_2011-06-24.der" and "microsoft corporation kek 2k ca 2023.der" from HERE. You can also download all 2023 certificates and add them.

Reminder: DBX is a certificate blacklist, it is not recommended to add CA 2011 certificate to the blacklist too early.

Then prepare a USB and put these two files into the USB. Enter to BIOS. And navigate to Secure Boot > Key Management

For example. I like to add CA 2023 certificate to DB allowlist. Select DB Management > Append Key

Choose No to load it from a file on external media.

Choose Public Key Certificate.

After completing these actions, exit BIOS.

bikemanAMD · Jul 28, 2025

My Current Results

uncyler825 · Jul 28, 2025

bikemanAMD said:
My Current Results

View attachment 140678

You are fine. You already have the KEK certificate, and Windows can update the DB or DBX in your firmware normally.

bikemanAMD · Jul 28, 2025

Awesome! relaxes on mine then, and gets other PC tasks done today shortly

Akeo · Jul 28, 2025

For the record, ultimately™, the CA-2023 KEK certificate (which, again, is different from the CA-2023 DB certificate) should be installed by Windows itself, as Microsoft has contacted all the manufacturers it knows about to ask them to sign KEK update packages (which only the entity that has access to the private key corresponding to the Secure Boot PK can do), which, eventually™, Microsoft should apply to user's platforms.

See the very relevant secureboot_objects/PostSignedObjects/KEK at main · microsoft/secureboot_objects and the long list of manufacturers it includes.

Now, of course, if your manufacturer closed shop, or if (as you might want to do if you are paranoid about security and don't like the idea of having third parties in control, such as hardware manufacturers that have demonstrated again and again that they are far from being reliable not getting their secrets exfiltrated to bad actors) you installed your own PK, then Microsoft's future™ auto-update of KEK will never work. But at least you can still use Mosby, that installs the new CA-2023 KEK (along with a unique PK that nobody can exploit).

In (very simplified and somewhat inaccurate) layman's term, what you want to know in terms of Secure Boot is that:

PK —(can update)⟶ KEK —(can update)⟶ DB/DBX

So, if you are Microsoft, and you want to add a new certificate, such as CA-2023, to the DB, then you need to have a KEK that you control (which should already be the case with the current 2011 KEK). But with the current Microsoft KEK set to also expire in 2026, once that deadline is gone, the only way Microsoft can update the DB to add a new certificate is they also add the CA-2023 KEK, and the only way to be able to do that is if the manufacturer (who has access to the PK) sign the CA-2023 KEK update package for your specific machine.

Oh and disclaimer: I am, the developer of Mosby.

uncyler825 · Jul 29, 2025

The latest Dev build 26200.5722 still does not fix the issue with installing the old CA 2011 certificate of Windows Boot Manager to EFI partition on a clean installed computer that already has a CA 2023 certificate.

gunrunnerjohn · Jul 29, 2025

Akeo said:
For the record, ultimately™, the CA-2023 KEK certificate (which, again, is different from the CA-2023 DB certificate) should be installed by Windows itself, as Microsoft has contacted all the manufacturers it knows about to ask them to sign KEK update packages (which only the entity that has access to the private key corresponding to the Secure Boot PK can do), which, eventually™, Microsoft should apply to user's platforms.

Any insight what happened here? I had a working system with Secure Boot, but I had to do a reset due to an update going wild. The reset went fine, but if I leave Secure Boot enabled, it doesn't boot. Not sure how I fix this.

I ran the rebuild, it did break one thing. Secure Boot stopped working! I turned off Secure Boot in the BIOS and got it booted up. The question now, is exactly how to fix it.

After seeing this and rebooting and getting it again, I ran MOSBY and replaced the CA Certificates, but that didn't fix it. The site that the BIOS spit out for more information was a bust, it took me to a generic MSC page that has nothing to do with Secure Boot, or booting of any kind.

I have the certificates enabled, but when I enable Secure Boot, no go.

I'm assuming there's something about the repair image that needs updating, but I don't see exactly how I do that.

uncyler825 · Jul 29, 2025

The "C:\Windows\Boot"(install.wim and winre.wim) directory contains the "EFI" and "EFI_EX" folders.

EFI folder = Windows Boot Manager of Windows Production PCA 2011
EFI_EX folder = Windows Boot Manager of Windows UEFI CA 2023

If "Windows Production CA 2011" certificate has been revoked. (Added the certificate to DBX) Clean installation of Windows 11 25H2 (26200.5722 Dev ISO) still installing the old CA 2011 certificate of Windows Boot Manager to EFI partition. So it will be reported security error in the second stage boot.

As a temporary solution. I need turning off Secure Boot in BIOS. Then use the WindowsUEFICA2023Capable PowerShell script to copy the EFI_EX file to the EFI partition. Restart the system and enter BIOS to turn on Secure Boot.

If Microsoft fixes this issue I will report here in which Windows build it is installed.

gunrunnerjohn · Jul 29, 2025

I haven't revoked any certificates. I also turned off Secure Boot to allow the system to boot.

uncyler825 said:
As a temporary solution. I need turning off Secure Boot in BIOS. Then use the WindowsUEFICA2023Capable PowerShell script to copy the EFI_EX file to the EFI partition. Restart the system and enter BIOS to turn on Secure Boot.

If Microsoft fixes this issue I will report here in which Windows build it is installed.

I looked at that script, a little frightening! That looks like more than copying a file to the EFI partition, but maybe that's just me.

uncyler825 · Jul 29, 2025

gunrunnerjohn said:
I haven't revoked any certificates. I also turned off Secure Boot to allow the system to boot.

I looked at that script, a little frightening! That looks like more than copying a file to the EFI partition, but maybe that's just me.

It's just copy the files to the partition, please learn PowerShell. You can write your own PowerShell script. These are all public scripts. You can also see the value of WindowsUEFICA2023Capable changed in the script. Please read the description of WindowsUEFICA2023Capable. This has been mentioned multiple times in this thread.

Aren't you frightening of Check_EFIBootFile.ps1? I think you should not use any scripts or certificates so that you have problems with Secure Boot.

Akeo · Jul 29, 2025

gunrunnerjohn said:
Any insight what happened here?

Yup. The Windows UEFI bootloader (bootmgr.efi) you use is not up to date, and it has been revoked through Microsoft's SVN -- which is really DBX revocation in disguise, as the SVN version that gets checked, i.e. the minimum allowed version you saw in the error message comes from a standard UEFI DBX update. And of course Mosby installs the latest DBX (or, more accurately, there hasn't been a DBX update since our last release of Mobsy), so, when Secure Boot is enabled, bootmgr.efi reads the minimum allowed version from the DBX (currently that would be 5.0), and if it finds that its own internal version (in your case 2.0) is lower than that, it produces the error message you just got.

Normally, if you boot with Secure Boot disabled, and let Windows go through its updates, it should detect that the bootloaders you use are obsolete and update them to versions that aren't revoked, and then boot should work again with Secure Boot enabled. But of course that only works after Windows has been installed and running (and also, since I don't work for Microsoft, I can't vouch that this will always happen -- I just had punctual experience that seems to hint at Windows doing this automatically). If, on the other hand, you are seeing this error during Windows installation, then you will have to redo your media so that all of the bootmgr.efi bootloaders it uses (as well as the boot###.efi ones, such as bootx64.efi to be on the safe side), including the ones that may reside in a .wim inside a .wim, are updated to a version that hasn't been revoked through SVN.

Be very mindful that you might have bootloaders that are signed with CA-2023, and that still have been revoked through Microsoft's SVN, so it's not because you are using CA-2023 signed bootloaders that you are safe from Security Violations when it comes to Secure Boot, as UEFI revocation updates happen regularly on account of new vulnerabilities being found (IIRC there's already been at least 2 DBXs updates since the start of the year, that any modern OS would have applied for you behind the scenes, and that you probably didn't even realize happened, which is exactly how it is supposed to work).

Oh, and as to the issue of the URL being broken, that's been the case for more than a year, and I got annoyed about this enough that I recently reported it to Microsoft (who are still in the process of acting on it)...

gunrunnerjohn · Jul 29, 2025

Well... Magic may have happened. I went and checked updates, and I got a Defender AV update. I figured... what the heck, it's an update, let's see if they noticed. I turned Secure Boot back on in the BIOS and no problem! Say What? I tried that three or four times earlier and couldn't get past that problem!

I guess the question now is, can I disable the 2011 certificates and finish the job?

Akeo said:
Be very mindful that you might have bootloaders that are signed with CA-2023, and that still have been revoked through Microsoft's SVN, so it's not because you are using CA-2023 signed bootloaders that you are safe from Security Violations when it comes to Secure Boot, as UEFI revocation updates happen regularly on account of new vulnerabilities being found (IIRC there's already been at least 2 DBXs updates since the start of the year, that any modern OS would have applied for you behind the scenes, and that you probably didn't even realize happened, which is exactly how it is supposed to work).

So, if I'm reading this right, even if I create a bootable recovery drive for instance, it may suddenly become non-bootable in the future until I disable Secure Boot? This is sounding like it's turning into a can of worms. I think I understand why the Linux folks are saying they just disable Secure Boot!

I'm guessing utilities like Rufus get updated regularly to stay ahead of any revocation of new vulnerabilities being discovered and the minimum allowed version gets incremented so they still boot? I also suspect this probably means my Acronis True Image bootable recovery disk might also be a problem if they don't update them...

Akeo · Jul 29, 2025

gunrunnerjohn said:
I guess the question now is, can I disable the 2011 certificates and finish the job?

No idea. I don't know what you're doing, how you're doing it, and, to be honest, I don't really want to know...

You can try, and see what happens, but please don't expect others to tell you what is likely to happen. Better see it for yourself.

So, if I'm reading this right, even if I create a bootable recovery drive for instance, it may suddenly become non-bootable in the future until I disable Secure Boot?

Well, a good rule of thumb is to consider that every non trivial executable that was ever written (and that of course also applies to UEFI bootloaders) will be discovered to contain a vulnerability eventually, which means that, since you do want the UEFI revocation to do its job, the amount of revoked bootloaders is ever increasing and is likely to, one day, include whatever one you are using right now -- but hopefully with quite a few years between the time you actively need to use that bootloader, and the time it gets revoked.

But this is very much what you want. You do not want your platform to allow the first person who has physical access to it to install a permanent UEFI rootkit, just because you are annoyed about stuff needing to be updated (especially as, again, in most cases, it should happen transparently behind the scenes). If you get a Security Violation with Secure Boot, your reaction should not be annoyance, but instead, it should be relief that your systems is actually actively working to prevent UEFI malware from being installed by literally any person who might have the desire to do so.

I think I understand why the Linux folks are saying they just disable Secure Boot!

Those who trade security for convenience end up with neither.

I'm guessing utilities like Rufus get updated regularly to stay ahead of any revocation of new vulnerabilities being discovered and the minimum allowed version gets incremented so they still boot?

Actually (when you have the check for updates enabled, which is a choice Rufus prompts you for the first time you run it), the Rufus executable does not need to get updated, because it actively checks to see if there has been a DBX update and downloads it, so it can alert you, in near-realtime (if you want to consider that the default 24-hour cooldown on checking for DBX updates is "near-realtime"), if you are using an image with a revoked bootloader. This way, if you obtained your image from a non-reputable source, you can choose to avoid putting yourself at risk, as well as get alerted that you are most likely going to see a Security Violation if the system you are trying to boot is up to date in terms of Secure Boot revocation (which again, is very much what you want to see happen!).

gunrunnerjohn · Jul 29, 2025

Akeo said:
Actually (when you have the check for updates enabled, which is a choice Rufus prompts you for the first time you run it), the Rufus executable does not need to get updated, because it actively checks to see if there has been a DBX update and download it, so it can alert you, in near-realtime (if you want to consider that the default 24-hour cooldown on checking for DBX updates is "near-realtime"), if you are using an image with a revoked bootloader. This way, if you obtained your image from an non-reputable source, you can choose to avoid putting yourself at risk, as well as get alerted that you are most likely going to see a Security Violation if the system you are trying to boot is up to date in terms of Secure Boot revocation (which again, is very much what you want to see happen!).

OK, I really appreciate your assistance, I'm slowly getting it. So if you use Rufus to install a windows image, it's checking the bootloader to see if it's revoked? That does seem like a very useful feature.

I think I'm set, at least for the moment. I guess if I needed to use an older recovery boot disk, I could disable Secure Boot just for that process and then turn it back on.

Winuser · Jul 29, 2025

Is MS starting to update the certificates through Windows Update? The reason I ask is because when I checked the Registry on my two desktops it showed that the WindowsUEFICA2023Capable is set to #2. Desktop #1 is running the latest 24H2 build and desktop #2 is running the latest Canary build. I tried a Macrium rescue disk that I had made earlier on desktop #1 (Powerspec B746) and it worked. Also does the value of #2 mean that the old certificate are no longer valid and my desktops are good to go?

uncyler825 · Jul 29, 2025

Winuser said:
Is MS starting to update the certificates through Windows Update? The reason I ask is because when I checked the Registry on my two desktops it showed that the WindowsUEFICA2023Capable is set to #2. Desktop #1 is running the latest 24H2 build and desktop #2 is running the latest Canary build. I tried a Macrium rescue disk that I had made earlier on desktop #1 (Powerspec B746) and it worked. Also does the value of #2 mean that the old certificate are no longer valid and my desktops are good to go?

You only need to have the new CA 2023 certificate, Current retail ISOs still contain the old CA 2011 certificates, and Windows installations still use the old Windows Boot Manager.

You can following step to validate that Windows Boot Manager is signed by the “Windows UEFI CA 2023” or "Windows Production CA 2011" certificate.

As Administrator, mount the EFI partition to get it ready for inspection:

Code:

mountvol s: /s

Validate that "s:\efi\microsoft\boot\bootmgfw.efi" file is signed by the “Windows UEFI CA 2023” certificate. To do this, follow these steps:

Code:

copy S:\EFI\Microsoft\Boot\bootmgfw.efi c:\bootmgfw_2023.efi

In File Manager, right-click the file C:\bootmgfw_2023.efi, click Properties, and then select the Digital Signatures tab.
In the Signature list, confirm that the certificate chain includes Windows UEFI CA 2023. The certificate chain should match the following screenshot:

If it's “Windows UEFI CA 2023” is using the New Windows Boot Manager.

Windows Update completes these steps automatically without user intervention.

Winuser · Jul 29, 2025

I checked my desktop running the Canary build and I'm not getting the exact box that you posted. If my desktop isn't running the latest certificates then why is the value in the registry set to #2?

uncyler825 · Jul 29, 2025

Winuser said:
I checked my desktop running the Canary build and I'm not getting anything close to what you posted. If my desktop isn't running the latest certificates then why is the value in the registry set to #2?

Windows Boot Manager（In EFI Partition） is the first boot program. The registry does not represent the actual situation because you can modify it at will.

Expiration date	Expiring certificate	Updated certificate	What it does	Storing location
June 2026	Microsoft Corporation KEK CA 2011	Microsoft Corporation KEK 2K CA 2023	Signs updates to DB and DBX	KEK
June 2026	Microsoft Corporation UEFI CA 2011 (or third-party UEFI CA)*	a) Microsoft Corporation UEFI CA 2023 b) Microsoft Option ROM UEFI CA 2023	a) Signs third-party OS and hardware driver components b) Signs third-party option ROMs	DB
Oct 2026	Microsoft Windows Production PCA 2011	Windows UEFI CA 2023	Signs the Windows bootloader and boot components	DB

Act now: Secure Boot certificates expire in June 2026

Recap: Why Secure Boot requires updating​

The change: Expiring certificates​

The impact and implications​

Take action today​

Enterprise IT-managed systems that send diagnostic data​

Enterprise IT-managed systems that don't send diagnostic data​

Systems with Secure Boot disabled​

Change management considerations​

Well-known member

My Computers

Well-known member

My Computer

Well-known member

Attachments

My Computer

Well-known member

My Computers

Well-known member

My Computer

Well-known member

My Computers

Well-known member

My Computer

Well-known member

My Computer

Well-known member

My Computers

Well-known member

My Computer

Well-known member

My Computers

Well-known member

My Computer

Well-known member

My Computer

Well-known member

My Computers

Well-known member

My Computer

Well-known member

My Computers

Well-known member

My Computers

Well-known member

My Computer

Well-known member

My Computers

Well-known member

My Computer

Similar threads

Recap: Why Secure Boot requires updating

The change: Expiring certificates

The impact and implications

Take action today

Enterprise IT-managed systems that send diagnostic data

Enterprise IT-managed systems that don't send diagnostic data

Systems with Secure Boot disabled

Change management considerations