Chapter 6. Configuring RHEL on AWS with Secure Boot


To enhance boot security for a Red Hat Enterprise Linux (RHEL) instance on Amazon Web Services (AWS), configure Secure Boot. Secure Boot verifies the digital signatures of the boot loader and other components at startup, allowing only trusted programs to load while blocking unauthorized ones.

6.1. Understanding secure boot for RHEL on cloud

When Secure Boot detects any tampered components or components signed by untrusted entities, it aborts the boot process. Secure Boot plays a critical role in configuring a Confidential Virtual Machine (CVM) by ensuring that only trusted entities participate in the boot chain.

Secure Boot is a Unified Extensible Firmware Interface (UEFI) feature that verifies digital signatures of boot components, such as boot loader and kernel, against trusted keys stored in hardware. Secure Boot prevents unauthorized or tampered software from running during boot, protecting your system from malicious code. It authenticates access to specific device paths through defined interfaces, enforces the use of the latest configuration, and permanently overwrites earlier configurations. When the Red Hat Enterprise Linux (RHEL) kernel boots with Secure Boot enabled, it enters the lockdown mode, allowing only kernel modules signed by a trusted vendor to load. Therefore, Secure Boot strengthens the security of the operating system boot sequence.

Components of Secure Boot

The Secure Boot mechanism consists of firmware, signature databases, cryptographic keys, boot loader, hardware modules, and the operating system. The following are the components of the UEFI trusted variables:

  • Key Exchange Key database (KEK): An exchange of public keys to establish trust between the RHEL operating system and the VM firmware. You can also update Allowed Signature database (db) and Forbidden Signature database (dbx) by using these keys.
  • Platform Key database (PK): A self-signed single-key database to establish trust between the VM firmware and the cloud platform. The PK also updates the KEK database.
  • Allowed Signature database (db): A database that maintains a list of certificates or binary hashes to check whether the binary file can boot on the system. Additionally, all certificates from db are imported to the .platform keyring of the RHEL kernel. With this feature, you can add and load signed third party kernel modules in the lockdown mode.
  • Forbidden Signature database (dbx): A database that maintains a list of certificates or binary hashes that are not allowed to boot on the system.
Note

Binary files check against the dbx database and the Secure Boot Advanced Targeting (SBAT) mechanism. With SBAT, you can revoke older versions of specific binaries by keeping the certificate that has signed binaries as valid.

Stages of Secure Boot for RHEL on Cloud

When a RHEL instance boots in the Unified Kernel Image (UKI) mode and with Secure Boot enabled, the RHEL instance interacts with the cloud service infrastructure in the following sequence:

  1. Initialization: When a RHEL instance boots, the cloud-hosted firmware initially boots and implements the Secure Boot mechanism.
  2. Variable store initialization: The firmware initializes UEFI variables from a variable store, a dedicated storage area for information that firmware needs to manage for the boot process and runtime operations. When the RHEL instance boots for the first time, the store initializes from default values associated with the VM image.
  3. Boot loader: When booted, the firmware loads the first stage boot loader. For the RHEL instance in a x86 UEFI environment, the first stage boot loader is shim. The shim boot loader authenticates and loads the next stage of the boot process and acts as a bridge between UEFI and GRUB.

    1. The shim x86 binary in RHEL is currently signed by the Microsoft Corporation UEFI CA 2011 Microsoft certificate so that the RHEL instance can boot in the Secure Boot enabled mode on various hardware and virtualized platforms where the Allowed Signature database (db) has the default Microsoft certificates.
    2. The shim binary extends the list of trusted certificates with Red Hat Secure Boot CA and optionally, with Machine Owner Key (MOK).
  4. UKI: The shim binary loads the RHEL UKI (the kernel-uki-virt package). The corresponding certificate, Red Hat Secure Boot Signing 504 on the x86_64 architecture, signs the UKI. You can find this certificate in the redhat-sb-certs package. Red Hat Secure Boot CA signs this certificate, so the check succeeds.
  5. UKI add-ons: When you use the UKI cmdline extensions, the RHEL kernel actively checks their signatures against db, MOK, and certificates shipped with shim. This process ensures that either the operating system vendor RHEL or a user has signed the extensions.

When the RHEL kernel boots in the Secure Boot mode, it enters the lockdown mode. After entering lockdown, the RHEL kernel adds the db keys to the .platform keyring and the MOK keys to the .machine keyring. During the kernel build process, the build system works with an ephemeral key, which consists of private and public keys. The build system signs standard RHEL kernel modules, such as kernel-modules-core, kernel-modules, and kernel-modules-extra. After the completion of each kernel build, the private key becomes obsolete to sign third-party modules. You can use certificates from db and MOK for this purpose.

