How To Enroll PK Keys | Custom Secure Boot Setup

Enrolling a Platform Key (PK) establishes a custom root of trust for Secure Boot, controlling which OSes and bootloaders your UEFI firmware accepts.

The wrong Platform Key can lock a machine out of its own operating system — so the enrollment process needs exact steps, not guesses. When a Linux installation requires custom Secure Boot signatures, enrolling PK keys is the step that transitions the system from Setup Mode to User Mode. The Platform Key sits at the top of the Secure Boot trust chain, and installing your own lets you sign bootloaders and kernels that manufacturer keys won’t cover.

What Are PK Keys and Why Enroll Them?

Platform Keys (PK) are the root certificates in the UEFI Secure Boot hierarchy. Enrolling a custom one replaces the manufacturer’s key and gives you full control over boot-time signature verification. The chain works like this:

• PK (Platform Key) — the root of trust. Only the holder of the private key can update the Key Exchange Key.
• KEK (Key Exchange Key) — controls updates to the signature database (db) and revoked database (dbx).
• db (Signature Database) — lists hashes or certificates of approved bootloaders and drivers.
• dbx (Revoked Database) — lists signatures that are explicitly blocked.

Custom PK enrollment is standard for openSUSE, Fedora, and other Linux distributions that ship their own signed bootloaders. It’s also required for custom OS builds and virtual machine security configurations where the default Microsoft keys aren’t sufficient.

What You Need Before Starting

A successful PK enrollment requires specific hardware, file formats, and tools. Missing any one of these stops the process cold.

Enrolling PK Keys: The Step Order That Works

Manual PK enrollment follows a fixed sequence: generate a DER-format certificate, place it on a FAT32 volume, switch Secure Boot to Custom mode, and select the file from the UEFI Device Manager. HPE’s official Secure Boot enrollment guide documents the same procedure for their systems.

Generate the PK Certificate

Use OpenSSL to create a self-signed certificate and private key. The output file must be in DER format — UEFI firmware does not accept PEM.

openssl req -new -x509 -newkey rsa:2048 -keyout pk.key -out pk.cer -days 3650 -subj "/CN=MyPK"

Copy the resulting pk.cer file to a FAT32-formatted USB drive or your EFI System Partition (typically mounted at /boot/efi).

Enter UEFI Firmware Settings

Restart the machine and press the manufacturer’s key during boot — Esc, Delete, F1, F2, F10, F11, or F12 depending on the motherboard. On Windows, hold Shift while clicking Restart, then go to Troubleshoot → Advanced Options → UEFI Firmware Settings.

Switch to Custom Mode

Navigate to the Secure Boot configuration menu. The exact label varies, but look for:

• Device Manager → Secure Boot Configuration
• Change Secure Boot Mode from Standard to Custom

This unlocks the PK enrollment options. In Standard mode the firmware will not allow you to enroll a new key.

Enroll the PK File

• Select PK Options → Enroll PK → Enroll PK Using File
• Browse to the correct volume — verify the label shows your USB drive or ESP, not the internal HDD
• Select your pk.cer or PKtestDer.cer file
• Confirm by selecting Commit Changes and Exit

The system now transitions to User Mode with your custom PK installed.

What Happens After You Enroll the PK

Once the PK is enrolled, the firmware moves from Setup Mode to User Mode. You must then enroll the Key Exchange Key (KEK) and signature database (db) to complete the Secure Boot chain. The same file-browsing process applies:

• Generate and copy a KEK certificate (KEK-2023.der) to the same volume
• Go to KEK Options → Enroll KEK → Enroll KEK Using File
• Repeat for db Options using your custom database certificate

After all three keys are enrolled, return to Secure Boot Mode and set it back to Standard — unless your setup requires fully custom signatures across the board. Confirm that Secure Boot shows Enabled before exiting the firmware.

Common Pitfalls That Block PK Enrollment

Most PK enrollment failures come from a small set of preventable mistakes. This table covers the ones that cause the most trouble.

Checklist for a Clean PK Enrollment

Run through this list after the final commit to confirm everything took hold:

• Secure Boot Mode is set to Standard (or Custom if fully self-signed)
• Secure Boot Status reads Enabled — not Disabled or Setup Mode
• PK, KEK, and db all show your custom certificate thumbprints in the firmware list
• The machine boots the target OS (Linux distribution, custom kernel) without Secure Boot errors
• A backup of the original Microsoft PK is saved and accessible if you ever need to revert

One test verifies everything: restart and watch for the Secure Boot logo or pass the mokutil --sb-state command in Linux. If it returns SecureBoot enabled, the PK enrollment worked exactly as designed.