TeraByte Unlimited

The procedure described in

Boot Failure: Secure Boot Error (“Did Not Authenticate”, “No Signature”)

Only works in newer computers which are factory updated to the CA 2023 certificates, and have the option to enable or disable UEFI CA 2011 in the Secure Boot setup.

I updated manually the certificates in an old Dell laptop, and after that Secure Boot blocks the IFL boot. IFW boots normally.

UEFI CA 2011 is in the DB database.

Any workaround in this case, besides disabling Secure Boot?

------Edited for clarity

are you using the 4.x version of IFL boot media?

Yes, I used 4.09.

Edited the fist post for clarity.

I tried with GParted (latest version), which is Linux-based, and it booted normally.

This problem happens with some manually-updated computers, and not with others.

I think it is related to the method used to update the certificates (I used Mosby), and will be solved with an update of the IFL boot files.

4.x already updated, if you're forcing update to include future (not scheduled at this time) revokes to shim then that can cause an issue.

V3.x won't work with updated certificates since they revoked all prior shim versions due to boothole issue.

I updated the certificates using Mosby, but the CA 2011 certificates were not revoked.

The error messages are:

Failed to open image: Security Policy Violation
Failed to open: \EFI\BOOT\mmx64.efi

There are several proposed "solutions" in the web. I tried some of them, they didn´t work.

Anyway, it´s not that important. I can use IFW or disable Secure Boot. And IFL works in my main computers, which haven´t been updated with Mosby.

Probably the boot item in the firmware for booting the UFD has garbage in its parameters.

Mosby is still a work in progress.

I think I have found why Secure Boot blocks the IFL boot after I updated the Certificates using Mosby.

It´s not because of a Mosby´s bug – it´s not a bug, but a feature.

It´s not because the CA 2011 certificates were revoked – they were not.

It´s because, as part of a “complete” update, Mosby “revokes” the bootloaders which are “too old”.

This has to do with the “SVN” level, which is set at 7 (high). The Mosby log shows:

Installing DBX: 'DBX for x86 (64 bit) [2025.10.16]'
Installing DBX: 'Windows Bootmgr SVN 7.0 DBX update [2025-06-06]'

A WinPE with IFW 4.09 is also affected, but a WinRE built on a recent HP computer is not. Also, GParted (Linux) is not affected, as posted above.

If the UFD is built with Rufus and the bootloader in the ISO is affected, Rufus shows a warning window.

You said *some* system have the issue and you showed:

> Failed to open image: Security Policy Violation
> Failed to open: \EFI\BOOT\mmx64.efi

If it's trying to load mmx64.efi (that is both message are related) it can mean the parameters of the UEFI boot item has garbage in it which would be related to the system rather than the update.

The SVN is specific to Windows boot loaders.

Shim type use SBAT

Where did you get the databases you're using?