Secure Boot and PXE: the chicken, the egg and four ways out

Provisioning a fleet of blank Windows machines over the network, by PXE, with Secure Boot on and never turned off, runs into a paradox you only see once your nose is against it. To boot over PXE, the boot binary must be signed or trusted by the firmware. To sign or enroll a key, you need to boot an OS. With no pre-existing OS on the machine, you can therefore neither boot nor enroll and that is exactly the situation of a fresh machine you want to install over the network in the first place. Here is the chain of trust as it must hold, then the four real ways out.

The chain of trust and why snponly

UEFI firmware (Microsoft CA enrolled natively by the OEM)
  └─ snponly.efi            ← must be trusted
       └─ wimboot           ← signed by the Microsoft UEFI CA
            └─ boot.wim (WinPE)
                 └─ Windows Setup

The choice of snponly.efi over ipxe.efi is not a detail. ipxe.efi embeds its own network drivers, binary blobs that are not in the Secure Boot chain of trust, so a strict firmware rejects them or behaves in undefined ways. snponly.efi delegates networking entirely to the firmware through the Simple Network Protocol, loads no extra code and keeps the chain intact. wimboot and the WIMs are not EFI binaries and do not go through Secure Boot validation, which simplifies things that much more.

Option A, enroll a key through the BMC

Servers with a BMC, iDRAC, iLO or standard Redfish, let you enroll a key into the Secure Boot database with no OS, over the network. You generate a certificate, sign your custom iPXE binary and push the certificate into the UEFI database through the Redfish API, driven by Ansible.

# RSA-2048 required, shim freezes with 4096
openssl req -newkey rsa:2048 -nodes -keyout MOK.key \
  -new -x509 -sha256 -days 3650 -subj "/CN=Foreman PXE MOK/" -out MOK.crt
sbsign --key MOK.key --cert MOK.crt --output snponly.efi.signed snponly.efi

The Redfish enrollment itself varies from one vendor to the next, so test it on one unit before generalising, but the principle is clean and hands-free and it scales well on a homogeneous server fleet.

Option B, have Microsoft sign your binary

Microsoft accepts submissions of third-party EFI binaries and iPXE was accepted this way after a security review. You can submit your own build. It is clean and hands-free, but the process takes weeks, requires an external review and freezes the embedded script in the signed binary, so any change needs a new submission. Suited to a long-term infrastructure with a stable binary, not to anyone who wants to iterate.

Option C, reuse binaries already signed by Microsoft

This is the most direct approach if you have a commercial imaging suite that ships ipxe.efi and snponly.efi already signed by the Microsoft UEFI CA. Those binaries are standard iPXE and their customisation goes through the DHCP server, not through a script frozen in the binary. The technique is iPXE’s classic “breaking the loop”: the DHCP detects whether the client is already an iPXE, through the user-class and then returns the URL of its script instead of the binary.

# dhcpd.conf
if exists user-class and option user-class = "iPXE" {
    filename "http://foreman.example/unattended/iPXE?bootstrap=1";
} elsif option client-arch = 00:07 {        # UEFI x86_64
    filename "boot/snponly.efi";             # Microsoft-signed binary
} elsif option client-arch = 00:00 {         # legacy BIOS
    filename "boot/undionly.kpxe";
}

The full flow then runs with no MOK at all: the machine asks for the signed binary, which is accepted without enrollment, iPXE redoes a DHCP with the user-class, retrieves the script, loads the signed wimboot and boot.wim over HTTP and WinPE starts, Secure Boot active end to end. Serve wimboot and the WIMs over HTTP and not TFTP, because TFTP is too slow for files of several hundred megabytes. This is the option I recommend when it is available: zero enrollment, zero modification of the machines, zero dependency on a pre-existing OS.

A point of vigilance on WinPE: machines with the Windows UEFI CA 2023 enrolled, recent hardware or a late Windows Update, can reject the old bootmgfw.efi of a WinPE built with too old an ADK. Recent wimboot handles the selection automatically; with an old ADK you have to patch the WIM by hand.

Option D, MOK enrollment by a technician

For fleets with no Redfish BMC and no signed binary available, or for workstations outside the other options, a technician intervenes once per machine, two or three minutes and the key is then persistent in the firmware. The simplest path is not even Linux: most modern UEFI firmwares include Secure Boot key management in the setup, so a MOK.cer on a FAT32 stick and some navigation in the “Key Management” menu is enough, with Secure Boot never disabled, even temporarily. The labels vary by vendor and when the option does not appear it is because the firmware is in standard mode, which you first switch to custom, without erasing the Microsoft keys already present. For tracking, a playbook that lists the enrolled MOKs lets you spot the machines still missing one.

Pick your poison

The chicken-and-egg paradox of Secure Boot and PXE looks like a wall and it invites the worst answer, disabling Secure Boot “just for the install”, which is precisely what you must not do on a fleet. The four ways out differ mostly by what you already own: a server fleet with BMCs goes to Redfish, a fleet with a signed imaging suite goes to the DHCP redirect, a long-term stable need to the Microsoft submission and the rest to manual enrollment. The common thread is that Secure Boot stays on end to end in the first three and that you only enroll what you signed yourself when there is no other way. Disabling Secure Boot to install a machine you want secured is a contradiction in terms and each of these options exists precisely so you never have to commit it.