Brian "bex" Exelbierd

— On the schedule —

Shim in 2026: A Certificate Rotation and a Decade-Overdue OpenSSL Migration

Every Linux distribution that ships with UEFI Secure Boot relies on a small bootloader called shim to verify the next link in the boot chain. Shim does this with a vendored copy of OpenSSL, statically linked into a UEFI binary that runs before any operating system loads. For years, that copy was frozen. An earlier attempt to update it was reverted because newer OpenSSL enforced stricter X.509 validation, rejecting certificates already deployed in production firmware. The project could not track upstream without risking boot failures on real machines. In 2026, two crypto-related transitions hit this codebase at the same time. The Microsoft UEFI CA 2011 had a known expiration date from the day it was issued. Fifteen years later, the ecosystem still arrived at that deadline with work to do. The certificate rotation is not primarily a technical problem; it is a coordination problem across a matrix of organizations (Microsoft, distributions, OEMs, cloud platforms) that share no common authority. Brian will cover how a small community managed that alongside a simultaneous engineering effort, and where the certificate side landed. Separately, and for different reasons, Nicolas completed a port of shim's vendored OpenSSL to version 3.5.0, merged in July 2026. The motivation was PQC readiness and a desire to stop diverging from upstream. This was not a version bump. Porting a modern OpenSSL into a pre-OS UEFI environment meant solving problems at every layer: missing libc primitives, platform-specific assumptions that don't hold without an OS, a roughly 3x binary size increase from the provider architecture, and a build system that had to be reworked from the ground up. Nicolas will walk through the categories of challenge, what was solved, what was stripped, and what remains uncomfortable. The talk closes with a question for the OpenSSL community: what would a "boot-time consumer" profile look like? Shim is likely not the only project that embeds OpenSSL where there is no operating system. The challenges (binary size, provider overhead, no runtime configuration, certificates spanning decades of varying standards compliance) are shared. And if the answer is that OpenSSL is not the right long-term fit for pre-OS environments, that is worth discussing openly, because Rust-based alternatives are already being explored in this space.