PCs without the new certificates could eventually have trouble booting new OSes.
See full article...
See full article...
You’re fine. The NVRam on your system has been updated.So... my Asus mobo (ROG Strix Z390-E Gaming) is from 2018, and while the code Andrew provided for PowerShell shows I'm OK for the new cert, I get "False" for Default DB.
That got me to finally update my mobo yesterday to the latest available from Asus (from 2024), and I followed their really (IMO) crappy broken English instructions that were linked, but I'm still seeing "false" when I check the default db via PowerShell.
Asus vaguely suggests that Windows 11 will update the keys at some point, but that's about it. Is that the case?
Like Arkeo said above, we need a follow-up. I wouldn't have even know about this if I hadn't seen this article.
Set-ItemProperty -Path “HKLM:\SYSTEM\CurrentControlSet\Control\SecureBoot” -Name “AvailableUpdates” -Value 0x40Start-ScheduledTask -TaskName “\Microsoft\Windows\PI\Secure-Boot-Update”To some extent, I mean, security is an onion and you want as many layers as possible. But if you have some malware attacking your bootloader things have gone pretty deeply wrong.
Yes, preventing the PC from even booting into the OS install media definitely ensures total security.
Yeah, I reset the keys following Asus instructions for "Method II", and when I went to check that the keys had indeed been updated ("Confirm that KEK Management contains "Microsoft Corporation KEK 2K CA 2023"" & "Confirm that DB Management contains both "Microsoft UEFI CA 2023" and "Windows UEFI CA 2023""), I found that they did not match what Asus said they should be.I have a ROG Zephirus G14 from 2022, running Windows 11 25H2 (26200.7705) and with the latest official BIOS (3.19 from August 2023)
So for devices where a BIOS update adds the new cert it is necessary to reset the Secure Boot keys to update the certs in NVRAM, it seems.
Well, there is MoK - "Machine owner Key" - basically, self signing the boot binary so that this one machine will boot it.When 'secure boot' was originally announced, Microsoft 'helpfully' offered to hold the keys for everyone, and sign the acceptable EFI for everyone; so redhat, ubuntu, etc all need to get their install binary (or at least the boot part of it) signed by Microsoft before they can be used on a secure boot system.
Since this article is referencing the set of keys that those binaries can be signed by, then it is reasonable to assume that this will matter; not today, as all the existing binaries are signed with existing older keys; but tomorrow, when new binaries start being signed with new keys that existing and older UEFI FW may not have loaded.
What is missing in my head is, if I boot Linux with secure boot off today, is there any way I can load a new key into secure boot's nvram and have it recognised, so I can turn secure boot on and run a liveCD from ubuntu/redhat/SuSe that depends on that new key?
(I know there is a mechanism to enroll new binaries, because installing the nVidia driver on a secure-booted Linux distro requires that I dream up a passphrase, reboot to bios time, enter the passphrase on the UEFI prompt and agree to allow that binary to load; but I can't see if that applies to keys themselves and all the fun that implies)
Latitude 7490? There have been steady releases of new versions.Dell doesn't seem better, my Dell 7490 hasn't gotten a BIOS update since ... 2018, the year of release. The problem is of course that it's a "modern" hexacore, meaning it can still do normal things (web, movies) without the fans even turning on and it'll even handle light games quite alright but apprently it's too old to function anyway.
Interesting. I have the same mobo as you and I get False for both checks. I also see the message in Event Viewer mentioned above indicating the certs are available but have not yet been applied to the firmware. Any idea what I need to do to get Windows to use the new certs to boot? I'm already on Win 11 25H2.So... my Asus mobo (ROG Strix Z390-E Gaming) is from 2018, and while the code Andrew provided for PowerShell shows I'm OK for the new cert, I get "False" for Default DB.
That got me to finally update my mobo yesterday to the latest available from Asus (from 2024), and I followed their really (IMO) crappy broken English instructions that were linked, but I'm still seeing "false" when I check the default db via PowerShell.
Asus vaguely suggests that Windows 11 will update the keys at some point, but that's about it. Is that the case?
Like Arkeo said above, we need a follow-up. I wouldn't have even know about this if I hadn't seen this article.
Updated NVRAM doesn't always mean updated certs in the NVRAM. That's why someone gets false for the "dbdefault" check.You’re fine. The NVRam on your system has been updated.
They went to the effort to release an updated in 2024 to fix the LogoFAIL vulnerability (and improve system stability) after no updates since 2021, so why would they not bother to toss in the new certs, which were available long before that. It can't be so much more work to add in the function to update the certs in NVRAM that they didn't want to waste the additional resources when they were already updating such a legacy platform, can it? And they probably already would have had the code basically done since they were updating more recent boards, needing minor changes to work for this board, unless they hadn't even started updating any of them.According to https://zentalk.asus.com/t5/motherb...-update-for-rog-strix-z390-e-bios/td-p/498418 the latest BIOS for that board does not include the certs and there are no plans for a version that will.
don't set an expiry date in the certificate?I'm so sick of expiring certificates breaking old devices. We need something better than this, though no clue what that would look like
I'm in IT, and Secure Boot is something that we absolutely require as part of our CIS standard for Windows 11. Apple has an equivalent called Secure Boot. Its purpose is to ensure only software verified by Apple can load during the startup process.
I'm shocked at the down votes on my original comment. I thought all of this was basic security knowledge?
Interesting. I have the same mobo as you and I get False for both checks. I also see the message in Event Viewer mentioned above indicating the certs are available but have not yet been applied to the firmware. Any idea what I need to do to get Windows to use the new certs to boot? I'm already on Win 11 25H2.
According to https://zentalk.asus.com/t5/motherb...-update-for-rog-strix-z390-e-bios/td-p/498418 the latest BIOS for that board does not include the certs and there are no plans for a version that will.
Thanks! I have a relatively recent (~3 yr old) Lenovo laptop (IdeaPad Flex) that came with Win11. They're simply silent about updates for it. Last bios update was in 2024. So I'm expecting a brick in June. The article's ps scripts say I have the new cert in the DB, but not in the default db which requires firmware update. Will try your alternative, which might also be needed for herself's slightly older Asus.I'm running a "not very" old Lenovo Legion laptop that just missed the requirements to officially run Windows 11 (which I'm running) and Lenovo has it listed as out of support so no firmware update with new keys for me.
I found the instructions here to update the certificate actually worked: https://www.elevenforum.com/t/did-you-manually-update-your-secure-boot-keys.36443/
You basically have to run these two commands in an admin powershell and then reboot twice:
Set-ItemProperty -Path “HKLM:\SYSTEM\CurrentControlSet\Control\SecureBoot” -Name “AvailableUpdates” -Value 0x40
Start-ScheduledTask -TaskName “\Microsoft\Windows\PI\Secure-Boot-Update”
And ... while I have a problem with the more recent Lenovo laptop that came with Win11, the older (MSI Z490 PRO with 10th gen i5) passes all the tests. So 'legacy' stuff can be patched.They went to the effort to release an updated in 2024 to fix the LogoFAIL vulnerability (and improve system stability) after no updates since 2021, so why would they not bother to toss in the new certs, which were available long before that. It can't be so much more work to add in the function to update the certs in NVRAM that they didn't want to waste the additional resources when they were already updating such a legacy platform, can it? And they probably already would have had the code basically done since they were updating more recent boards, needing minor changes to work for this board, unless they hadn't even started updating any of them.
Dell doesn't seem better, my Dell 7490 hasn't gotten a BIOS update since ... 2018, the year of release. The problem is of course that it's a "modern" hexacore, meaning it can still do normal things (web, movies) without the fans even turning on and it'll even handle light games quite alright but apprently it's too old to function anyway.
Thanks! I have a relatively recent (~3 yr old) Lenovo laptop (IdeaPad Flex) that came with Win11. They're simply silent about updates for it. Last bios update was in 2024. So I'm expecting a brick in June. The article's ps scripts say I have the new cert in the DB, but not in the default db which requires firmware update. Will try your alternative, which might also be needed for herself's slightly older Asus.
As someone currently in the process of moving to Linux from Windows, all I can say is "BS." I won't bother listing the numerous issues I've encountered on my quest to install Mint (massaged Ubuntu) on my laptop, but I will mention the most serious.
My laptop won't currently boot into Mint, probably because of a change I made (using the GUI) to the resolution of my two monitors. It was perfectly happy talking to both of them and then I foolishly rebooted. Now the Linux installation is effectively bricked.
My 2016 HP Precision 7810 from 2016 last had a BIOS update in 2016. And still works fine too*. And I use it for computationally intensive work.Dell doesn't seem better, my Dell 7490 hasn't gotten a BIOS update since ... 2018, the year of release. The problem is of course that it's a "modern" hexacore, meaning it can still do normal things (web, movies) without the fans even turning on and it'll even handle light games quite alright but apprently it's too old to function anyway.
“However, the device will enter a degraded security state that limits its ability to receive future boot-level protections. As new boot‐level vulnerabilities are discovered, affected systems become increasingly exposed because they can no longer install new mitigations. Over time, this may also lead to compatibility issues, as newer operating systems, firmware, hardware, or Secure Boot–dependent software may fail to load.”
I agree 100%, I've only seen this issue reported here on Ars but this is serious. It's not W11 or Linux (if you're still stuck there please don't bother), it's both: it's the damn BIOS or UEFI or Secure Boot. I tried to follow on from OP to Microsoft's, per the link provided, but it immediately became incomprehensible (I can recompile the Kernel, but this is totally new and totally beyond me). I downloaded the .crt file and installed it, both PowerShell prompts still report False.So... my Asus mobo (ROG Strix Z390-E Gaming) is from 2018, and while the code Andrew provided for PowerShell shows I'm OK for the new cert, I get "False" for Default DB.
That got me to finally update my mobo yesterday to the latest available from Asus (from 2024), and I followed their really (IMO) crappy broken English instructions that were linked, but I'm still seeing "false" when I check the default db via PowerShell.
Asus vaguely suggests that Windows 11 will update the keys at some point, but that's about it. Is that the case?
Like Arkeo said above, we need a follow-up. I wouldn't have even know about this if I hadn't seen this article.
It's just the way M$ handles these things, then people get angry - you know the drill.I'm in IT, and Secure Boot is something that we absolutely require as part of our CIS standard for Windows 11. Apple has an equivalent called Secure Boot. Its purpose is to ensure only software verified by Apple can load during the startup process.
I'm shocked at the down votes on my original comment. I thought all of this was basic security knowledge?
It's not happening. Your system will continue to boot. It will only fail to boot if bootx86.efi is updated to a new version signed with the new cert without updating the cert.It's just the way M$ handles these things, then people get angry - you know the drill.
But if the original article is correct this is indeed a MAJOR fsck up - I built my desktop and paid the W11 license ($10), I bought my wonderful HP ProBook, and by June I won't be able to boot?
Read again the lines above, something like this should not happen.
Still False for me. I'm beginning to get uncomfortable- the HP laptop is my test system because it works wonderfully with W10, W11 and any GNU/Linux distro you can think of. The desktop is for gaming and/or writing (2 4K screens). False as well.I just followed the instructions Snake JG posted above, which include a line of code to check if the process was successful.
What's interesting is that that line of code is almost identical to the line that was included in the article to check the default db: "The second thing to check is the “default db,” which shows whether the new Secure Boot certificates are baked into your PC’s firmware".
I've bolded the difference between the two lines below.
The code from the article is:
([System.Text.Encoding]::ASCII.GetString((Get-SecureBootUEFI dbdefault).bytes) -match 'Windows UEFI CA 2023')
The code from the instructions in the link above is:
[System.Text.Encoding]::ASCII.GetString((Get-SecureBootUEFI db).bytes) -match ‘Windows UEFI CA 2023’
After I'd completed the process and restarted twice, I ran the code from the instructions in the link in terminal as admin, and got a "True" return.
Then, for shitzengiggles, I ran the code from the article in terminal as admin, and got a "False" return.
I assume I'm good to go?
It’s literally reading the certificate description from the NVRAM. If it comes back as true, then the certificate is there.Updated NVRAM doesn't always mean updated certs in the NVRAM. That's why someone gets false for the "dbdefault" check.
It's not happening. Your system will continue to boot. It will only fail to boot if bootx86.efi is updated to a new version signed with the new cert without updating the cert.
Microsoft is doing a staged release, with the new key being installed being a requirement before an updated bootx86.efi is installed. Not that they couldn't screw it up, but they're not going to intentionally brick your system.
The steps will be to stage the new cert, install it, verify it's installed, then install a newly signed bootx86.efi with each step having to succeed.
If you're on a Win10 system that's getting updates, same thing. If you're not getting updates, no problem because bootx86.efi won't get updated and will still match the old cert.
Thanks for clarifying!It's not happening. Your system will continue to boot. It will only fail to boot if bootx86.efi is updated to a new version signed with the new cert without updating the cert.
Microsoft is doing a staged release, with the new key being installed being a requirement before an updated bootx86.efi is installed. Not that they couldn't screw it up, but they're not going to intentionally brick your system.
The steps will be to stage the new cert, install it, verify it's installed, then install a newly signed bootx86.efi with each step having to succeed.
If you're on a Win10 system that's getting updates, same thing. If you're not getting updates, no problem because bootx86.efi won't get updated and will still match the old cert.
It's interesting that both of us who have real experience with Linux problems are being downvoted for suggesting that switching to Linux isn't as easy as the fanbois would have us believe. Confirmation bias is rampant in this forum.Yeah... I've been dabbling in Linux for about 20 years (I still have the stickers that came with the Ubuntu 6.06LTS CDs!) and I have not once had an installation where everything just worked the way Windows did. It's been alright, but it there is always something that just doesn't work, like background lightning on laptop keyboards, power saving options, network shenanigans. It's always been something. I still recommend more people getting into it, but I asbolutely agree it's in no way as universally working as well as Windows.
It's a dual socket workstation, a bit different beast than a modern laptop. Anyway here's a BIOS from 2020, but double check. Personally I'm just going to keep to Windows 10 on the desktop.My 2016 HP Precision 7810 from 2016 last had a BIOS update in 2016. And still works fine too*. And I use it for computationally intensive work.
* Actually, it causes me fewer headaches than my Surface Laptop Studio purchased in 2023
I even joined the Win10 ESU to try to keep it going longer. But this part slightly concerns me:
Although, in fairness, the ESU was only fixing things until next fall, so it was only a matter of time anyways.
While I truly appreciate the sentiment this doesn't feel like an OS-related issue: SB (and the mess M$ is making) affects UEFI, not W11 or Ubuntu or Debian specifically.It's interesting that both of us who have real experience with Linux problems are being downvoted for suggesting that switching to Linux isn't as easy as the fanbois would have us believe. Confirmation bias is rampant in this forum.
I just followed the instructions Snake JG posted above, which include a line of code to check if the process was successful.
What's interesting is that that line of code is almost identical to the line that was included in the article to check the default db: "The second thing to check is the “default db,” which shows whether the new Secure Boot certificates are baked into your PC’s firmware".
I've bolded the difference between the two lines below.
The code from the article is:
([System.Text.Encoding]::ASCII.GetString((Get-SecureBootUEFI dbdefault).bytes) -match 'Windows UEFI CA 2023')
The code from the instructions in the link above is:
[System.Text.Encoding]::ASCII.GetString((Get-SecureBootUEFI db).bytes) -match ‘Windows UEFI CA 2023’
After I'd completed the process and restarted twice, I ran the code from the instructions in the link in terminal as admin, and got a "True" return.
Then, for shitzengiggles, I ran the code from the article in terminal as admin, and got a "False" return.
I assume I'm good to go?