Windows 10: Event ID 1801, Secure Boot CA/keys need to be updated

​

In this post, we are going to see what you can do to resolve Event ID 1801, Secure Boot CA/keys need to be updated. Event ID 1801 is a warning logged by Windows to indicate that the Secure Boot Forbidden Signature Database (DBX) or its underlying certificates (CA/keys) are out of date. Secure Boot is a […]

This article Event ID 1801, Secure Boot CA/keys need to be updated first appeared on TheWindowsClub.com.

read more...

 

Updating Microsoft Secure Boot keys

Windows IT Pro Blog: Microsoft, in collaboration with our ecosystem partners, is preparing to roll out replacement certificates thatll set new Unified Extensible Firmware Interface (UEFI) Certificate Authorities (CAs) trust anchors in Secure Boot for the future. Look out for Secure Boot database updates rolling out in phases to add trust for the new database (DB) and Key Exchange Key (KEK) certificates. This new DB update is available as an optional servicing update for all Secure Boot enabled devices from February 13, 2024. What is Secure Boot? Secure Boot is a security feature in the UEFI that helps ensure that only trusted software runs during the systems boot sequence. It works by verifying the digital signature of any software against a set of trusted digital keys stored in the UEFI. As an industry standard, UEFIs Secure Boot defines how platform firmware manages certificates, authenticates firmware, and how the operating system (OS) interfaces with this process. For more details on UEFI and Secure Boot, please refer to this article. Secure Boot was first introduced to Windows systems with the Windows 8 release to protect against the emerging pre-boot malware (bootkit) threat at that time. Since then, Secure Boot has continued to be a part of Microsoft's Trusted Boot security architecture. Secure Boot authenticates modules such as UEFI firmware drivers, bootloaders, applications, and option ROMs (Read-Only Memory), which are firmware run by the PC BIOS during platform initialization, before they are all executed. As the final step of the Secure Boot process, the firmware verifies the Windows boot loader is trusted by Secure Boot and then passes control to the boot loader which in turn verifies, loads into memory, and launches Windows. This process coupled with the UEFI firmware signing process helps to ensure that only verified code executes before Windows, preventing attackers from utilizing the boot path as an attack vector. To learn more about how Secure Boot fits in with the overall Windows chip-t-cloud security, please refer to the Windows Security Book RWMyFE. Trust and authenticity in Secure Boot are built using the Public-Key Infrastructure (PKI). This establishes a certificate management system which utilizes CAs to store digital certificates. These CAs, consisting of Original Equipment Manufacturer (OEM) or their delegates and Microsoft, generate key pairs that form the root of trust of a system.

Secure Boot “root of trust”: Setting trust anchors for the future Secure Boots root of trust utilizes a hierarchical system, where the Platform Key (PK) is typically managed by the OEM and used to sign updates to the KEK database. The KEK in turn signs updates to both the Allowed Signature DB and the Forbidden Signature Database (DBX). The Secure Boot Allowed Signature DB and the DBX are integral to the functionality of Secure Boot. Bootloader modules signing authority must be allowlisted by the Secure Boot DB, while the DBX is used for revoking previously trusted boot components. Updates to the DB and DBX must be signed by a KEK in the Secure Boot KEK database. The configuration of Secure Boot DB and KEK for Windows devices has remained the same since Windows 8. Microsoft requires every OEM to include the same three certificates managed by Microsoft for Windows and in support of the third-party hardware and OS ecosystem. These include the Microsoft Corporation KEK CA 2011 stored in the KEK database, and two certificates stored in the DB called the Microsoft Windows Production PCA 2011, which signs the Windows bootloader, and the Microsoft UEFI CA 2011 (or third-party UEFI CA), which signs third-party OS and hardware driver components. All three of these Microsoft certificates expire in 2026. So, in collaboration with our ecosystem partners, Microsoft is preparing to roll out replacement certificates that will set new UEFI CA trust anchors for the future. Microsoft will be rolling out Secure Boot database updates in phases to add trust for the new DB and KEK certificates. The first DB update will add the Microsoft Windows UEFI CA 2023 to the system DB. The new Microsoft Windows UEFI CA 2023 will be used to sign Windows boot components prior to the expiration of the Windows Production CA 2011. This DB update will be optional for the February 2024 servicing and preview updates, and can be manually applied to devices. Microsoft will slowly roll out this DB update as we validate devices and firmware compatibility globally. The full DB updates controlled-rollout process to all Windows customers will begin during the 2024 April servicing and preview updates, ahead of the certificate expiration in 2026. Meanwhile, efforts to update the Microsoft UEFI CA 2011 (aka third-party UEFI CA) and Microsoft Corporation KEK CA 2011 will begin late 2024, and will follow a similar controlled rollout process as this DB update. While Microsoft has frequently performed DBX updates globally since the inception of Secure Boot, this will be the first DB update performed on such a large scale. Were actively collaborating with our OEM partners to identify and address bugs in firmware implementation that could result in unbootable systems or render a device unreceptive to the DB update. To ensure a successful rollout, devices with identified issues will be suspended from receiving the update until a fix is released. Microsoft is taking a very deliberate and cautious approach to rolling out this update. With this DB update, Microsoft will sustain its ability to service all Windows devices boot components. Guidance to manually apply DB update The DB update is available on February 13, 2024, along with manual steps to allow customers to test for firmware compatibility, especially for organizations with fleets of devices. If you would like to manually apply the DB update to validate that your system is compatible, please read the following instructions. These actions should be completed with non-critical hardware representing devices in your environment. Pre-requisite checks Before attempting the DB update, please ensure to perform the necessary pre-requisite checks:

