Apply Prettier format

Author: autofix-ci[bot]

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

@@ -16,7 +16,7 @@ need to do on your systems.
 - **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.**
-- To stay compatible with *future* Secure Boot components and revocation (dbx)
+- 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`.
@@ -26,19 +26,19 @@ need to do on your systems.
 UEFI Secure Boot on most hardware is anchored to certificates operated by
 Microsoft. Three of them, issued in 2011, expire in 2026:
 
-| Certificate | Expires | Role |
-|---|---|---|
-| Microsoft Corporation KEK CA 2011 | June 24, 2026 | Authorizes updates to the Secure Boot databases (db/dbx) |
-| Microsoft Corporation UEFI CA 2011 | June 27, 2026 | Signs third-party boot components, including the Linux **shim** |
-| Microsoft Windows Production PCA 2011 | October 2026 | Signs Windows boot components (not used by Linux) |
+| Certificate                           | Expires       | Role                                                            |
+| ------------------------------------- | ------------- | --------------------------------------------------------------- |
+| Microsoft Corporation KEK CA 2011     | June 24, 2026 | Authorizes updates to the Secure Boot databases (db/dbx)        |
+| Microsoft Corporation UEFI CA 2011    | June 27, 2026 | Signs third-party boot components, including the Linux **shim** |
+| Microsoft Windows Production PCA 2011 | October 2026  | Signs Windows boot components (not used by Linux)               |
 
 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).
 
 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:
+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:
 
 - 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
@@ -55,11 +55,11 @@ AlmaLinux follows the same approach as RHEL.
 
 ## Current AlmaLinux status
 
-| Release | Latest shim | x86_64 signature | aarch64 signature |
-|---|---|---|---|
-| AlmaLinux 10 | `shim-16.1-4.el10.alma.1` | 2011 **and** 2023 (dual-signed) | 2023 only |
-| AlmaLinux 9 | `shim-16.1-7.el9.alma.1` | 2011 **and** 2023 (dual-signed) | 2023 only |
-| AlmaLinux 8 | `shim-15.8-4.el8_9.alma.2` | 2011 only | 2011 only |
+| Release      | Latest shim                | x86_64 signature                | aarch64 signature |
+| ------------ | -------------------------- | ------------------------------- | ----------------- |
+| AlmaLinux 10 | `shim-16.1-4.el10.alma.1`  | 2011 **and** 2023 (dual-signed) | 2023 only         |
+| AlmaLinux 9  | `shim-16.1-7.el9.alma.1`   | 2011 **and** 2023 (dual-signed) | 2023 only         |
+| AlmaLinux 8  | `shim-15.8-4.el8_9.alma.2` | 2011 only                       | 2011 only         |
 
 - **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
@@ -140,7 +140,7 @@ sudo reboot
 ```
 
 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
+as _UEFI db_ and _KEK_ with pending _Secure Boot_ certificate updates and prompt
 for confirmation. The new certificates only become visible after a reboot.
 
 > **Note:** older fwupd versions (before 2.0.8) do not attempt db/KEK updates at
@@ -197,7 +197,7 @@ assembling the right KEK update for other PK vendors).
 ## Virtual machines
 
 **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
+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