Chapter 6. Configuring RHEL on AWS with Secure Boot

Secure Boot is a mechanism in the Unified Extensible Firmware Interface (UEFI) specification, which controls the execution of programs at boot time. Secure Boot verifies digital signatures of the boot loader and its components at boot time, to ensure only trusted and authorized programs are executed, and also prevent unauthorized programs from loading. You can use this feature for both AWS Marketplace Red Hat Enterprise Linux Amazon Machine Images (AMI) and custom RHEL AMI.

6.1. Types of RHEL AMI on AWS
링크 복사

AWS Marketplace RHEL AMI

The AWS Marketplace provides a pre-configured Red Hat Enterprise Linux (RHEL) Amazon Machine Image (AMI) that is tailored for specified use cases such as data processing, system management, and web development. This type of ready-to-use image reduces setup by minimizing manual installation and configuration time required for operating systems and software packages.

Custom RHEL AMI

A custom RHEL AMI offers flexibility to customers and organizations to build and deploy tailored environments that meet specific application and workflow requirements. By creating custom RHEL AMI, you can use RHEL instances that are pre-installed with necessary tools, configurations, and security policies. This customization aims at greater control over the infrastructure.

6.2. Understanding secure boot for RHEL on cloud
링크 복사

Secure Boot is a feature of Unified Extensible Firmware Interface (UEFI). It ensures that only trusted and digitally signed programs and components, such as the boot loader and kernel, run during boot time. Secure Boot checks digital signatures against trusted keys stored in hardware. If it detects any tampered components or components signed by untrusted entities, it aborts the boot process. This action prevents malicious software from compromising the operating system.

Secure Boot plays a critical role in configuring a Confidential Virtual Machine (CVM) by ensuring that only trusted entities participate in the boot chain. 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. As a result, Secure Boot strengthens the security of the operating system boot sequence.

6.2.1. 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.

6.2.2. 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:

Initialization: When a RHEL instance boots, the cloud-hosted firmware initially boots and implements the Secure Boot mechanism.
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.
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).
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.
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 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.

6.3. Configuring a RHEL instance on the AWS Marketplace with Secure Boot
링크 복사

To ensure that your RHEL instance on AWS has a secured booting sequence, use Secure Boot. To configure a Red Hat Enterprise Linux instance with Secure Boot support on AWS, launch a RHEL Amazon Machine Image (AMI) from the AWS Marketplace, pre-configured with the uefi-preferred enabled boot mode. The uefi-preferred option enables support for the Unified Extensible Firmware Interface (UEFI) boot loader required for Secure Boot. Without UEFI, the Secure Boot feature does not work.

Warning

To avoid security issues, generate and keep private keys apart from the current RHEL instance. Intruders can gain access to Secure Boot secrets for escalating their privileges if the same instance uses and stores them. For details on launching an AWS EC2 instance, see Get started with Amazon EC2.

Prerequisites

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

aws ec2 describe-images --image-id <ami-099f85fc24d27c2a7> --region <us-east-2> | grep -E '"ImageId"|"Name"|"BootMode"'

"ImageId": "ami-099f85fc24d27c2a7",
"Name": "RHEL-9.6.0_HVM_GA-20250423-x86_64-0-Hourly2-GP3",
"BootMode": "uefi-preferred"

$ aws ec2 describe-images --image-id <ami-099f85fc24d27c2a7> --region <us-east-2> | grep -E '"ImageId"|"Name"|"BootMode"'

"ImageId": "ami-099f85fc24d27c2a7",
"Name": "RHEL-9.6.0_HVM_GA-20250423-x86_64-0-Hourly2-GP3",
"BootMode": "uefi-preferred"

Copy to Clipboard

Toggle word wrap

You have installed the following packages on the RHEL instance:
- awscli2
- python3
- openssl
- efivar
- keyutils
- edk2-ovmf
- python3-virt-firmware

Procedure

Check the platform status of the RHEL Marketplace AMI instance:
```
mokutil --sb-state

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

SecureBoot disabled
Platform is in Setup Mode
```
Copy to Clipboard Toggle word wrap
The setup mode allows updating the Secure Boot UEFI variables within the instance.
Create a new random universally unique identifier (UUID) and store it in a system-generated text file:
```
uuidgen --random > GUID.txt
```
```
$ uuidgen --random > GUID.txt
```
Copy to Clipboard Toggle word wrap

Generate a new PK.key RSA private key and a self-signed PK.cer X.509 certificate for the Platform Key database:

openssl req -quiet \
-newkey rsa:3072 \
-nodes -keyout PK.key \
-new -x509 -sha256 \
-days 3650 \
-subj "/CN=Platform key/" \
-outform DER -out PK.cer

