Skip to content

Commit b18bf30

Browse files
andrewlukoshkoandrewlukoshko
committed
Add UEFI Secure Boot 2023 certificate transition guide
Documents the Microsoft 2011 -> 2023 Secure Boot CA transition: current AlmaLinux shim signing status, verification steps, the recommended fwupd update path, manual efivar enrollment, and guidance for KVM, VMware, Azure, GCP and AWS virtual machines. Adds the page to the Documentation navbar menu.
1 parent e54a68c commit b18bf30

2 files changed

Lines changed: 163 additions & 0 deletions

File tree

‎docs/.vuepress/config.js‎

Lines changed: 4 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -181,6 +181,10 @@ module.exports = {
181181
children: [
182182
"/Comparison",
183183
"/documentation/nvidia",
184+
{
185+
title: "Secure Boot: 2023 Certificates",
186+
path: "/documentation/secure-boot-2023-certificates",
187+
},
184188
"/FAQ",
185189
{
186190
title: "openQA Guide",

‎docs/documentation/secure-boot-2023-certificates.md‎

Lines changed: 159 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,159 @@
1+
---
2+
title: "UEFI Secure Boot: Microsoft 2023 Certificate Transition"
3+
---
4+
5+
# UEFI Secure Boot: Microsoft 2023 Certificate Transition
6+
7+
This page explains the June 2026 expiration of the Microsoft 2011 UEFI Secure Boot certificates, what AlmaLinux has already done about it, and what (if anything) you need to do on your systems.
8+
9+
## TL;DR
10+
11+
- **Your existing AlmaLinux systems will not stop booting.** UEFI Secure Boot does not check certificate expiration dates at boot time. Everything that boots today keeps booting after June 2026.
12+
- **The latest shim in AlmaLinux 9 and 10 for x86_64 is dual-signed** with both the Microsoft 2011 and 2023 certificates, so it boots on systems that have either (or both) certificate enrolled. **No action is required right now.**
13+
- To stay compatible with _future_ Secure Boot components and revocation (dbx) updates, you should enroll the Microsoft 2023 certificates on systems that don't have them yet. The recommended way to do this on AlmaLinux is **fwupd**: `fwupdmgr refresh && fwupdmgr update`.
14+
15+
## Background: what is expiring and why it matters
16+
17+
UEFI Secure Boot on most hardware is anchored to certificates operated by Microsoft. Three of them, issued in 2011, expire in 2026:
18+
19+
| Certificate | Expires | Role |
20+
| ------------------------------------- | ------------- | --------------------------------------------------------------- |
21+
| Microsoft Corporation KEK CA 2011 | June 24, 2026 | Authorizes updates to the Secure Boot databases (db/dbx) |
22+
| Microsoft Corporation UEFI CA 2011 | June 27, 2026 | Signs third-party boot components, including the Linux **shim** |
23+
| Microsoft Windows Production PCA 2011 | October 2026 | Signs Windows boot components (not used by Linux) |
24+
25+
Their replacements are **Microsoft Corporation KEK 2K CA 2023**, **Microsoft UEFI CA 2023**, and **Microsoft Option ROM UEFI CA 2023** (in the 2023 hierarchy, the third-party CA was split into a separate option ROM CA).
26+
27+
The expiration does **not** invalidate already-signed binaries — firmware does not check signature expiry at boot. What changes is that Microsoft can no longer _sign new artifacts_ with the 2011 CAs after they expire. The practical consequences:
28+
29+
- Future shim builds, option ROM firmware, and other third-party EFI binaries will be signed only by the 2023 CAs. Systems whose firmware `db` does not contain the 2023 certificates will refuse to boot them under Secure Boot.
30+
- Future revocation (dbx) and db updates are signed by the KEK. Systems without the 2023 KEK may be unable to receive future security revocations.
31+
32+
See the upstream guidance for distro maintainers in [rhboot/shim-review#547](https://github.com/rhboot/shim-review/issues/547) and Red Hat's article [Secure Boot certificate changes in 2026: Guidance for RHEL environments](https://access.redhat.com/articles/7128933) ([developers.redhat.com version](https://developers.redhat.com/articles/2026/02/04/secure-boot-certificate-changes-2026-guidance-rhel-environments)). AlmaLinux follows the same approach as RHEL.
33+
34+
## Current AlmaLinux status
35+
36+
| Release | Latest shim | x86_64 signature | aarch64 signature |
37+
| ------------ | -------------------------- | ------------------------------- | ----------------- |
38+
| AlmaLinux 10 | `shim-16.1-4.el10.alma.1` | 2011 **and** 2023 (dual-signed) | 2023 only |
39+
| AlmaLinux 9 | `shim-16.1-7.el9.alma.1` | 2011 **and** 2023 (dual-signed) | 2023 only |
40+
| AlmaLinux 8 | `shim-15.8-4.el8_9.alma.2` | 2011 only | 2011 only |
41+
42+
- **AlmaLinux 9 and 10, x86_64:** the current shim carries both signatures, so it boots regardless of whether your firmware trusts the 2011 CA, the 2023 CA, or both. **No immediate action is required.**
43+
- **AlmaLinux 9 and 10, aarch64:** the current shim is signed with the **Microsoft UEFI CA 2023 only** (the same is true for RHEL). If your aarch64 system boots with Secure Boot enabled today, its firmware already trusts the 2023 CA — **no action is required.** You may still want to verify the KEK (Step 1) to keep receiving future Secure Boot database updates.
44+
- **AlmaLinux 8:** the current shim is signed with the 2011 CA only. An updated shim is planned following RHEL 8 (expected June 2026). Note that the fwupd version in AlmaLinux 8 (1.7.8) is too old to deliver the certificate updates described below; AlmaLinux 8 users should rely on vendor firmware updates or the manual method.
45+
46+
You can check which certificates your shim is signed with:
47+
48+
```bash
49+
sudo dnf -y install pesign
50+
pesign -S -i /boot/efi/EFI/almalinux/shimx64.efi
51+
```
52+
53+
A dual-signed shim shows two signatures, one issued by `Microsoft Corporation UEFI CA 2011` and one by `Microsoft UEFI CA 2023`.
54+
55+
## Step 1: Check whether your system already trusts the 2023 CAs
56+
57+
First confirm Secure Boot is enabled (if it is disabled, none of this affects you):
58+
59+
```bash
60+
$ mokutil --sb-state
61+
SecureBoot enabled
62+
```
63+
64+
Check the signature database (`db`) for the 2023 third-party CA:
65+
66+
```bash
67+
$ mokutil --db | grep 'UEFI CA 2023'
68+
Subject: C=US, O=Microsoft Corporation, CN=Microsoft UEFI CA 2023
69+
```
70+
71+
Check the KEK:
72+
73+
```bash
74+
$ mokutil --kek | grep 'KEK 2K CA 2023'
75+
Subject: C=US, O=Microsoft Corporation, CN=Microsoft Corporation KEK 2K CA 2023
76+
```
77+
78+
If both commands print a match, your system is already up to date and you are done. If they print nothing, continue below.
79+
80+
Many recent machines already received the 2023 certificates through a firmware (BIOS/UEFI) update from the hardware vendor, so check for vendor firmware updates first — that is the cleanest path.
81+
82+
## Step 2 (recommended): Enroll the 2023 certificates with fwupd
83+
84+
Like RHEL, AlmaLinux recommends **fwupd** for Secure Boot variable updates. fwupd delivers Microsoft's signed db/KEK update payloads through the [Linux Vendor Firmware Service (LVFS)](https://fwupd.org/), and contains quirk handling for firmware implementations that need special treatment.
85+
86+
Support for UEFI db and KEK updates was added in fwupd **2.0.8**. AlmaLinux 9 and 10 ship fwupd **2.0.19** in BaseOS, so the stock package is sufficient:
87+
88+
```bash
89+
sudo dnf install -y fwupd
90+
fwupd --version
91+
```
92+
93+
Refresh metadata and apply available updates:
94+
95+
```bash
96+
sudo fwupdmgr refresh
97+
sudo fwupdmgr update
98+
sudo reboot
99+
```
100+
101+
If updates are available for your system, `fwupdmgr update` will list devices such as _UEFI db_ and _KEK_ with pending _Secure Boot_ certificate updates and prompt for confirmation. The new certificates only become visible after a reboot.
102+
103+
> **Note:** older fwupd versions (before 2.0.8) do not attempt db/KEK updates at all and may appear to "succeed" while doing nothing. Always verify the result (Step 3) instead of trusting the tool output alone.
104+
105+
## Step 3: Verify after reboot
106+
107+
```bash
108+
mokutil --db | grep 'UEFI CA 2023'
109+
mokutil --kek | grep 'KEK 2K CA 2023'
110+
```
111+
112+
Both should now print the corresponding `Subject:` lines shown in Step 1. If the `db` entry is present but the KEK update did not apply, see the caveats below — the db update is the time-critical part for being able to boot future 2023-signed components; the KEK matters for receiving future db/dbx updates.
113+
114+
## Alternative: manual enrollment without fwupd
115+
116+
For air-gapped systems, or if fwupd does not offer the update on your platform, Microsoft publishes the signed authenticated-variable update payloads in the [microsoft/secureboot_objects](https://github.com/microsoft/secureboot_objects) repository. The db update can be appended with `efivar` (available in the standard AlmaLinux repositories):
117+
118+
```bash
119+
sudo dnf install -y efivar
120+
curl -LO https://raw.githubusercontent.com/microsoft/secureboot_objects/main/PostSignedObjects/Optional/DB/amd64/DBUpdate3P2023.bin
121+
122+
# 103 = 0x67: NV + BS + RT + TIME_BASED_AUTH + APPEND_WRITE
123+
sudo efivar \
124+
--name d719b2cb-3d3a-4596-a3bc-dad00e67656f-db \
125+
--append \
126+
--attributes 103 \
127+
-f DBUpdate3P2023.bin
128+
```
129+
130+
> **Note:** the attribute value is given in decimal (`103`) because the efivar versions in AlmaLinux 8 and 9 (37 and 38) do not accept hexadecimal input and would silently parse `0x67` as `0`. The short `-f` option is used because efivar 37 (AlmaLinux 8) names the long option `--fromfile` while 38/39 name it `--datafile`.
131+
132+
Then reboot and verify as in Step 3. The matching KEK update (`PostSignedObjects/KEK/Microsoft/KEKUpdate_Microsoft_PK1.bin`) can be applied the same way to the `KEK` variable (`8be4df61-93ca-11d2-aa0d-00e098032b8c-KEK`), but note that a KEK update must be signed by the Platform Key (PK) chain enrolled on your machine — on platforms whose PK is not Microsoft's, this particular payload will not apply (check `mokutil --pk`, and see [shim-review#547](https://github.com/rhboot/shim-review/issues/547) for assembling the right KEK update for other PK vendors).
133+
134+
## Virtual machines
135+
136+
**KVM/QEMU (libvirt) guests:** the Secure Boot certificates of a VM come from the OVMF firmware variable template on the _host_. Update the `edk2-ovmf` package on the hypervisor — current builds include both the 2011 and 2023 Microsoft certificates. New VMs created afterwards get the new certificate set automatically. Existing VMs keep their old NVRAM; either apply the update inside the guest exactly as on physical machines (fwupd), or recreate the guest NVRAM from the new template (`virsh start <vm> --reset-nvram`, libvirt 8.1.0+ — note this also resets boot order and any MOK enrollments).
137+
138+
**VMware vSphere:** the certificates of a VM come from its virtual EFI firmware and are stored in the VM's NVRAM. On **ESXi 9.x** and **ESXi 8.0 U3j (P09)** or later, VMs with hardware version 14+ are initialized with the 2023 certificates automatically. VMs on older ESXi builds carry only the 2011 certificates; Broadcom recommends updating in-guest using the OS vendor's method — i.e. fwupd as described above. Note that the KEK update can fail on VMs created before ESXi 8.0 U3j because the expected Platform Key is missing from the VM's variable store; the db update is the part that matters for booting future AlmaLinux components. See Broadcom KB [Secure Boot Certificate Expirations and Update Failures in VMware Virtual Machines](https://knowledge.broadcom.com/external/article/423893/secure-boot-certificate-expirations-and.html).
139+
140+
**Azure (Trusted Launch VMs):** the same in-guest fwupd procedure applies and is the recommended method. The manual method above also works; the `DBUpdate3P2023.bin` payload is the relevant one. The Microsoft KEK update may not apply on some Azure platform configurations — the db update is sufficient to keep booting future 2023-signed AlmaLinux components. Verify with `mokutil` after reboot as usual.
141+
142+
**Google Cloud (Shielded VM):** instances created on or after **November 7, 2025** already include the 2023 certificates. For older instances, Google recommends the same in-guest update; their [update guide](https://docs.cloud.google.com/compute/docs/security/ms-secure-boot-certificates-update) uses fwupd (2.0.10 or later — the fwupd shipped in AlmaLinux 9 and 10 qualifies) or the manual payloads from `microsoft/secureboot_objects`. See also Google's [expiration overview](https://docs.cloud.google.com/compute/docs/security/ms-secure-boot-certificates-expiration).
143+
144+
**AWS (EC2):** Secure Boot on EC2 is opt-in: it is only active on instances launched from an AMI registered with UEFI boot mode and a UEFI variable store (`UefiData`) containing Secure Boot keys — there is no platform-wide certificate rollout. On instances where Secure Boot is enabled with the Microsoft 2011 certificates, apply the same in-guest update (fwupd or the manual method above) and verify with `mokutil`. When building your own Secure Boot-enabled AMIs, include the 2023 certificates in the variable store at registration time. See [UEFI Secure Boot for Amazon EC2 instances](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/uefi-secure-boot.html).
145+
146+
## Caveats and warnings
147+
148+
- **TPM-bound disk encryption (PCR 7):** updating PK/KEK/db/dbx changes the TPM PCR 7 measurement. If you use TPM auto-unlock for LUKS bound to PCR 7 (`systemd-cryptenroll`, `clevis`), re-enroll/reseal the binding after the update, and make sure you have your LUKS passphrase available before rebooting.
149+
- **Vendor firmware quirks:** some platforms (HP and Fujitsu are known examples) block standalone db updates from the OS. Do not force the update if it fails — check for a vendor firmware (BIOS/UEFI) update instead, which typically delivers the 2023 certificates itself.
150+
- **Do not remove or revoke the 2011 CA.** Existing artifacts and option ROMs depend on it, and on most firmware a dbx revocation of the 2011 CA would also block dual-signed binaries. The 2011 CA is expected to remain trusted for the foreseeable future.
151+
152+
## References
153+
154+
- [Guidance for the Microsoft 2023 Secure Boot CA Transition (rhboot/shim-review#547)](https://github.com/rhboot/shim-review/issues/547)
155+
- [Red Hat: Secure Boot certificate changes in 2026 — Guidance for RHEL environments](https://access.redhat.com/articles/7128933)
156+
- [Red Hat Developer article version](https://developers.redhat.com/articles/2026/02/04/secure-boot-certificate-changes-2026-guidance-rhel-environments)
157+
- [Microsoft: Windows Secure Boot certificate expiration and CA updates](https://support.microsoft.com/en-us/topic/windows-secure-boot-certificate-expiration-and-ca-updates-7ff40d33-95dc-4c3c-8725-a9b95457578e)
158+
- [microsoft/secureboot_objects — signed update payloads](https://github.com/microsoft/secureboot_objects)
159+
- [fwupd / LVFS](https://fwupd.org/)

0 commit comments

Comments
 (0)