XPost: alt.comp.os.windows-10
From: nospam@needed.invalid
On Thu, 3/5/2026 10:15 PM, Alan K. wrote:
> On 3/5/26 7:01 PM, Paul wrote:
>> On Thu, 3/5/2026 6:24 PM, Alan K. wrote:
>>> On 3/5/26 6:30 PM, Jack wrote:
>>>> Windows Secure Boot is EXPIRING: Do This Before June 2026!
>>>> Windows Secure Boot certificates are reaching their "End of Life"
>>>> starting June 2026. If you haven't updated your UEFI CA certificates,
>>>> your PC's boot-level security is about to expire and you may have
>>>> serious problems booting up your machine.
>>>>
>>>> This only applies to UEFI boot. On Windows 10 this was not necessary but
>>>> for Windows 11 this is now mandatory. Whether Microsoft updates this
>>>> before they expire remains to be seen but you can manually upgrade it by
>>>> using these PowerShell/Terminal commands as Administrator:
>>>>
>>>> Check if it needs updating:
>>>>
>>>> [System.Text.Encoding]::ASCII.GetString((Get-SecureBootUEFI db).bytes)
>>>> -match 'Windows UEFI CA 2023'
>>>>
>>>> If it shows false then you need to change the registry:
>>>>
>>>> reg add HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Secureboot
>>>> /v AvailableUpdates /t REG_DWORD /d 0x5944 /f
>>>>
>>>> Then run this in Terminal/PowerShell:
>>>>
>>>> Start-ScheduledTask -TaskName "\Microsoft\Windows\PI\Secure-Boot-Update"
>>>>
>>>> Article:
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>> This is so old it's pathetic. 2023. I would sure hope that some
standard MS patch came down the line. It would be a pity if millions of
windows 11 users got hung out to dry.
>>>
>>
>> My recommendation, is to check in the BIOS to see if you can
>> connect a USB stick and back up the four files with the
>> certificates in it. Keeping those four files, gives
>> you the ability to reset the certificate state if there
>> are problems anywhere along the line.
>>
>> As for the proposition, Microsoft is concern-trolling us again,
>> just like the WinRE problem they would not fix for themselves.
>> I am "less excited" this time, at the prospect of messing
>> around with my stuff.
>>
>> Paul
> Paul, for those of us who are unaware of how, can you pass on your expertise
on how to grab those four files and replace them later. As much as I'm not
sure I'll need it but there's nothing like being ready anyway.
>
I didn't realize, that there is an interface at BIOS level, where
you can back up the MOK, db, dbx and the other one, and the BIOS
interface tells you to "plug in a USB stick". Usually, BIOS
features like this use FAT or FAT32 for a file system. There
would be a button in the BIOS, to either back up the four
areas of the secure boot stuff, or do a restore.
You have to find the Secure Boot support area in the BIOS for this.
# Asus example. If you use the > icon next to an item,
# the menu there may allow backing up just that item, like
# just PK (platform key). The Save All puts four files on your
# USB stick.
https://i.sstatic.net/vTJqtwyo.jpg
For example, you can back up the machine key (MOK), then
remove the key, then restart the computer, and it is supposed
to be in "recovery mode". The claim is, that if an OS needed
to adjust the file set there, it could do it if the MOK is removed
and the UEFI is no longer protected. I tried that and Windows
would not touch the thing. So that wasn't a gating item for
maintenance of the materials there. I restored the MOK from
my USB stick, which enables Secure Boot again and prevents
some amount of alteration.
Ubuntu did not have a problem modifying something in either
the .db or .dbx. But because I had not backed up my four
items when the computer was new (I didn't know this feature
was there), I don't have a file set corresponding to "Factory".
And any "reset" feature, stands a chance of leaving four
completely empty silos in there. It's the usual thing
with computer manuals, that the documentation is not
particularly thorough.
Why should customers have to fuck around with this stuff ?
This makes no sense to me. I like a challenge, but this
is turning into just "more of the same", and I am less
game to be treated like a trained puppy.
Ubuntu seems to have no problem injecting two items
into my BIOS, without explicit permission. So if we're
going to be receiving missive after missive to be
manually inserting PCA 2023, it smacks of an attempt
to dodge responsibility for any "damages" to the users
computer, if we can trick the user into doing the messing
around.
Another question I have, is there is PCA 2011 and PCA 2023.
It may be (by some stretch of the imagination), an attack
surface to leave PCA 2011 active in the BIOS. But I don't
believe the certificate is valid past mid-year, and maybe
at that point, whether it is allowed to be present or not
is no longer an issue. If you aren't careful about your
treatment of those two, it restricts what OS(es) you can
boot. And again, we don't want to be put into a position
where the function of the machine is compromised in any way.
*******
In legacy BIOS era, how many concerns would I have ? I would
enable my disks, and the booting was a simple handoff from
legacy BIOS, to whatever I had attached to the computer.
I had complete freedom to use my computer the way I wanted
to.
What do we have today ? Hmmm.
I've warned people in previous years, that there was a
plan afoot to remove legacy (CSM) boot from BIOS soon
(by Intel). And that is likely to be the case for
equipment purchased now. What I don't know, is whether
Secure Boot in UEFI mode, can be switched on and off
as desired or not. Or for that matter, whether any amount
of modifications are to be expected to the UEFI four file
backup thing. The signed Linux shim, is supposed to use
PCA 2023 as part of its root. And in principle, we still
have the ability to boot other things. I don't know
if any FreeBSD-like OSes are included in this or not.
But with UEFI-only machines this year, a percentage
of my DVD collection would no longer boot. Some of my
legacy collection, will boot if you enter "noacpi"
as an option. With the price of hardware though, I
doubt I will be buying any more gear, any time soon.
Paul
--- SoupGate-Win32 v1.05
* Origin: you cannot sedate... all the things you hate (1:229/2)
|