To ensure a secure booting process for a Red Hat Enterprise Linux (RHEL) instance on Amazon Web Services (AWS), configure Secure Boot on a RHEL instance. This instance is launched from a pre-configured Amazon Machine Image (AMI) from the AWS Marketplace.

Prerequisites

  • The RHEL AMI has the uefi-preferred option enabled in boot settings:

    $ aws ec2 describe-images --image-id ami-08d2f096f70b3dd74 --region us-east-2 | grep -E '"ImageId"|"Name"|"BootMode"'
    "Name": "RHEL-9.7.0_HVM-20260303-x86_64-0-Hourly2-GP3",
    "BootMode": "uefi-preferred",
    "ImageId": "ami-08d2f096f70b3dd74",
  • You have installed the following packages on the RHEL instance:

    • awscli2
    • python3
    • openssl
    • efivar
    • keyutils
    • edk2-ovmf
    • python3-virt-firmware

      Warning

      To avoid security issues, generate and keep private keys apart from the current RHEL instance. If Secure Boot secrets are stored on the same instance on which they are used, intruders can gain access to secrets for escalating their privileges. For details on launching an AWS EC2 instance, see Get started with Amazon EC2.

Procedure

  1. Check the platform status of the RHEL Marketplace AMI instance:

    $ sudo mokutil --sb-state
    SecureBoot disabled
    Platform is in Setup Mode

    The setup mode allows updating the Secure Boot UEFI variables within the instance.

  2. Generate a custom_db.cer custom certificate:

    $ openssl req -quiet \
    -newkey rsa:3072 \
    -nodes -keyout custom_db.key \
    -new -x509 -sha256 \
    -days 3650 \
    -subj "/CN=Signature Database key/" \
    --outform DER -out custom_db.cer
  3. Generate UEFI variables file by using the virt-fw-vars utility:

    $ virt-fw-vars --enroll-redhat \
    --add-db-cert OvmfEnrollDefaultKeys custom_db.cer \
    --set-dbx /usr/share/edk2/ovmf/DBX* \
    --output-auth .

    For details, see the virt-fw-vars(1) man page on your system.

  4. Convert UEFI variables to the Extensible Firmware Interface (EFI) Signature List (ESL) format:

    $ for f in PK KEK db dbx; do tail -c +41 $f.auth > $f.esl; done
    Note

    Each GUID is an assigned value and represents an EFI parameter

    • 8be4df61-93ca-11d2-aa0d-00e098032b8c: EFI_GLOBAL_VARIABLE_GUID
    • d719b2cb-3d3a-4596-a3bc-dad00e67656f: EFI_IMAGE_SECURITY_DATABASE_GUID

    The EFI_GLOBAL_VARIABLE_GUID parameter maintains settings of the bootable devices and boot managers, while the EFI_IMAGE_SECURITY_DATABASE_GUID parameter represents the image security database for Secure Boot variables db, dbx, and storage of required keys and certificates.

  5. Transfer the database certificates to the target instance, use the efivar utility to manage UEFI environment variables.

    1. To transfer PK.esl, enter:

      $ sudo efivar -w -n 8be4df61-93ca-11d2-aa0d-00e098032b8c-PK -f PK.esl
    2. To transfer KEK.esl, enter:

      $ sudo efivar -w -n 8be4df61-93ca-11d2-aa0d-00e098032b8c-KEK -f KEK.esl
    3. To transfer db.esl, enter:

      $ sudo efivar -w -n d719b2cb-3d3a-4596-a3bc-dad00e67656f-db -f db.esl
    4. To transfer the dbx.esl UEFI revocation list file for x64 architecture, enter:

      $ sudo efivar -w -n d719b2cb-3d3a-4596-a3bc-dad00e67656f-dbx -f dbx.esl
  6. Reboot the instance from the AWS console.

Verification

  • Verify if Secure Boot is enabled:

    $ sudo mokutil --sb-state
    SecureBoot enabled
  • Use the keyctl utility to verify the kernel keyring for the custom certificate:

    $ sudo keyctl list %:.platform
    7 keys in keyring:
    741159788: ---lswrv     0     0 asymmetric: Microsoft Windows Production PCA 2011: a92902398e16c49778cd90f99e4f9ae17c55af53
    941772267: ---lswrv     0     0 asymmetric: Red Hat Secure Boot CA 8: e1c6c580aa1e21d585aad9bf20f3929e5ec1f08b
    979739129: ---lswrv     0     0 asymmetric: Red Hat Secure Boot CA 5: cc6fa5e72868ba494e939bbd680b9144769a9f8f
    303712700: ---lswrv     0     0 asymmetric: Signature Database key: 7dff9c7433d40daa6cb2cdbdb4c2b7c93f5252a4
    747313470: ---lswrv     0     0 asymmetric: Microsoft UEFI CA 2023: 81aa6b3244c935bce0d6628af39827421e32497d
    710788326: ---lswrv     0     0 asymmetric: Microsoft Corporation UEFI CA 2011: 13adbf4309bd82709c8cd54f316ed522988a1bd4
       163192: ---lswrv     0     0 asymmetric: Microsoft Corporation: Windows UEFI CA 2023: aefc5fbbbe055d8f8daa585473499417ab5a5272
    ...

