Ubuntu 24.04.4 LTS
This keeps popping up and I don’t know what itmeans. Ubuntu works so well that I have become a cretin about its functioning. I have no idea whether I should update firmware and, if so, how I would do that.
Don’t talk to me like a child - they’re much too smart. Talk to me like an old feeb.
Hello JamButty 
I do expect that a general software update will fix you right up.
I am terminally minded (as I like to see/know what takes place); my advise is from the terminal:
open a terminal with key codes ctl+alt+t
here execute commands:
sudo apt updateyou will be required to enter your password - enter the password blindly.
Next execute:
sudo apt upgradereboot to see the effect.
Cheers
This should clarify the purpose of the update in question:
There is also this LWN article, courtesy of Brian “bex” Exelbierd of Microsoft, for some more background:
https://lwn.net/Articles/1079808/
As for the other questions, I think, this thread should have all the answers.
In short, you can just click that notification and the firmware updater will apply the update and ask for a reboot. It’s a pretty standard and safe operation.
Yes and no.
Took the install directly from the popup notification. After finishing and rebooting, I checked per that article on how to confirm that the updates are complete.
It lists three keys I should have:
Subject: C=US, O=Microsoft Corporation, CN=Microsoft UEFI CA 2023
Subject: C=US, O=Microsoft Corporation, CN=Microsoft Option ROM UEFI CA 2023
Subject: C=US, O=Microsoft Corporation, CN=Microsoft Corporation KEK 2K CA 2023
I had the first two, UEFI keys, but not the third KEK key.
As the article states the fwupdmgr must be up to date, I ran the refresh and updates on it and rebooted. However, after the boot, I still had the 2011 KEK key.
So something is still missing. I do not know how to get that third needed key.
For whatever it is worth, here is the full output:
fred@fred-Inspiron-3847:\~$ mokutil --db | grep ‘Subject:’
Subject: C=US, ST=Washington, L=Redmond, O=Microsoft Corporation, CN=Microsoft Windows Production PCA 2011
Subject: C=US, ST=Washington, L=Redmond, O=Microsoft Corporation, CN=Microsoft Corporation UEFI CA 2011
Subject: C=US, O=Microsoft Corporation, CN=Microsoft UEFI CA 2023
Subject: C=US, O=Microsoft Corporation, CN=Microsoft Option ROM UEFI CA 2023
fred@fred-Inspiron-3847:\~$ mokutil --kek | grep ‘Subject:’
Subject: C=US, ST=Washington, L=Redmond, O=Microsoft Corporation, CN=Microsoft Corporation KEK CA 2011
fred@fred-Inspiron-3847:\~$ fwupdmgr --version
compile info.libusb 1.0.27
compile com.hughsie.libxmlb 0.3.24
compile com.hughsie.libjcat 0.2.3
compile org.freedesktop.fwupd 2.0.20
runtime org.freedesktop.fwupd-efi 1.4
runtime com.hughsie.libxmlb 0.3.24
runtime com.hughsie.libjcat 0.2.3
runtime org.kernel 6.8.0-134-generic
runtime org.freedesktop.fwupd 2.0.20
## fred@fred-Inspiron-3847:\~$ sudo fwupdmgr refresh
\[sudo\] password for fred:
Metadata is up to date; use --force to refresh again.
fred@fred-Inspiron-3847:\~$ sudo fwupdmgr update
╔══════════════════════════════════════════════════════════════════════════════╗
║ Upgrade UEFI dbx from 20250507 to 20260402? ║
╠══════════════════════════════════════════════════════════════════════════════╣
║ This updates the list of forbidden signatures (the “dbx”) to the latest ║
║ release from Microsoft. ║
║ ║
║ Some insecure bootloaders were added, due to security vulnerabilities that ║
║ allowed an attacker to bypass UEFI Secure Boot. The additional entries were ║
║ from: ║
║ ║
║ • Baramanudi Management Suite ║
║ • EAZ EasyFix ║
║ • Finland Matriculation Examination Board ║
║ • NTC IT ROSA Linux ║
║ • PC-Doctor ║
║ • Spyrus WTGCreator ║
║ • WhiteCanyon blancco ║
║ • Some ancient shim releases for OpenSUSE, Oracle and Red Hat ║
║ ║
╚══════════════════════════════════════════════════════════════════════════════╝
y
Waiting… \[\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\]
Successfully installed firmware
Devices with the latest available firmware version:
• UEFI CA
• Unifying Receiver
Devices with no available firmware updates:
• Internal SPI Controller (BIOS)
• KEK CA
• Option ROM UEFI CA
• ST2000DM001-1ER164
• System Firmware
• WD20EZBX-00AYRA0
• Windows Production PCA
An update requires a reboot to complete. Restart now? \[y|N\]:
(after reboot)
$ mokutil --kek | grep ‘Subject:’
Subject: C=US, ST=Washington, L=Redmond, O=Microsoft Corporation, CN=Microsoft Corporation KEK CA 2011
I wouldn’t sweat it, give it time. It might still be a phased rollout.
That’s because the manual update wasn’t for the KEK:
Please put all log and other console/terminal output in pre-formatted code blocks (open a new line and click the </> icon in the editor first, then paste into the new element), ideally wrapped in a “Hide Details” element, if it’s more than just a few lines. See items 4 and 5 in the Posting Guide.
If you are so inclined, I took it upon myself to provide a little helper script for that. 
See how readability improves; I’ve edited what I quoted from your post for demonstration.
KEK updates must be signed by the PK and PK is (normally) owned by the vendor of your hardware platform. Your vendor needs to provide update to KEK signed by the PK installed in your system. Depending on the age of your system, vendor may not do it.
dbx updates are “easier”, because they need to be signed by “only” KEK, so as long as your system has Microsoft KEK it can deploy those updates. At least as long as Microsoft still signs them by the old KEK 2011.
Actually, I would expect that if your system is currently supported there should be BIOS update with new certificates. And if your system is out of support it is highly unlikely that vendor will provide updates for new KEK.
It should still be possible to install new KEK by temporary disabling Secure Boot and using any update payload from the Microsoft Secure Boot objects repository. Even with Secure Boot disabled the update must be properly formatted and signed, but the valid signer is not enforced. Payload on this site is prepared for appending, not replacing, so it is fairly harmless (as long as you trust this site at all 
)
P.S. sorry, I misremembered. One must be in Setup Mode for that and the only way to enter Setup Mode is clearing the PK. Restoring it back is rather complicated.
It went out of support in 2016 so nothing is coming from there. Is there any real risk in continuing with the old KEK? Would problems affect only Microsoft products (I have a Windows partition, but only use it once or twice a year)?
Conceivably when the 2011 KEK expires Microsoft will stop using it to sign dbx updates and you won’t be able to install them. dbx includes mostly non-Microsoft binaries. It is up to you to evaluate the risk.
You also will not be able to install db updates, but you probably retire your system before it happened (unless new certificates become compromised).
Unfortunately I was wrong and disabling Secure Boot is not enough to install KEK update. One must delete PK (and restore it later) which is much more intrusive and complicated.
I don’t understand DBX or DB but is seems DBX only impacts programmers. If the currency of DB impacts all database related systems, then that could be a problem for sure. It may be time to retire my old box. Even apart from the cost, I dread the process of migration.
dbx contains the list of fingerprints for the binaries that were found compromised and firmware will refuse to execute these binaries even if they have a valid signature. The db contains the list of trusted keys - unless a binary is signed by one of those keys firmware will refuse to execute it. db is white list and dbx is black list.
It’s all in that LWN article. Once new binaries arrive, signed only be the new trust chain, your UEFI won’t be able to validate their signatures, so you’d have to disable Secure Boot then. But I still don’t think it will come to that.
The output of
sudo mokutil --db
lists some ¨fingerprints” with references to the UEFI CA 2023 and some without. Of those without, 1 will expire in a few months, another has already expired.
To me this implies that the outdated KEK CA 2011 is already impeding updates to DB
Now the secure boot is turned off and it looks like leaving it off is the price for having such an old machine without vendor support.
Please share that output. There might some nuance that’s not immediately clear to the uninitiated.
No, the key hasn’t expired yet, so that doesn’t compute.
You shouldn’t disable it when nothing is broken. If it were, your machine would refuse to boot. Might as well wait until that happens, if at all. In principle, it should be possible to get an up-to-date KEK enrolled. Might not be straight forward or easy, but it must be possible. If all else fails, generate your own PK key pair enroll the public key, sign the KEK with the private key and enroll it. While you’re at it also sign Canonical’s CA key, for the EFI shim.
If all that fails, nothing is really lost, since the alternative already is to disable SB for good. Might as well try.
It may be true for future updates. You have the current 2023 Microsoft certificates and this should be good for the next dozen of years unless these certificates are compromised.
You imply that Microsoft will replace the 2023 certificates in the near future? The OP already has the current certificates used to verify the binaries. Please, do not add to confusion.
The 2011 KEK is the one expiring soon and you were the one pointing out that it is signed by the PK owner (OEM of OP’s EOL device). Anything signed by its successor can’t be validated without same.
I’m wondering if one can cannibalize UEFI updates for newer devices from the same vendor, extract the KEK and enroll manually. But, as I’m saying that, I don’t see why fwupd wouldn’t be able to do the equivalent; PK owner ID triggers update of latest KEK signed by it, no matter the age of the target device. Isn’t that the whole point of LVFS?
ok, here is the full output with just the modulus and signature values removed (else it goes on for even more pages):
$ sudo mokutil --db
[key 1]
SHA1 Fingerprint: 58:0a:6f:4c:c4:e4:b6:69:b9:eb:dc:1b:2b:3e:08:7b:80:d0:67:8d
Certificate:
Data:
Version: 3 (0x2)
Serial Number:
61:07:76:56:00:00:00:00:00:08
Signature Algorithm: sha256WithRSAEncryption
Issuer: C=US, ST=Washington, L=Redmond, O=Microsoft Corporation, CN=Microsoft Root Certificate Authority 2010
Validity
Not Before: Oct 19 18:41:42 2011 GMT
Not After : Oct 19 18:51:42 2026 GMT
Subject: C=US, ST=Washington, L=Redmond, O=Microsoft Corporation, CN=Microsoft Windows Production PCA 2011
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
Public-Key: (2048 bit)
Modulus:
value removed
Exponent: 65537 (0x10001)
X509v3 extensions:
1.3.6.1.4.1.311.21.1:
…
X509v3 Subject Key Identifier:
A9:29:02:39:8E:16:C4:97:78:CD:90:F9:9E:4F:9A:E1:7C:55:AF:53
1.3.6.1.4.1.311.20.2:
.
.S.u.b.C.A
X509v3 Key Usage:
Digital Signature, Certificate Sign, CRL Sign
X509v3 Basic Constraints: critical
CA:TRUE
X509v3 Authority Key Identifier:
D5:F6:56:CB:8F:E8:A2:5C:62:68:D1:3D:94:90:5B:D7:CE:9A:18:C4
X509v3 CRL Distribution Points:
Full Name:
URI:http://crl.microsoft.com/pki/crl/products/MicRooCerAut_2010-06-23.crl
Authority Information Access:
CA Issuers - URI:http://www.microsoft.com/pki/certs/MicRooCerAut_2010-06-23.crt
Signature Algorithm: sha256WithRSAEncryption
Signature Value:
value removed
[key 2]
SHA1 Fingerprint: 46:de:f6:3b:5c:e6:1c:f8:ba:0d:e2:e6:63:9c:10:19:d0:ed:14:f3
Certificate:
Data:
Version: 3 (0x2)
Serial Number:
61:08:d3:c4:00:00:00:00:00:04
Signature Algorithm: sha256WithRSAEncryption
Issuer: C=US, ST=Washington, L=Redmond, O=Microsoft Corporation, CN=Microsoft Corporation Third Party Marketplace Root
Validity
Not Before: Jun 27 21:22:45 2011 GMT
Not After : Jun 27 21:32:45 2026 GMT
Subject: C=US, ST=Washington, L=Redmond, O=Microsoft Corporation, CN=Microsoft Corporation UEFI CA 2011
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
Public-Key: (2048 bit)
Modulus:
value removed
Exponent: 65537 (0x10001)
X509v3 extensions:
1.3.6.1.4.1.311.21.1:
…
1.3.6.1.4.1.311.21.2:
…k..wSJ.%7.N.&{. p.
X509v3 Subject Key Identifier:
13:AD:BF:43:09:BD:82:70:9C:8C:D5:4F:31:6E:D5:22:98:8A:1B:D4
1.3.6.1.4.1.311.20.2:
.
.S.u.b.C.A
X509v3 Key Usage:
Digital Signature, Certificate Sign, CRL Sign
X509v3 Basic Constraints: critical
CA:TRUE
X509v3 Authority Key Identifier:
45:66:52:43:E1:7E:58:11:BF:D6:4E:9E:23:55:08:3B:3A:22:6A:A8
X509v3 CRL Distribution Points:
Full Name:
URI:http://crl.microsoft.com/pki/crl/products/MicCorThiParMarRoo_2010-10-05.crl
Authority Information Access:
CA Issuers - URI:http://www.microsoft.com/pki/certs/MicCorThiParMarRoo_2010-10-05.crt
Signature Algorithm: sha256WithRSAEncryption
Signature Value:
value removed
[key 3]
SHA1 Fingerprint: b5:ee:b4:a6:70:60:48:07:3f:0e:d2:96:e7:f5:80:a7:90:b5:9e:aa
Certificate:
Data:
Version: 3 (0x2)
Serial Number:
33:00:00:00:16:36:bf:36:89:9f:15:75:cc:00:00:00:00:00:16
Signature Algorithm: sha256WithRSAEncryption
Issuer: C=US, O=Microsoft Corporation, CN=Microsoft RSA Devices Root CA 2021
Validity
Not Before: Jun 13 19:21:47 2023 GMT
Not After : Jun 13 19:31:47 2038 GMT
Subject: C=US, O=Microsoft Corporation, CN=Microsoft UEFI CA 2023
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
Public-Key: (2048 bit)
Modulus:
value removed
Exponent: 65537 (0x10001)
X509v3 extensions:
X509v3 Key Usage: critical
Digital Signature, Certificate Sign, CRL Sign
1.3.6.1.4.1.311.21.1:
…
X509v3 Subject Key Identifier:
81:AA:6B:32:44:C9:35:BC:E0:D6:62:8A:F3:98:27:42:1E:32:49:7D
1.3.6.1.4.1.311.20.2:
.
.S.u.b.C.A
X509v3 Basic Constraints: critical
CA:TRUE
X509v3 Authority Key Identifier:
84:44:86:06:00:98:3F:2C:AA:B3:C5:89:F3:AC:2E:C9:E6:9D:09:03
X509v3 CRL Distribution Points:
Full Name:
URI:http://www.microsoft.com/pkiops/crl/Microsoft%20RSA%20Devices%20Root%20CA%202021.crl
Authority Information Access:
CA Issuers - URI:http://www.microsoft.com/pkiops/certs/Microsoft%20RSA%20Devices%20Root%20CA%202021.crt
Signature Algorithm: sha256WithRSAEncryption
Signature Value:
value removed
[key 4]
SHA1 Fingerprint: 3f:b3:9e:2b:8b:d1:83:bf:9e:45:94:e7:21:83:ca:60:af:cd:42:77
Certificate:
Data:
Version: 3 (0x2)
Serial Number:
33:00:00:00:17:b3:ec:4d:8f:01:e2:70:05:00:00:00:00:00:17
Signature Algorithm: sha256WithRSAEncryption
Issuer: C=US, O=Microsoft Corporation, CN=Microsoft RSA Devices Root CA 2021
Validity
Not Before: Oct 26 19:02:20 2023 GMT
Not After : Oct 26 19:12:20 2038 GMT
Subject: C=US, O=Microsoft Corporation, CN=Microsoft Option ROM UEFI CA 2023
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
Public-Key: (2048 bit)
Modulus:
value removed
Exponent: 65537 (0x10001)
X509v3 extensions:
X509v3 Key Usage: critical
Digital Signature, Certificate Sign, CRL Sign
1.3.6.1.4.1.311.21.1:
…
X509v3 Subject Key Identifier:
51:4F:BF:93:7F:A4:6F:B5:7B:F0:7A:F8:BE:D8:4B:3B:86:4B:17:11
1.3.6.1.4.1.311.20.2:
.
.S.u.b.C.A
X509v3 Basic Constraints: critical
CA:TRUE
X509v3 Authority Key Identifier:
84:44:86:06:00:98:3F:2C:AA:B3:C5:89:F3:AC:2E:C9:E6:9D:09:03
X509v3 CRL Distribution Points:
Full Name:
URI:http://www.microsoft.com/pkiops/crl/Microsoft%20RSA%20Devices%20Root%20CA%202021.crl
Authority Information Access:
CA Issuers - URI:http://www.microsoft.com/pkiops/certs/Microsoft%20RSA%20Devices%20Root%20CA%202021.crt
Signature Algorithm: sha256WithRSAEncryption
Signature Value:
value removed
No, the key hasn’t expired yet, so that doesn’t compute.
I understood that key to be invalid as of June 27 2026. I also understood that key to be the validating entity letting DB know that it can make changes. I don’t pretend to understand why some DB entries reflect the new Microsoft certs and others don’t. It is little more than a guess that somehow the invalid KEK key is responsible.
I seriously doubt Dell would send me an updated key for an ancient machine they stopped supporting in 2016. As to forging certs myself - that is WAY over my head. I have spent about 8 hours of just trying to understand this as dimly as I do. It is extremely arcane to me. I am not a computer professional in any way, just a user with only as much understanding of the system as is strictly necessary for normal use. If the system would not boot, I would have no idea how to proceed or amend it. If recovering from a non-booting system is very simple (I mean normal person simple), I would be willing to risk it and use SecureBoot.
This topic was automatically closed after 30 days. New replies are no longer allowed.