Veracrypt appears to be signed with the 2011 CA which will stop working June 27th 2026

[Motophan]

From what I can tell in June everyone w/ veracrypt will have their secureboot stop working because vc signs itself from the 2011 ca and not the 2023 ca. This means w11 will complain about secure boot not being valid, and in some cases will not show a screen / ignore the boot option instead of continuing.

Can we rush a version bump for this please?

sudo sbverify --list DcsBoot.efi

results in

    signature 1
    image signature issuers:
     - /C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/CN=Microsoft Corporation UEFI CA 2011
    image signature certificates:
     - subject: /C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/CN=Microsoft Windows UEFI Driver Publisher
       issuer:  /C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/CN=Microsoft Corporation UEFI CA 2011
     - subject: /C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/CN=Microsoft Corporation UEFI CA 2011
       issuer:  /C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/CN=Microsoft Corporation Third Party Marketplace Root

[dacervera]

If the leaf cert is a code or firmware-signing cert, the signer applies a time stamp on signed objects so that what matters is that the certificate was valid at the moment it was originally signed so that even if the certificate (or any of the CAs above it) were to simply expire (not revoked), software signed a decade ago will still keep working. My sense is, it's the same in this case. People depend on their hardware for quite a long time--we don't want these devices to brick--but we still want the cert chains to continue to validate, so that's why you'll sometimes see expired CA certs in a trust store--if that CA or its subordinates issued code/firmware signing certs, the aging cert is kept to allow software that some parts of the industry still rely on will continue to function.

[Motophan]

For me, setting my BIOS clock ahead to 1-1-27 causes a warn about secure boot, then reboot to firmware interface. This may not be what is suppose to happen, but it do.

Yes I can turn secure boot off, but then I cant play MMO's anymore because their anticheat will see secure boot off (vanguard get mad). I will also be noncompliant for w11 minimum standards.

it was vbios, ignore above comment. >2027 seeems to work in bios clock, sorry.

[TinchoteSK]

@dacervera The certificate will be revoked later this year.

@Motophan I think the 2027 date worked because the certificate has not yet been revoked.

[MartyMacGyver]

Will this break portable mode as well?

Given the new signing problems mentioned in the project update an update may not be forthcoming soon if at all.

[dartraiden]

Users will be able to solve this problem themselves

• sign EFI bootloader manually with their own certificate and add to the trusted ones in the Secure Boot storage
  see [HowTo] SecureBoot support Drive-Trust-Alliance/sedutil#259 for reference

or

• disable Secure Boot at all

[idrassi]

I investigated this in detail and I want to summarize the situation clearly because this issue can easily be misunderstood.

The current VeraCrypt EFI bootloader is signed through Microsoft Corporation UEFI CA 2011. This is the Microsoft third-party UEFI CA that has historically been used for non-Microsoft EFI boot applications, including Linux shim and similar boot components.

The important distinction is between certificate expiration and revocation through DBX.

Microsoft's own guidance for UEFI submitters states that expiration of the 2011 UEFI CA does not invalidate binaries already signed with the 2011 certificate as long as the device still has that 2011 CA in its Secure Boot db:
https://techcommunity.microsoft.com/blog/hardware-dev-center/signing-with-the-new-2023-microsoft-uefi-certificates-what-submitters-need-to-kn/4455787

Microsoft also states in the same article that, from October 20, 2025 until June 2026, each approved UEFI submission returns two signed files:

• one signed with the existing 2011 UEFI CA
• one signed with the new 2023 UEFI CA

The recommended Microsoft model is therefore not one universal binary and not one old bootloader plus one new bootloader. The model is:

• same bootloader code, signed under the 2011 CA
• same bootloader code, signed under the 2023 CA
• installer detects what the firmware trusts and installs the appropriate signed file

Microsoft also explicitly says that existing 2011-signed binaries remain valid on devices that still trust the 2011 CA in db and a
Microsoft reply in that article says that there are currently no plans to revoke the 2011 UEFI CA using DBX.