$ openssl req -quiet \
-newkey rsa:3072 \
-nodes -keyout PK.key \
-new -x509 -sha256 \
-days 3650 \
-subj "/CN=Platform key/" \
-outform DER -out PK.cer

Copy to Clipboard

Toggle word wrap

The openssl utility generates a common name Platform key for the certificate by setting output format to Distinguished Encoding Rules (DER).

Generate a new KEK.key RSA private key and a self-signed KEK.cer X.509 certificate for the Key Exchange Key database:

openssl req -quiet \
-newkey rsa:3072 \
-nodes -keyout KEK.key \
-new -x509 -sha256 \
-days 3650 \
-subj "CN=Key Exchange Key/" \
-outform DER -out KEK.cer

$ openssl req -quiet \
-newkey rsa:3072 \
-nodes -keyout KEK.key \
-new -x509 -sha256 \
-days 3650 \
-subj "CN=Key Exchange Key/" \
-outform DER -out KEK.cer

Copy to Clipboard

Toggle word wrap

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

$ 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

Copy to Clipboard

Toggle word wrap

Download the Microsoft Corporation UEFI CA 2011 Certificate:

wget https://go.microsoft.com/fwlink/p/?linkid=321194 --user-agent="Mozilla/5.0 (Windows NT 10.0; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/51.0.2704.103 Safari/537.36" -O MicCorUEFCA2011_2011-06-27.crt

$ wget https://go.microsoft.com/fwlink/p/?linkid=321194 --user-agent="Mozilla/5.0 (Windows NT 10.0; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/51.0.2704.103 Safari/537.36" -O MicCorUEFCA2011_2011-06-27.crt

Copy to Clipboard

Toggle word wrap

Download the updated UEFI Revocation List File of forbidden signatures (dbx) for x64 bits system:
```
wget https://uefi.org/sites/default/files/resources/x64_DBXUpdate.bin
```
```
$ wget https://uefi.org/sites/default/files/resources/x64_DBXUpdate.bin
```
Copy to Clipboard Toggle word wrap

Generate UEFI variables file using the virt-fw-vars utility:

virt-fw-vars --set-pk "$(< GUID.txt)" PK.cer \
--add-kek "$(< GUID.txt)" KEK.cer \
--add-db "$(< GUID.txt)" custom_db.cer \
--add-db 77fa9abd-0359-4d32-bd60-28f4e78f784b MicCorUEFCA2011_2011-06-27.crt \
--set-dbx DBXUpdate.bin -i /usr/share/edk2/ovmf/OVMF_VARS.secboot.fd \
--output VARS

$ virt-fw-vars --set-pk "$(< GUID.txt)" PK.cer \
--add-kek "$(< GUID.txt)" KEK.cer \
--add-db "$(< GUID.txt)" custom_db.cer \
--add-db 77fa9abd-0359-4d32-bd60-28f4e78f784b MicCorUEFCA2011_2011-06-27.crt \
--set-dbx DBXUpdate.bin -i /usr/share/edk2/ovmf/OVMF_VARS.secboot.fd \
--output VARS

Copy to Clipboard

Toggle word wrap

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

Convert UEFI variables to the Extensible Firmware Interface (EFI) Signature List (ESL) format:
```
python3 /usr/share/doc/python3-virt-firmware/experimental/authfiles.py \
--input VARS \
--outdir .
for f in PK KEK db dbx; do tail -c +41 $f.auth > $f.esl; done
```
```
$ python3 /usr/share/doc/python3-virt-firmware/experimental/authfiles.py \
--input VARS \
--outdir .
$ for f in PK KEK db dbx; do tail -c +41 $f.auth > $f.esl; done
```
Copy to Clipboard Toggle word wrap
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.

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

To transfer PK.esl, enter:

efivar -w -n 8be4df61-93ca-11d2-aa0d-00e098032b8c-PK -f PK.esl

# efivar -w -n 8be4df61-93ca-11d2-aa0d-00e098032b8c-PK -f PK.esl

Copy to Clipboard

Toggle word wrap

To transfer KEK.esl, enter:

efivar -w -n 8be4df61-93ca-11d2-aa0d-00e098032b8c-KEK -f KEK.esl

# efivar -w -n 8be4df61-93ca-11d2-aa0d-00e098032b8c-KEK -f KEK.esl

Copy to Clipboard

Toggle word wrap

To transfer db.esl, enter:

efivar -w -n d719b2cb-3d3a-4596-a3bc-dad00e67656f-db -f db.esl