1. If you intend to manually apply this update to a large group of devices, we advise that you begin by rolling out to individual devices with the same firmware and specifications first to minimize the risks in the case of firmware bugs in your devices.
2. Please verify that your UEFI firmware version is the most recent available version by your firmware vendor or OEM.
3. For data backup steps, please refer to this guide.
4. If you use BitLocker or if your enterprise has deployed BitLocker on your machine, ensure to backup BitLocker Keys:
   1. 1. See this portal to ensure your BitLocker keys are backed up before your next reboot for your selfhost device. In the unlikely event that device becomes inoperable after receiving the update, the hard drive can still be unlocked.
      2. If the keys are backed up, the UI should resemble the following:
         
         
   1. If the keys are not backed up, please open Windows Search to search for “Manage BitLocker” and select Back up your recovery key followed by Save to your Azure AD or MSA account.
   
   
   
   
   
   

For users that use a local account instead of an Azure Active Directory (AAD) or Microsoft account (MSA), you can print your recovery password, save to a file, and store it in a secure location. Formal DB update steps

1. Apply the February 2024 (or later) security update.
2. Open a PowerShell console and ensure that PowerShell is running as an administrator before running the following commands:
   1. Set the registry key to Set-ItemProperty -Path “HKLM:\SYSTEM\CurrentControlSet\Control\SecureBoot” -Name “AvailableUpdates” -Value 0x40
   2. Run the following scheduled task as Start-ScheduledTask -TaskName “\Microsoft\Windows\PI\Secure-Boot-Update”
3. Reboot the machine twice after running these commands to confirm that the machine is booting with the updated DB.
4. To verify that the Secure Boot DB update was successful, open a PowerShell console and ensure that PowerShell is running as an administrator before running the following command: [System.Text.Encoding]::ASCII.GetString((Get-SecureBootUEFI db).bytes) -match ‘Windows UEFI CA 2023’
   
   

If the command returns True, the update was successful. In the case of errors while applying the DB update, please refer to the article, KB5016061: Addressing vulnerable and revoked Boot Managers. Source: https://techcommunity.microsoft.com/...s/ba-p/4055324

 

Windows 8 Secure Boot Feature: Not So Secure?

So Linux is switching to secure boot also? Or they have to because of UEFI?

 

Event ID 5061 Audit Failure after April Update.

This is what I got by doing it

Serial Number: d49c11c6a8d97643a55b5eddd9a4e94a
Issuer: CN=XBL Client IPsec Issuing CA
NotBefore: 1/2/2018 10:20 AM
NotAfter: 1/3/2018 10:20 AM
Subject: CN=F9007479FC031D7A
Non-root Certificate
Cert Hash(sha1): cb1e5291b2e04c32b8651684f5f9fd4de010c775
Key Container = 11F88326-2132-4D64-9956-EB77B5003DC6
Unique container name: 2b1270ead2983daf54828e3f6773802a_bfd23135-ab1a-4702-9757-7ea9f71be682
Provider = Microsoft Software Key Storage Provider
Private key is NOT exportable
Encryption test passed
CertUtil: -store command completed successfully.



Should I reset the app then?