So, based on the information available today, I don't expect existing VeraCrypt installations to all stop booting on June 27, 2026 solely because the 2011 UEFI CA expires. Systems that still have Microsoft Corporation UEFI CA 2011 in their Secure Boot database should continue to trust the existing VeraCrypt bootloader unless that CA is later removed or blocked by firmware policy.

However, this is still an important compatibility and security maintenance issue:

• Microsoft will stop signing new submissions with the 2011 CA after the transition period.
• Some newer systems may have only the 2023 Microsoft UEFI CA and may not trust old 2011-signed VeraCrypt bootloaders.
• Systems that receive the 2023 CA need VeraCrypt boot components signed with the 2023 CA.
• Systems that have not yet received the 2023 CA still need VeraCrypt boot components signed with the 2011 CA.
• Recovery media also has to be considered, because bootable media must match what the target firmware trusts.

This is also how other projects are handling the transition. Red Hat's Secure Boot guidance says existing systems using 2011-signed shim continue to boot, while updated shim binaries are being prepared/signed for the 2023 CA: https://developers.redhat.com/articles/2026/02/04/secure-boot-certificate-changes-2026-guidance-rhel-environments

fwupd documents the same ecosystem issue: existing machines do not simply stop booting when the certificate expires but new and updated boot media must move to the new CA: https://fwupd.github.io/libfwupdplugin/uefi-db.html

There is a separate Microsoft Secure Boot hardening process related to CVE-2023-24932 / BlackLotus. That process concerns revocation of Microsoft Windows Production PCA 2011 which signs Windows Boot Manager. This is NOT the same certificate as Microsoft Corporation UEFI CA 2011, which signs third-party UEFI applications such as VeraCrypt's EFI bootloader.

Microsoft's KB5025885 explains that applying the DBX revocation blocks Windows boot managers signed by Windows Production PCA 2011: https://support.microsoft.com/en-us/topic/kb5025885-how-to-manage-the-windows-boot-manager-revocations-for-secure-boot-changes-associated-with-cve-2023-24932-41a975df-beb2-40c1-a3-b3ff139f832d

For VeraCrypt, this separate Windows Boot Manager issue matters because VeraCrypt keeps/uses a Windows Boot Manager path during the boot chain. Therefore, part of the work is to make sure that the backed-up Windows Boot Manager used by VeraCrypt is refreshed when needed, so that it is not an obsolete Windows Production PCA 2011-signed boot manager on systems that have already moved to the 2023 Windows boot manager.

After considering all this, I have decided to prepare a VeraCrypt 1.26.28 maintenance release focused on this Secure Boot transition.

The goal for this 1.26.28 release is:

1. Submit the VeraCrypt EFI bootloader components for new Microsoft signing as soon as possible.
2. Ship the appropriate Microsoft-signed EFI bootloader variants, following Microsoft's 2011/2023 transition model.
3. Install the 2023-signed VeraCrypt bootloader when the firmware trusts Microsoft UEFI CA 2023.
4. Install the 2011-signed VeraCrypt bootloader when the firmware still only trusts Microsoft Corporation UEFI CA 2011.
5. Update/review VeraCrypt rescue media handling accordingly.
6. Review the Windows Boot Manager backup/chainload handling so that the separate Windows PCA2011 DBX revocation does not leave users with an old Windows boot manager behind VeraCrypt.

The new 1.26.28 release will address the immediate signing/compatibility pressure for current users, while VeraCrypt 1.27 can continue to be prepared properly with its own updated bootloader and driver changes.

For users:

• Non-system encrypted volumes and containers are not affected by this UEFI CA transition. They are mounted after the operating system has booted and do not depend on the VeraCrypt EFI bootloader.
• This issue concerns system encryption on UEFI systems with Secure Boot enabled.
• Existing VeraCrypt system-encrypted installations are not expected to suddenly stop booting solely because the 2011 UEFI CA expires, provided the firmware still trusts that CA.
• Nevertheless, users of VeraCrypt system encryption with Secure Boot should upgrade to the new 1.26.28 release once available, and regenerate rescue media after upgrading.
• Users should also keep Windows and firmware updates current, because Microsoft is rolling out the 2023 Secure Boot certificates through Windows/OEM update channels.

I will keep this issue updated as the signing and release process progresses.