Skip to content

Question: Should a Microsoft UEFI CA 2011-signed shim still boot on firmware that has completed Microsoft's 2023 Secure Boot certificate transition? #825

Open

Description

@dryada70749

Description

Hi,

I'm trying to understand the expected behavior of the upstream shim project regarding Microsoft's 2023 Secure Boot certificate transition.

Hardware

  • MSI Crosshair 16 Max HX E2WGXK
  • BIOS: E2652IMS.507 (latest)

Operating Systems

  • Windows 11
  • Ubuntu 26.04 LTS Desktop Live USB (official ISO)
  • Kubuntu 26.04 LTS

Both operating systems are installed in UEFI mode on separate NVMe SSDs.

Problem

With Secure Boot enabled:

  • Windows 11 boots normally.
  • Ubuntu 26.04 LTS Desktop Live USB (official ISO) fails before GRUB.
  • Kubuntu 26.04 LTS installed on SSD fails in exactly the same way.

Firmware reports:

Secure Boot Violation

Invalid signature detected.
Check Secure Boot Policy in Setup.

With Secure Boot disabled:

  • Windows boots normally.
  • Ubuntu boots normally.

Verification

I have verified the following:

  • Latest BIOS installed (E2652IMS.507)
  • Factory Secure Boot Keys restored
  • Secure Boot Standard Mode
  • Windows Secure Boot works correctly
  • Windows TPM Event ID 1808 confirms Microsoft's 2023 Secure Boot certificate transition completed successfully
  • Windows Status tool reports Windows UEFI CA 2023 is active
  • EFI Boot Entry points to EFI\ubuntu\shimx64.efi
  • shimx64.efi is Microsoft signed
  • grubx64.efi is Canonical signed
  • Ubuntu official signed kernel
  • shim-signed package version:
    1.59+15.8-0ubuntu2
  • SHA256 of /boot/efi/EFI/ubuntu/shimx64.efi is identical to /usr/lib/shim/shimx64.efi.signed

sbverify reports:

shim issuer:

Microsoft Corporation UEFI CA 2011

grub issuer:

Canonical Ltd. Master Certificate Authority

Question

My understanding is that Microsoft's 2023 Secure Boot certificate transition has already completed successfully on this machine, and Windows boots normally using the 2023-signed Windows Boot Manager.

However, the current Ubuntu official shim is still signed by Microsoft UEFI CA 2011.

I noticed issue #824 discusses updating Microsoft's db/KEK/dbx to the 2023 certificates after booting with shim, which seems to imply that a Microsoft UEFI CA 2011-signed shim is still expected to boot successfully.

Therefore I would like to ask:

  1. Is a Microsoft UEFI CA 2011-signed shim still expected to boot successfully on firmware that has already completed Microsoft's 2023 Secure Boot certificate transition?

  2. If the answer is yes, then the behavior I'm observing would appear unexpected.

  3. If the answer is no, is there an ongoing migration plan toward a 2023-signed (or dual-signed) shim for Ubuntu 26.04 LTS or future Ubuntu releases?

I'm not trying to determine whether this is an OEM firmware issue or an Ubuntu packaging issue.

I would simply like to understand the expected behavior of the upstream shim project regarding Microsoft's 2023 Secure Boot transition.

If additional information (sbverify output, mokutil output, Secure Boot database information, etc.) would be helpful, I'd be happy to provide it.

Thank you.

Activity

  1. changed the title [-]Question: Is Ubuntu 26.04 official shim-signed (1.59+15.8) expected to boot on firmware that has completed Microsoft's 2023 Secure Boot transition?[/-] [+]Question regarding Ubuntu 26.04 official shim and Microsoft's 2023 Secure Boot transition[/+] on Aug 6, 2026
  2. changed the title [-]Question regarding Ubuntu 26.04 official shim and Microsoft's 2023 Secure Boot transition[/-] [+]Question: Should a Microsoft UEFI CA 2011-signed shim still boot on firmware that has completed Microsoft's 2023 Secure Boot certificate transition?[/+] on Aug 6, 2026
  3. DanielMYT commented on Aug 23, 2026

    @DanielMYT

    Hello,

    I am not a developer of Ubuntu, nor a developer of Shim, nor have any affiliation with Microsoft/RedHat/Canonical, so I can't answer your questions definitively, but since your issue has been thus far ignored by the Shim maintainers, here are some insights that may or may not be helpful.

    Some newer Shims from commercial distros (e.g. Fedora Shim 16.1) are dual-signed by the 2011+2023 cert. Although Ubuntu is currently shipping an older Shim version (15.8) which they have yet to update to the latest version, presumably when (if?) they do, it will also be dual-signed, so as to maximise compatibility with older systems (as well as to provide a fallback for devices manufactured before 2023, in the case that their firmware SB databases get reset for some reason - so as to avoid getting locked out of booting into any OS).

    My guess is that Microsoft, being a very backwards-compatibility-obsessed company in general, would want to keep the 2011 certs around, for backwards compatibility with EFI apps signed by the older 2011 cert which are not revoked by updates to the UEFI forbidden signatures database (dbx).

    Another point is that, as far as I am aware, the BlackLotus vulnerability (one of the main incentives for the migration to new certs) only concerns Microsoft's first-party cert, used to sign Windows Boot Manager, not the third-party cert which is what signs shim and all other third party EFI applications, so a "fully migrated" system may only really need to revoke that first party 2011 cert ("Microsoft Windows Production PCA") and not the third party one ("Microsoft Corporation UEFI CA"). I may be mistaken on this point, so am open to being corrected if so, but on my own systems (where I have taken control of secure boot by enrolling my own platform keys), I am keeping the MS 2011 certs alongside the 2023 ones just for compatibility's sake.

    Another point of interest is that although the 2011 is (or is about to be) past it's ""expiry"" date, the physical cryptographic key is still valid. Microsoft could (in theory) roll back their system clocks to be able to continue using it for signing new binaries if they really needed to. I can't speak for whether they will or not, but anything is possible... 🤔

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions