UEFI HTTPS Boot Is Becoming Interesting, but Firmware Still Feels Like Infrastructure Archaeology

The old network boot stack is starting to look less inevitable. PXE, DHCP, and TFTP have been the default mental model for booting machines over the network for decades, but the developer conversation is shifting toward a simpler question: if nearly every other infrastructure path moved to HTTPS, why is early boot still so often tied to a clear-text, operationally awkward protocol stack?

A recent hands-on walkthrough of UEFI HTTP(S) boot with Qemu, OVMF, and netboot.xyz captures that shift well. The interesting part is not just that UEFI firmware can fetch an EFI binary over HTTP or HTTPS. The interesting part is how close the modern path feels to being practical, and how many low-level assumptions still leak through once TLS enters the boot path.

The trend observation is straightforward: developers and infrastructure engineers are testing whether network boot can become ordinary web infrastructure. HTTP gives teams familiar hosting, caching, observability, load balancing, and high availability patterns. HTTPS adds server authentication, confidentiality, and integrity to a stage of the system that often still relies on network trust. In principle, that makes boot artifacts easier to serve from controlled internal platforms, remote sites, or cloud storage, without treating the local network as a magic safe zone.

The evidence from the experiment is also revealing because it is not polished. A minimal Qemu invocation using OVMF and SLIRP networking can boot the snponly EFI image from netboot.xyz over HTTP, but only after adding a random number generator device with -device virtio-rng-pci. Without that RNG device, OVMF’s network stack never properly comes up. That detail is easy to miss because the failure mode is quiet: the firmware reports no bootable option, rather than pointing clearly at the missing EFI RNG protocol.

That small requirement says a lot about where firmware development still differs from application development. In an operating system, a missing entropy source might be logged by several layers, inspected with common tools, and fixed through a package or kernel setting. In firmware, the dependency is declared in EDK II metadata, such as the [Depex] section of NetworkPkg/Library/DxeNetLib/DxeNetLib.inf, where gEfiRngProtocolGuid quietly gates network functionality. That is technically coherent, but it is not discoverable in the way most modern infrastructure operators expect.

Once the RNG device is present, HTTP boot works. The firmware tries network boot paths in sequence, including IPv4 PXE, IPv6 PXE, and then IPv4 HTTP. The first successful result is a familiar iPXE startup screen and a netboot.xyz menu. The catch is time. A naive boot path can spend more than a minute waiting through irrelevant PXE and IPv6 attempts before the HTTP path succeeds.

That is where OVMF’s Qemu integration becomes useful. EDK II documents firmware runtime configuration through OvmfPkg/RUNTIME_CONFIG.md, including knobs such as opt/org.tianocore/IPv4PXESupport and opt/org.tianocore/IPv6PXESupport. Passing those through Qemu’s -fw_cfg interface lets the VM skip unwanted PXE attempts and reach HTTP boot in seconds instead of more than a minute. For lab work, CI experiments, and reproducible infrastructure testing, that is a strong adoption signal. Developers like paths that can be encoded in a command line and repeated without clicking through firmware menus.

A second adoption signal is the use of UEFI variables rather than DHCP-provided bootfile URLs. Real hardware does not expose Qemu’s OVMF-specific configuration surface, so the experiment turns to virt-firmware, specifically virt-fw-vars, to inject a one-time boot URI into an OVMF variable store. That path is more interesting than the first because it resembles how managed platforms might prepare machines or VM images before first boot. It also connects to Qemu’s newer paravirtualized variable work documented in OvmfPkg/QEMU_PV_VARS.md, even if the distribution build used in the test did not enable that route.

The HTTP side, then, is not especially mysterious once the pieces are known. Provide OVMF code and variables, provide a network device, provide entropy, optionally disable irrelevant boot paths, and point the firmware at an EFI binary. The story changes when the URL becomes HTTPS.

On paper, HTTPS boot should be a small upgrade. In practice, it exposes a stack of trust decisions that normal web clients hide. OVMF does not automatically ship with a browser-style CA bundle. The firmware has a TLS implementation, but it needs trust anchors. The experiment uses p11-kit to extract the host system’s trusted CA certificates into an EDK II-compatible format, then passes that bundle through -fw_cfg as etc/edk2/https/cacerts. EDK II’s documentation also points to virt-fw-sigdb as a way to build a narrower trust database.

This is where the security argument becomes more nuanced. Moving from TFTP to HTTPS is not just adding encryption. It changes who gets trusted, how certificate policy is enforced, and how boot reliability depends on TLS details that many infrastructure teams normally leave to browsers, curl, or managed load balancers. A firmware HTTPS client is not Firefox. It may not share the host operating system’s trust store. It may not expose useful diagnostics. It may enforce a different OpenSSL security level than the server operator expects.

That last point is the sharp edge in the walkthrough. After providing CA certificates, the HTTPS boot still fails. Only after rebuilding OVMF as a DEBUG build and collecting firmware logs through Qemu’s isa-debugcon path, as documented by Gerd Hoffmann in his firmware logging post, does the real error emerge. The TLS handshake fails because certificate verification rejects the end-entity certificate as too weak.