# efivar -w -n d719b2cb-3d3a-4596-a3bc-dad00e67656f-db -f db.esl

Copy to Clipboard

Toggle word wrap

To transfer the dbx.esl UEFI revocation list file for x64 architecture, enter:

efivar -w -n d719b2cb-3d3a-4596-a3bc-dad00e67656f-dbx -f dbx.esl

# efivar -w -n d719b2cb-3d3a-4596-a3bc-dad00e67656f-dbx -f dbx.esl

Copy to Clipboard

Toggle word wrap

Reboot the instance from the AWS console.

Verification

Verify if Secure Boot is enabled for the RHEL instance:
```
mokutil --sb-state

SecureBoot enabled
```
```
$ mokutil --sb-state

SecureBoot enabled
```
Copy to Clipboard Toggle word wrap

Use the keyctl utility to verify the kernel keyring for the custom certificate:

sudo keyctl list %:.platform

4 keys in keyring:
907254483: ---lswrv     0     0 asymmetric: Signature Database key: f064979641c24e1b935e402bdbc3d5c4672a1acc
...

$ sudo keyctl list %:.platform

4 keys in keyring:
907254483: ---lswrv     0     0 asymmetric: Signature Database key: f064979641c24e1b935e402bdbc3d5c4672a1acc
...

Copy to Clipboard

Toggle word wrap

6.4. Configuring a RHEL instance from a custom RHEL image with Secure Boot
링크 복사

To ensure that your RHEL instance on AWS has secured booting sequence, use Secure Boot. When a custom RHEL Amazon machine images (AMI) is registered, the image consists of pre-stored Unified Extensible Firmware Interface (UEFI) variables for Secure Boot. This enables all the instances launched from the RHEL AMI to use the Secure Boot mechanism with the required variables on the first boot.

Prerequisites

You have created and uploaded an AWS AMI image. For details, see Creating and uploading AWS AMI.
You have installed the following packages:
- awscli2
- python3
- openssl
- efivar
- keyutils
- python3-virt-firmware

Procedure

Create a new random universally unique identifier (UUID) and store it in a system-generated text file:
```
uuidgen --random > GUID.txt
```
```
$ uuidgen --random > GUID.txt
```
Copy to Clipboard Toggle word wrap
Generate a new RSA private key PK.key and a self-signed X.509 certificate PK.cer for the platform Key database:
```
openssl req -quiet \
-newkey rsa:3072 \
-nodes -keyout PK.key \
-new -x509 -sha256 \
-days 3650 \
-outform DER -out PK.cer
```
```
$ openssl req -quiet \
-newkey rsa:3072 \
-nodes -keyout PK.key \
-new -x509 -sha256 \
-days 3650 \
-outform DER -out PK.cer
```
Copy to Clipboard Toggle word wrap
The openssl utility generates a common name platform key for the certificate by setting output format to Distinguished Encoding Rules (DER).

Generate a new RSA private key KEK.key and a self-signed X.509 certificate KEK.cer for the Key Exchange Key database:

openssl req -quiet \
-newkey rsa:3072 \
-nodes -keyout KEK.key \
-new -x509 -sha256 \
-days 3650 \
-subj "/CN=Key Exchange Key/" \
-outform DER -out KEK.cer

$ openssl req -quiet \
-newkey rsa:3072 \
-nodes -keyout KEK.key \
-new -x509 -sha256 \
-days 3650 \
-subj "/CN=Key Exchange Key/" \
-outform DER -out KEK.cer

Copy to Clipboard

Toggle word wrap

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

$ 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

Copy to Clipboard

Toggle word wrap

