{
  "$type": "site.standard.document",
  "bskyPostRef": {
    "cid": "bafyreigjqpnpe5btoqivo43oqbxbwe3sxfpz5oggxjyoqd5koct2fvbyiy",
    "uri": "at://did:plc:46ti67tc37qcmwp2vaynk6fq/app.bsky.feed.post/3mmfsre6r5dy2"
  },
  "path": "/2026/05/22#secure_boot_ca_rollover",
  "publishedAt": "2026-05-22T01:45:22.844Z",
  "site": "https://blog.einval.com",
  "tags": [
    "shim-review",
    "Debian\nwiki",
    "shim",
    "https://github.com/microsoft/secureboot_objects",
    "UEFI",
    "Secure Boot",
    "SecureBoot/CAChanges"
  ],
  "textContent": "## Background\n\nI'm a member of the EFI team in Debian, and I've done much of the work for Debian to support UEFI Secure Boot (SB) in recent years. We have included that support for a number of releases now, starting back with Debian 10 (aka _Buster_).\n\nI'm also a long-time accredited member of the shim-review team, the group that checks and approves shim binaries before Microsoft will sign them.\n\nSee the Debian\nwiki for lots of background details about Secure Boot and how we do things in Debian.\n\nSecure Boot depends on signatures, which are verified during boot using a chain of X.509 certificates. The root certificate(s) in the chain are embedded in computer firmware, then later software such as shim can add more certificates to extend the trust. Easy, right?\n\n## The problem - certificates expire...\n\nMicrosoft administer the most widespread Secure Boot root certificates, and have been doing so since the very beginning of UEFI Secure Boot as a concept. The Microsoft UEFI CA certificates are included in just about every x86 and x86-64 computer shipped, and also in quite a lot of arm64 machines too.\n\n(The fact that Microsoft is therefore a gatekeeper for Linux running under Secure Boot is very unpopular in some quarters, but this is just a fact of life in the world we live in.)\n\nThe current certificates have been around since 2011:\n\n**1. Windows Production PCA 2011 (used for signing Windows components)**\n``\n\n\n      Subject: C=US, ST=Washington, L=Redmond, O=Microsoft Corporation, CN=Microsoft Windows Production PCA 2011\n      Validity\n        Not Before: Oct 19 18:41:42 2011 GMT\n        Not After : Oct 19 18:51:42 2026 GMT\n\n\nThis expires in October this year, ~5 months from now.\n\n**2. Third Party Marketplace Root (used for signing option ROMs and other software)**\n``\n\n\n      Subject: C=US, ST=Washington, L=Redmond, O=Microsoft Corporation, CN=Microsoft Corporation UEFI CA 2011\n      Validity\n        Not Before: Jun 27 21:22:45 2011 GMT\n        Not After : Jun 27 21:32:45 2026 GMT\n\n\nFor Linux folks, this second certificate is more interesting - it is the root of the certificate chain that Microsoft use when signing shim for Linux distributions\n\n**This CA expires 5 weeks from today.**\n\n## OMG!!! Will all my existing Secure Boot machines stop booting?\n\nAlmost definitely not, no.\n\nThe specification for UEFI Secure Boot expects that valid dates on certificates should not be enforced for signatures here. All that matters here is the signatures themselves. Modulo buggy firmware, existing signed binaries should continue just fine.\n\n## New CAs to be aware of\n\nMicrosoft have published **three** new CAs:\n\n**1. A new CA used for signing device option ROMs**\n``\n\n\n      Subject: C=US, O=Microsoft Corporation, CN=Microsoft Option ROM UEFI CA 2023\n      Validity\n        Not Before: Oct 26 19:02:20 2023 GMT\n        Not After : Oct 26 19:12:20 2038 GMT\n\n\n**2. A new CA used for signing Windows components**\n``\n\n\n      Subject: C=US, O=Microsoft Corporation, CN=Windows UEFI CA 2023\n      Validity\n        Not Before: Jun 13 18:58:29 2023 GMT\n        Not After : Jun 13 19:08:29 2035 GMT\n\n\n**3. A new CA used for signing other software (e.g. shim)**\n``\n\n\n      Subject: C=US, O=Microsoft Corporation, CN=Microsoft UEFI CA 2023\n      Validity\n        Not Before: Jun 13 19:21:47 2023 GMT\n        Not After : Jun 13 19:31:47 2038 GMT\n\n\nNew machines and updated older machines will **most likely** have all of these new CAs installed. New machines are already shipping that **only** include the new CAs; they will not trust older software and this has already started causing problems for some users.\n\n## Isn't this is all a bit short notice?\n\nYes it is. :-(\n\nA common rule of thumb when deploying CA certificates is to start the process of replacement (\"rollover\") when a certificate reaches half of its lifetime. Unfortunately, Microsoft have done this very late. They generated new keys in 2023, but didn't start signing shim and other third-party software with the UEFI CA until October 2025.\n\n## If I'm a distro developer, what should I do?\n\nIf you already have an old shim signed by Microsoft for your distribution from before October 2025, then it will only be signed using the older CA that expires soon. On newer machines, your users will already not be able to boot your distro with Secure Boot enabled.\n\nIf you want your users to be able to use Secure Boot in future, you will need to get a new shim build submitted, reviewed and signed using the new CA. However, that signed build will not work on older machines unless they have had the new CAs installed. This is also likely to cause problems for some users. You should encourage your users to update their systems **NOW** before things break for them.\n\nThere is an interim solution which will work, but only if you're quick! Microsoft are currently returning shim binaries signed using **both** the old CA and the new CA. More specifically, for every binary that is submitted they will return two: one signed with each CA. If you use these directly, you'll need to plan to publish:\n\n  * 2 signed shim binaries\n  * 2 installers\n  * 2 sets of live/installer images\n  * etc.\n\n\n\nand explain to your users how they'll need to pick one. Good luck with that!\n\n**However** , it is possible to extract signatures from those signed shim binaries and attach them all onto one shim, giving you the Holy Grail here - a single shim that will boot on the vast majority of machines. Indeed, this is what I'm planning on doing in Debian. So-called \"dual-signed\" shims **may** provoke issues with buggy firmware, so be aware that you may have to deal with this too. But take heart: early testing by various distro folks with a dual-signed Fedora shim did not show any problems.\n\n## You have 5 weeks and counting...\n\nMicrosoft have promised to continue signing with the old CA as long as possible, right up to the last day. They understand how awkward things are going to be otherwise, and are trying to help here as much as possible.\n\nIn the shim-review team, we have been expecting to see a surge of shim submissions before the old CA expires, to make the most of the \"Holy Grail\" dual-signed shims described above. But we've been really surprised that this has **not** been happening.\n\nSo, this blog is a wake-up call for people doing Secure Boot with shim. Even if you're not going to be ready to ship a new shim binary to your users, you should really try to get a new build prepared and signed **NOW** so that you have it available to tide you over through the coming CA transition. Don't leave it too late.\n\nIf you're not sure what to do, ask me and the other shim-review folks. We're happy to give advice. But don't delay.\n\n**You have 5 weeks and counting.**\n\n## References\n\n  * Microsoft ship all their CA certificates and binaries you can use to update computers at https://github.com/microsoft/secureboot_objects\n  * The Debian wiki has a lot more information about UEFI and Secure Boot already, and I'm going to be adding more user-focused documentation about the CA rollover at SecureBoot/CAChanges shortly.\n\n\n\nI'll add more links here in the coming weeks.",
  "title": "Steve McIntyre: Secure Boot and CA Rollover - a heads-up for distributions",
  "updatedAt": "2026-05-21T23:43:00.000Z"
}