To secure boot a Red Hat Enterprise Linux (RHEL) instance on Amazon Web Services (AWS), configure Secure Boot when registering a custom RHEL Amazon Machine Image (AMI). As this AMI consists of pre-stored UEFI variables, instances launched from it use the Secure Boot mechanism during the first boot.

Prerequisites

  • You have created and uploaded an AWS AMI image. For details, see Preparing and uploading AWS AMI.
  • You have installed the following packages:

    • awscli2
    • python3
    • openssl
    • efivar
    • keyutils
    • python3-virt-firmware

Procedure

  1. Generate a custom certificate custom_db.cer:

    $ openssl req -quiet \
    -newkey rsa:3072 \
    -nodes -keyout custom_db.key \
    -new -x509 -sha256 \
    -days 3650 -subj "/CN=Signature Database key/" \
    --outform DER -out custom_db.cer
  2. Use the virt-fw-vars utility to generate the aws_blob.bin binary file from keys, database certificates, and the UEFI variable store:

    $ virt-fw-vars --enroll-redhat \
    --add-db-cert OvmfEnrollDefaultKeys custom_db.cer \
    --set-dbx /usr/share/edk2/ovmf/DBX* \
    --output-aws aws_blob.bin

    The customized blob consists of:

    • PK.cer, KEK.cer, db, and dbx from the edk2-ovmf package
    • The custom_db.cer generated certificate
  3. Use the awscli2 utility to create and register the AMI from a disk snapshot with the required Secure Boot variables:

    $ aws ec2 register-image \
    --name rhel-9-secure-boot \
    --architecture x86_64 \
    --virtualization-type hvm \
    --root-device-name "/dev/sda1" \
    --block-device-mappings "{\"DeviceName\": \"/dev/sda1\",\"Ebs\": {\"SnapshotId\": \"<snap-02d4db3813ff9b98e>\"}}" \
    --ena-support --boot-mode uefi \
    --region eu-central-1 \
    --uefi-data $(cat aws_blob.bin)
    --output json
    {
        "ImageId": "example-amazon-id"
    }
  4. Reboot the instance from the AWS Console.

Verification

  • Verify Secure Boot functionality:

    $ sudo mokutil --sb-state
    SecureBoot enabled
  • Use the keyctl utility to verify the kernel keyring for the custom certificate:

    $ sudo keyctl list %:.platform
    7 keys in keyring:
    741159788: ---lswrv     0     0 asymmetric: Microsoft Windows Production PCA 2011: a92902398e16c49778cd90f99e4f9ae17c55af53
    941772267: ---lswrv     0     0 asymmetric: Red Hat Secure Boot CA 8: e1c6c580aa1e21d585aad9bf20f3929e5ec1f08b
    979739129: ---lswrv     0     0 asymmetric: Red Hat Secure Boot CA 5: cc6fa5e72868ba494e939bbd680b9144769a9f8f
    303712700: ---lswrv     0     0 asymmetric: Signature Database key: 7dff9c7433d40daa6cb2cdbdb4c2b7c93f5252a4
    747313470: ---lswrv     0     0 asymmetric: Microsoft UEFI CA 2023: 81aa6b3244c935bce0d6628af39827421e32497d
    710788326: ---lswrv     0     0 asymmetric: Microsoft Corporation UEFI CA 2011: 13adbf4309bd82709c8cd54f316ed522988a1bd4
       163192: ---lswrv     0     0 asymmetric: Microsoft Corporation: Windows UEFI CA 2023: aefc5fbbbe055d8f8daa585473499417ab5a5272
    ...
Red Hat logoGithubredditYoutubeTwitter

Learn

Try, buy, & sell

Communities

About Red Hat Documentation

We help Red Hat users innovate and achieve their goals with our products and services with content they can trust. Explore our recent updates.

Making open source more inclusive

Red Hat is committed to replacing problematic language in our code, documentation, and web properties. For more details, see the Red Hat Blog.

About Red Hat

We deliver hardened solutions that make it easier for enterprises to work across platforms and environments, from the core datacenter to the network edge.

Theme

© 2026 Red Hat
Back to top