Download the updated UEFI Revocation List File of forbidden signatures (dbx) for 64 bit system:
```
wget https://uefi.org/sites/default/files/resources/x64_DBXUpdate.bin
```
```
$ wget https://uefi.org/sites/default/files/resources/x64_DBXUpdate.bin
```
Copy to Clipboard Toggle word wrap
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 --output-aws aws_blob.bin \
--set-pk "$(< GUID.txt)" PK.cer \
--add-kek "$(< GUID.txt)" KEK.cer \
--add-db "$(< GUID.txt)" custom_db.cer \
--add-db 77fa9abd-0359-4d32-bd60-28f4e78f784b MicCorUEFCA2011_2011-06-27.crt \
--set-dbx x64_DBXUpdate.bin
```
```
$ virt-fw-vars --output-aws aws_blob.bin \
--set-pk "$(< GUID.txt)" PK.cer \
--add-kek "$(< GUID.txt)" KEK.cer \
--add-db "$(< GUID.txt)" custom_db.cer \
--add-db 77fa9abd-0359-4d32-bd60-28f4e78f784b MicCorUEFCA2011_2011-06-27.crt \
--set-dbx x64_DBXUpdate.bin
```
Copy to Clipboard Toggle word wrap
The customized blob consists of:
- PK.cer with a self-signed X.509 certificate
- KEK.cer and custom_db.cer with owner group GUID and Privacy Enhanced Mail (pem) format
- x64_DBXUpdate.bin list downloaded from database of excluded signatures (dbx).
- The 77fa9abd-0359-4d32-bd60-28f4e78f784b UUID is for MicCorUEFCA2011_2011-06-27.crt Microsoft Corporation UEFI Certification Authority 2011.

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 rhel9-example-ami \
--architecture x86_64 \
--virtualization-type hvm \
--root-device-name "/dev/sda1" \
--block-device-mappings "{\"DeviceName\": \"/dev/sda1\",\"Ebs\": {\"SnapshotId\": \"snap-example-id\"}}" \
--ena-support --boot-mode uefi \
--region eu-central-1 \
--uefi-data $(cat aws_blob.bin)

$ aws ec2 register-image \
--name rhel9-example-ami \
--architecture x86_64 \
--virtualization-type hvm \
--root-device-name "/dev/sda1" \
--block-device-mappings "{\"DeviceName\": \"/dev/sda1\",\"Ebs\": {\"SnapshotId\": \"snap-example-id\"}}" \
--ena-support --boot-mode uefi \
--region eu-central-1 \
--uefi-data $(cat aws_blob.bin)

Copy to Clipboard

Toggle word wrap

Reboot the instance from the AWS Console.

Verification

Verify if Secure Boot is enabled:
```
mokutil --sb-state
SecureBoot enabled
```
```
$ mokutil --sb-state
SecureBoot enabled
```
Copy to Clipboard Toggle word wrap

Use the keyctl utility to verify the kernel keyring for the custom certificate:

sudo keyctl list %:.platform

4 keys in keyring:
907254483: ---lswrv     0     0 asymmetric: Signature Database key: f064979641c24e1b935e402bdbc3d5c4672a1acc
...

$ sudo keyctl list %:.platform

4 keys in keyring:
907254483: ---lswrv     0     0 asymmetric: Signature Database key: f064979641c24e1b935e402bdbc3d5c4672a1acc
...

Copy to Clipboard

Toggle word wrap

Chapter 6. Configuring RHEL on AWS with Secure Boot

6.1. Types of RHEL AMI on AWS
링크 복사

6.2. Understanding secure boot for RHEL on cloud
링크 복사

6.2.1. Components of secure boot
링크 복사

6.2.2. Stages of secure boot for RHEL on cloud
링크 복사

6.3. Configuring a RHEL instance on the AWS Marketplace with Secure Boot
링크 복사

6.4. Configuring a RHEL instance from a custom RHEL image with Secure Boot
링크 복사

자세한 정보

평가판, 구매 및 판매

커뮤니티

Red Hat 문서 정보

보다 포괄적 수용을 위한 오픈 소스 용어 교체

Red Hat 소개

Theme

Red Hat legal and privacy links

Red Hat legal and privacy links

Chapter 6. Configuring RHEL on AWS with Secure Boot

6.1. Types of RHEL AMI on AWS링크 복사링크가 클립보드에 복사되었습니다!

6.2. Understanding secure boot for RHEL on cloud링크 복사링크가 클립보드에 복사되었습니다!

6.2.1. Components of secure boot링크 복사링크가 클립보드에 복사되었습니다!

6.2.2. Stages of secure boot for RHEL on cloud링크 복사링크가 클립보드에 복사되었습니다!

6.3. Configuring a RHEL instance on the AWS Marketplace with Secure Boot링크 복사링크가 클립보드에 복사되었습니다!

6.4. Configuring a RHEL instance from a custom RHEL image with Secure Boot링크 복사링크가 클립보드에 복사되었습니다!

자세한 정보

평가판, 구매 및 판매

커뮤니티

Red Hat 문서 정보

보다 포괄적 수용을 위한 오픈 소스 용어 교체

Red Hat 소개

Theme

Red Hat legal and privacy links

Red Hat legal and privacy links

6.1. Types of RHEL AMI on AWS
링크 복사

6.2. Understanding secure boot for RHEL on cloud
링크 복사

6.2.1. Components of secure boot
링크 복사

6.2.2. Stages of secure boot for RHEL on cloud
링크 복사

6.3. Configuring a RHEL instance on the AWS Marketplace with Secure Boot
링크 복사

6.4. Configuring a RHEL instance from a custom RHEL image with Secure Boot
링크 복사