Skip to content

Commit f4cfd04

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 f4cfd04

2 files changed

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

0 commit comments

Comments
 (0)