The underlying cause is OpenSSL security level policy. OpenSSL security levels control acceptable key sizes, ciphers, and related TLS properties. Many Linux distributions and OpenSSL defaults commonly operate at security level 2. The EDK II TLS library had been changed to set security level 3 by default, with discussion visible in the related EDK II pull request. Security level 3 is stricter, and in this case it rejects the certificate used by https://boot.netboot.xyz/, even though ordinary host tools and browsers may accept it.

This is a useful counterweight to the easy consensus that HTTPS boot is simply better PXE. It probably is better for many environments, but the operational contract changes. With PXE and TFTP, the dominant risks are unauthenticated delivery, clear-text transport, and brittle service topology. With HTTPS boot, the risks move toward trust-store management, certificate rotation, key strength policy, firmware compatibility, and sparse diagnostics. Those are better problems in many settings, but they are still problems.

Community sentiment around this kind of work tends to split into three groups. Firmware and virtualization engineers see progress because the components exist and are scriptable. Homelab and bare-metal enthusiasts see a promising way to replace aging PXE recipes with ordinary web hosting and projects like netboot.xyz. Production infrastructure teams are more cautious, because early boot is not a place where subtle certificate policy failures are acceptable. If a fleet cannot boot after a certificate renewal or firmware update, the elegance of HTTPS does not matter much in the incident channel.

The adoption signals are still real. Qemu can model the workflow. OVMF has HTTP and TLS support. netboot.xyz provides a public target that makes testing easy. iPXE remains a familiar bridge between firmware boot and richer boot menus. Tools such as virt-firmware make variable-store manipulation scriptable. EDK II documents several of the relevant configuration surfaces. That combination gives developers enough material to build reproducible tests, CI checks, and internal prototypes.

The counter-perspective is that this stack is not yet friendly. The first failed HTTP attempt may be caused by missing entropy. The first failed HTTPS attempt may be caused by missing CAs. The second failed HTTPS attempt may be caused by certificate strength policy. Debugging may require a DEBUG firmware build that a distribution does not ship. Each individual issue is reasonable once explained, but the path is too dependent on prior firmware knowledge.

There is also a hardware translation gap. Qemu and OVMF are excellent for learning, but real machines vary widely. Some firmware implementations expose HTTP boot settings in setup menus. Some expect DHCP options. Some support HTTPS with vendor-specific certificate enrollment flows. Some may support HTTP but not HTTPS in the way an operator expects. The EDK II behavior is highly relevant, but it is not the whole market.

For teams considering this pattern, the practical lesson is to separate HTTP boot from HTTPS boot during evaluation. First prove that the firmware can fetch and execute an EFI binary over plain HTTP in a controlled test network. Confirm that the boot order is sane and that irrelevant PXE or IPv6 attempts are not adding hidden delays. Then add HTTPS and treat certificates as a first-class boot dependency. Build a CA bundle intentionally, decide whether to trust the system CA set or a smaller internal trust root, and test certificate renewal before relying on the setup.

The stronger production pattern may be to mirror boot artifacts under a domain and certificate policy the team controls, rather than depending on a public endpoint. netboot.xyz is useful for testing and exploration, but production boot usually wants repeatability, artifact pinning, and clear ownership. Hosting the EFI binary, kernel, initramfs, and configuration behind internal HTTPS gives teams better control over certificate choices and cache behavior. It also makes it easier to audit what firmware is allowed to trust.

The broader pattern is familiar from other parts of infrastructure modernization. A newer protocol reduces old pain, but it imports the operational rules of the system it came from. HTTPS brings mature hosting and better transport security into network boot, but it also brings CA governance, TLS policy, and expiry handling into firmware. That trade is probably favorable, especially compared with unauthenticated TFTP, yet it should be made consciously.

The most interesting thing about this experiment is that it makes UEFI HTTPS boot feel both close and unfinished. Close, because a working Qemu command line can boot a real EFI payload over HTTPS after the right certificates and firmware policy are in place. Unfinished, because the debugging path still feels like reading firmware source, rebuilding OVMF, and interpreting OpenSSL reason codes by hand.

That is often what early infrastructure transitions look like. The capability arrives before the operator experience catches up. Developers start publishing working recipes. Tool authors fill gaps around configuration and inspection. Distributions decide which firmware features to enable. Server operators discover that browser-compatible TLS is not always firmware-compatible TLS. Consensus forms slowly, not around the headline feature, but around the boring details that make it dependable.

UEFI HTTP(S) boot deserves attention for that reason. It is not only a cleaner replacement for PXE in a lab. It is a sign that early boot is being pulled toward the same web-native operational model used everywhere else. The case for adoption is strong, but the current state rewards teams that test the full chain: firmware, entropy, DHCP or variables, CA material, TLS policy, artifact hosting, logging, and recovery. The future may be HTTPS boot, but the present still asks developers to understand exactly what their firmware is doing before trusting it with the first instruction of a machine.