Secure Boot "Invalid Key" on Zorin OS 18.1 (Acer Aspire ) - Looking for Solutions

[Duarte]

CONTEXT AND HISTORY

Model: Acer Aspire GX-781 (Desktop)
OS: Zorin OS 18.1 (Ubuntu 24.04 LTS)
BIOS: R02-A4 (10/12/2017)
Issue: "Invalid Signature" / "Invalid Key" when enabling Secure Boot (even with Microsoft 2011 and 2023 certificates in DB and valid shim).

Timeline:

• Kernel 6.17: Works with Secure Boot (but EOL, no updates).
• **Kernel 7.x+: "Invalid Key" (failure began after 2026-09-07; kernel 7.0.0-31 itself booted successfully with Secure Boot enabled from 2026-09-04 to at least 2026-09-07, per journalctl logs — so direct causation with the kernel update is not confirmed).
• DB 2023: Microsoft 2023 certificates present (verified via mokutil --db).
• shimx64.efi: Valid signature (Ubuntu 15.8-0ubuntu1, with SBAT).

Supporting logs:

$ grep "Start-Date" /var/log/apt/history.log | tail -5
Start-Date: 2026-09-04 19:27:25 <- linux-image-7.0.0-31-generic installed here

$ journalctl | grep "Secure boot enabled"
set 04 19:24:31 ... kernel: secureboot: Secure boot enabled
set 07 13:37:58 ... kernel: secureboot: Secure boot enabled

Core Question:

Why does Secure Boot reject Zorin's shim with kernel 7.x+ if 2023 certificates are present and the shim has a valid signature? Are there solutions beyond kernel downgrade or BIOS flash?

DETAILED TECHNICAL ANALYSIS
Current Environment
bash
Copiar

BIOS

$ sudo dmidecode -t bios | grep -E "Vendor|Version|Release"
Vendor: American Megatrends Inc. (AMI)
Version: R02-A4
Release Date: 10/12/2017

Secure Boot

$ sudo mokutil --sb-state
SecureBoot disabled # (disabled to bypass the error)

DB Certificates (UEFI)

$ sudo mokutil --db | grep -E "Microsoft|2023"
Microsoft UEFI CA 2023 (valid until 2038)
Microsoft Option ROM UEFI CA 2023 (valid until 2038)
Microsoft Windows Production PCA 2011 (valid until 2026-10-19)
Microsoft UEFI CA 2011 (valid until 2026-06-27)

Shim

$ sudo sbverify --list /boot/efi/EFI/Zorin/shimx64.efi
SBAT: shim.ubuntu,1,Ubuntu,shim,15.8-0ubuntu1

Acer Official BIOS Comparison

  Version
  Date
  Size
  Official Changes
  Protected Range 2 Hash
  ME Version




  R02-A4
  10/12/2017
  '-
  Original
  97F7DD5561BCF0CE...
  ?


  R02-B0
  23/01/2018
  6.86 MB
  Fix: Systems hangs up during BIOS POST
  8EA0CDDE7C9BC35E...
  ?


  R02-B1
  07/05/2018
  6.73 MB
  Fix: Intel security-side channel + ME 11.8.50.3460
  F3C92AA91159B4BF...
  11.8.50.3460


  R02-B2
  12/07/2018
  6.73 MB
  Fix: System can't auto detect ODD status
  FD03E67FC19BD0EA...
  11.8.x.x

Key Findings:
AMI v2 Protected Range 2 hash changed in every version transition (A4→B0→B1→B2); its size stayed the same A4→B0, then grew B0→B1 and B1→B2.
Intel ME updated in R02-B1 (to 11.8.50.3460).
SecureBootDXE module itself (the actual Secure Boot validation code) is byte-for-byte identical (SHA-256 match) between A4 and B2 — ruling out a firmware-level fix in this specific module.
Boot Guard is present in all versions, but unchanged (same ACM, Key Manifest, Boot Policy).

QUESTIONS FOR THE COMMUNITY

1. Has anyone with an Acer Aspire GX-781 (or similar Acer model) solved this issue without flashing the BIOS or downgrading the kernel?

• What was the solution?
• Did you use any specific configuration?

2. Has anyone tested kernel 6.8 LTS with BIOS R02-A4 for an extended period?

• Did it work with Secure Boot enabled?
• Did you receive security updates without issues?

3. Does anyone know how to "force" Secure Boot to accept Zorin's shim with kernel 7.x+?

• Specific BIOS settings?
• Tools like mokutil or efi-updatevar?

4. Has anyone removed the Microsoft CA 2023 certificates from db to bypass the issue?

• How did you do it?
• Were there security consequences?
• Did the system continue to work normally?

5. Has anyone used Canonical's shim (shim-signed) instead of Zorin's?

• Did it solve the problem?
• How to install without conflicts?

6. Does anyone have experience with Intel Boot Guard on Acer boards?

• Is Boot Guard active on the GX-781?
• How to check or disable it (if possible)?

7. Does anyone know if Acer has a systemic issue with Secure Boot on Linux?

• Is there official documentation?
• Is there a known bug reported to Acer or Canonical?

8. Has anyone tried contacting Acer or Canonical support about this issue?

• What was the response?

HOW TO REPRODUCE THE ISSUE

1. Enable Secure Boot in BIOS (Acer GX-781, R02-A4).
2. Install Zorin OS 18.1 (or upgrade to kernel 7.x+).
3. Try to boot → Error: "Invalid Signature" or "Invalid Key".
4. Check certificates:

bash

Copiar

sudo mokutil --db
sudo efi-readvar -v db | grep -E "Microsoft|2023"
sudo sbverify --list /boot/efi/EFI/Zorin/shimx64.efi

Look for non-obvious solutions to the Secure Boot issue on Zorin OS 18.1 with Acer Aspire GX-781, beyond kernel downgrade or BIOS flash.

Already ruled out (tested directly, not assumed):

• MOK: Zorin's MOK already existed before any third-party tool was used;
  MOK validation happens after firmware signature check, so it cannot
  cause this specific error.
• Shim file integrity: replaced with a byte-for-byte verified copy
  (SHA-256 + cmp match against the shim-signed package) — still rejected.
• GRUB signature: valid (Canonical Ltd. Secure Boot Signing 2022 v1).
• db structure: verified with efi-readvar -v db — 6 well-formed
  signature lists, correct official GUIDs, no corruption.
• Standard EFI boot entry: created a plain HD()/File() entry pointing
  directly to shimx64.efi (instead of the odd VenHw() entry) — same
  rejection.
• TPM/PCR: not involved in this failure path.
• Key reconstruction attempts (in order): "Custom → Standard" (failed),
  "Install Default Secure Boot Keys" (failed), "Clear Secure Boot Keys"
  (only this restored boot, but left firmware in Setup Mode with
  PK/KEK/db/dbx all empty — not a real fix).
• dbx (revocation list): updated by fwupd from 20230501 to 20260402
  (2026-07-07). No revocation entry found matching the reference shim
  hash. The dbx content prior to the first "Clear Secure Boot Keys"
  was never captured, so a hash-based revocation of the original shim
  cannot be fully ruled out — this remains an open question.

Note: The Aspire GX-781 does not appear on Acer's official supported
models list for the June 2026 Secure Boot certificate update
(community.acer.com/en/kb/articles/18840). Acer's own FAQ states that
firmware "cannot automatically handle or write the larger certificate
files" is a known limitation category for older/EOL systems outside
this program's scope.

• I appreciate any feedback or similar experiences!
• If anyone has solved this issue, please share the solution!
• This thread may help other users with the same problem.

Sorry my English.

[Ponce-De-Leon]

So, You don't want a BIOS Flash and I gues, let Secure Boot disabled is no Solution, too?

I find this interesting:

@Duarte

DB Certificates (UEFI)

$ sudo mokutil --db | grep -E "Microsoft|2023"
Microsoft UEFI CA 2023 (valid until 2038)
Microsoft Option ROM UEFI CA 2023 (valid until 2038)
Microsoft Windows Production PCA 2011 (valid until 2026-10-19)
Microsoft UEFI CA 2011 (valid until 2026-06-27)

The last 2 one's are the older Certificates. Maybe there is an Interference.

[JustZorin]

Hello and welcome in the Forum!

Could you please post the output of more mokutil commands,
so we see really only the valid 2023 secure boot keys?
It looks like the Windows UEFI CA 2023 key is missing but only needed for Windows.

mokutil --db | strings | grep -E 2023

mokutil --kek | strings | grep -E 2023

Additional question: Do you have dual boot with Windows?

[Duarte]

Thank you for pointing this out. I checked the certificate situation more carefully, including the KEK.

My UEFI db currently contains both the older Microsoft certificates and the newer 2023 certificates:

• Microsoft UEFI CA 2023
• Microsoft Option ROM UEFI CA 2023
• Microsoft Windows Production PCA 2011
• Microsoft UEFI CA 2011

So the 2011 and 2023 certificates are indeed present together.

I also checked the KEK:

mokutil --kek | strings | grep -E "Microsoft|2011|2023"

The output shows:

Subject: C=US, ST=Washington, L=Redmond, O=Microsoft Corporation, CN=Microsoft Corporation KEK CA 2011

There was no 2023 match in the KEK output.

However, I don't want to conclude from this alone that the Microsoft 2023 KEK is necessarily missing, because this test only shows what appears in the strings output.

Regarding the possible interference between the 2011 and 2023 certificates: I don't consider this hypothesis ruled out yet. Microsoft documentation indicates that 2011 and 2023 certificates are designed to coexist during the transition, so coexistence itself should not normally be a problem. However, that does not necessarily rule out a firmware-specific implementation issue on an older Acer BIOS such as my R02-A4.

There is also an important detail from my testing: Secure Boot works with kernel 6.17.0-40 on this system, while the 7.x kernels eventually started producing Invalid Key. However, kernel 7.0.0-31 did boot successfully with Secure Boot enabled for several days after it was installed, so I am not assuming that the kernel update itself directly caused the failure.

For now, I consider the 2011/2023 coexistence a possible hypothesis that still needs to be tested, rather than either the cause or something that has been ruled out.

I am trying to understand the behaviour of the original Acer R02-A4 firmware before considering a BIOS flash, since flashing would change the conditions of the investigation.

Thank you for raising this point — it gives me another part of the Secure Boot chain to examine.

[Duarte]

Hello, and thank you for looking into this.

I ran both commands you suggested again, and I also expanded the grep to include both 2011 and 2023 so we could see the Microsoft certificates currently present in both db and KEK.

DB

mokutil --db | strings | grep -E "Microsoft|2011|2023"

Relevant output:

Not Before: Jun 27 21:22:45 2011 GMT
Subject: C=US, ST=Washington, L=Redmond, O=Microsoft Corporation, CN=Microsoft Corporation UEFI CA 2011

Not Before: Oct 19 18:41:42 2011 GMT
Subject: C=US, ST=Washington, L=Redmond, O=Microsoft Corporation, CN=Microsoft Windows Production PCA 2011

Not Before: Jun 13 19:21:47 2023 GMT
Subject: C=US, O=Microsoft Corporation, CN=Microsoft UEFI CA 2023

Not Before: Oct 26 19:02:20 2023 GMT
Subject: C=US, O=Microsoft Corporation, CN=Microsoft Option ROM UEFI CA 2023

So the db contains both the Microsoft 2011 certificates and the 2023 certificates.

KEK

mokutil --kek | strings | grep -E "Microsoft|2011|2023"

Output:

Not Before: Jun 24 20:41:29 2011 GMT
Subject: C=US, ST=Washington, L=Redmond, O=Microsoft Corporation, CN=Microsoft Corporation KEK CA 2011

There was no 2023 match in the KEK output.

Regarding your comment that the Windows UEFI CA 2023 appears to be missing: I don't have that certificate in the db output. The 2023 certificates I do have are:

• Microsoft UEFI CA 2023
• Microsoft Option ROM UEFI CA 2023

So your observation about the Windows UEFI CA 2023 is correct.

As for Windows: there is no Windows installation and this is not a Windows dual-boot system. However, there is still a Windows Boot Manager entry in the motherboard's F12 boot menu. I have already removed it, but the entry comes back again. I have not yet established why it persists.

The system is currently Zorin OS 18.1 only.

A note about the timing of the Secure Boot failure

The chronology is important here.

The APT history shows that kernel 7.0.0-30 was installed on:

Start-Date: 2026-08-21 06:41:37
...
linux-image-7.0.0-30-generic
...
End-Date: 2026-08-21 06:42:10

Kernel 7.0.0-31 was installed later:

Start-Date: 2026-09-04 19:27:25
...
linux-image-7.0.0-31-generic
...
End-Date: 2026-09-04 19:30:52

The journal then shows:

Sep 04 19:24:31 ... kernel: secureboot: Secure boot enabled
Sep 07 13:37:58 ... kernel: secureboot: Secure boot enabled

The September 4 entry occurred three minutes before 7.0.0-31 was installed, so that particular boot was still with 7.0.0-30.

However, the September 7 entry occurred almost three days after 7.0.0-31 had been installed. Therefore, the chronology shows that 7.0.0-31 was able to boot during this period with Secure Boot enabled.

The Invalid Key failure appeared only after September 7. So I am not claiming that installing 7.0.0-31 immediately caused the failure.

The timing of the failure and the 2023 Secure Boot certificate transition are nevertheless interesting, which is why I am investigating whether there could be a firmware/certificate-chain interaction on this older Acer BIOS.

The full chronology and the other Secure Boot tests are documented in the main topic, so I have kept this reply focused on the db/KEK results and the relevant timing.

I hope these additional results help narrow it down.

[swarfendor437]

Hi and welcome.

I had some issues initially when attempting to get rid of Windows 10 on a client's machine that was being stubborn when I was trying to install LMDE 7 on an Acer Aspire.

I managed to get into live mode, launched GParted and I thought had successfully removed Windows 10 - but it was a stubborn brute.

I resolved the issue by running Ventoy once more and Windows asked if I wanted to enrol the Ventoy EFI - once I had done that the installation was plain sailing.

If you have any data present, back it up and try a fresh install with Ventoy USB.

[Side note: I discovered today, that my PCLOS Debian has TPM 2 packages available!

]

[JustZorin]

It is normal to have the 2011 and the 2023 keys in parallel, there is nothing wrong with it. But only the 2023 secure boot keys are valid.
As the 2011 keys have no impact to the Secure Boot Configuration, there is no need to look at them.

When we look at your 2023 secure boot keys, there are two keys missing:

• Windows UEFI CA 2023
  -> not needed as you don't use windows
• Microsoft Corporation KEK 2K CA 2023
  -> would be necessary to get future updates for the dbx database to update the entries for forbidden software
  -> but not the cause for your linux kernel problem

Without Windows and without Microsoft Corporation KEK 2K CA 2023 key there is no really win to have secure boot enabled under Linux Zorin OS.

I would recommend just to disable secure boot and fast boot within your BIOS/UEFI. You can boot into BIOS/UEFI directly via sudo systemctl reboot --firmware

Then follow @swarfendor437 advise to install Zorin OS from the scratch (overrides Windows Boot EFI) with Ventoy for flashing the USB stick to make it bootable.

Create a boot USB Stick with Ventoy under Linux Zorin OS

To flash under Zorin OS an USB Stick you can use Ventoy to make it bootable. To the with Ventoy flashed USB Multibootstick device you can copy and store several ISO/WIM/IMG/VHD(x)/EFI Files, from which you can choose the one needed when you boot from this stick. To download Ventoy choose on URL Download . Ventoy ventoy-1.1.17-linux.tar.gz [image] After download the ventoy-1.1.17-linux.tar.gz Package you unpack it into its folder ventoy-1.1.17 which contains the linux Ventoy program file Ven…

Make sure that your -zorin OS ISO file is clean and copy it to the Ventoy USB stick.

Before starting the new Zorin OS installation backup your data.
During the new Zorin installation choose then:

[Duarte]

Thank you for the suggestions. There is some additional history that may be relevant here, because I had already done several tests with Ventoy before the current Secure Boot investigation.

I was using Ventoy 1.1.17 and tested several systems from the same Ventoy USB.

One of the tests was GhostBSD-26.1-R15.0p2-XFCE.iso, because I wanted to see a Unix/BSD system on this machine. GhostBSD did boot through Ventoy and reached the terminal, although I then had a separate graphical/driver problem involving the GTX 1050/NVIDIA.

I also tested ubuntu-26.04.1-desktop-amd64.iso, partly to see whether Ubuntu might be a possible alternative to my existing Zorin installation. Ubuntu was also started through Ventoy in Normal mode.

So Ventoy itself and the ability to boot other operating systems were already tested successfully. The important detail is what happened afterwards: the Invalid Signature — Check Secure Boot Policy in Setup problem appeared when rebooting and trying to return to the existing Zorin installation. It was not an error that prevented Ventoy from starting those other systems.

There is another detail which may be interesting to people familiar with UEFI/firmware.

The UEFI boot entry for Zorin itself changed during this whole process.

Originally, Boot0000 Zorin OS was a normal UEFI disk/file entry pointing to:

HD(...)/File(\EFI\Zorin\shimx64.efi)

Later, the same Boot0000 Zorin OS entry appeared as:

VenHw(99e275e7-75a0-4b37-a2e6-c5385e6c00cb)

At that point Zorin also disappeared from the firmware F12 boot menu, while Windows Boot Manager remained available.

I don't yet know what caused that change, and I am not claiming that the VenHw() entry is itself the cause of the Secure Boot failure. But it is a concrete change in the UEFI boot configuration that occurred during the investigation and seems relevant.

There is also a separate anomaly in the existing Zorin EFI files.

The shimx64.efi currently present on the ESP is 957,042 bytes, whereas the installed package copy /usr/lib/shim/shimx64.efi.signed.latest is 966,664 bytes. More importantly, the PE Security Directory information in the ESP copy points beyond the physical end of that file, whereas the package copy has a consistent PE structure.

That makes me interested in understanding the existing EFI boot chain before simply replacing it with a fresh installation.

Regarding the Secure Boot 2023 keys, I have also checked this in more detail.

My installed PK is an Acer Platform Key with:

Serial:
54515947FDE650984F16AA4144FE8072

SHA-1:
57B2F689AAA05DDA5FDA8231800DA2FBC90F710C

The current KEK contains the Microsoft Corporation KEK CA 2011, but not the Microsoft Corporation KEK 2K CA 2023.

The DB already contains Microsoft UEFI CA 2023 and Microsoft Option ROM UEFI CA 2023.

I also downloaded the official Acer/Microsoft KEK update packages available from Microsoft's Secure Boot objects repository. The three Acer packages available there validate correctly with Microsoft's own validate_kek.py tool, but they correspond to different Acer Platform Keys, not to my exact PK serial/SHA-1.

Therefore, I agree that the missing Microsoft KEK 2023 is relevant to the wider Secure Boot transition, but I don't yet have evidence that the missing KEK alone explains why this existing Zorin installation is being rejected.

There is also the possibility of flashing/reflashing the latest BIOS/firmware available from Acer for this machine. However, I would regard that as another investigation rather than assuming it will solve the problem. I have not established whether the latest Acer firmware for this model actually implements the required Secure Boot 2023 key transition, or whether it would correctly accept/install the missing 2023 KEK.

In other words, a BIOS update might potentially correct a firmware/UEFI problem, but there is currently no evidence that it would necessarily solve the missing 2023 KEK, the changed VenHw() boot entry, the anomalous EFI shim, or the Invalid Signature error.

For these reasons, before doing a fresh Zorin installation or flashing the BIOS, I would prefer to understand what actually changed in the existing UEFI/Zorin boot chain.

I am posting these details because someone familiar with Acer UEFI firmware, shim/GRUB, Secure Boot variables, or Zorin's boot process may recognise something in this sequence that I have not yet identified.

[swarfendor437]

Thanks for reminding me. Before I got into Ventoy I burned GhostBSD xfce and Plasma versions to DVD. Whilst xfce is usually good for keeping low spec machines going (and I am not detracting from the fact it is faster on modern machines) it needs a minimum of 4 Gb RAM.

[Ponce-De-Leon]

Hmm ... When it is Firmware-related ... There were a bigger Firmware Update what have splittet the Firmware Package that exists in one big Package into several smaller Pieces:

Info about Firmware Split Update

Hello Ladies and Gentlemen! I received today an interesting Update. The linux-firmware what was a complete Package is now spilt into Parts. This is actually not new but new for Zorin 18 with Ubuntu 24.04 Base. As far as I understand it, it is to adress used Hardware more specific. And in Theory with a Firmware Update, You don't need to update the whole linux-firmware Package like before, only the specific adressed Package. You can see it in the Software Updater. There is a whole List of Packag…

@Duarte

I was using Ventoy 1.1.17

Was in Ventoy the Secure Boot Support Option enabled?

[JustZorin]

To disable Secure Boot (and Fast Boot) avoids your described problems.

Please find here more info about Secure Boot under Linux:

UEFI Secure Boot

[Duarte]

Yes. Secure Boot Support was enabled in Ventoy during these tests.

The important test was Ubuntu 26.04.1: it was booted through Ventoy 1.1.17 in Normal Mode and successfully reached the Ubuntu desktop with Secure Boot enabled. So the Acer firmware was able to validate and boot the Ventoy/Ubuntu chain.

I also tested GhostBSD 26.1 XFCE through Ventoy. It booted, but the graphical session had a separate NVIDIA/XLibre compatibility problem with my GTX 1050. That was not a Secure Boot signature rejection.

The Invalid Signature — Check Secure Boot Policy in Setup problem appeared later when rebooting and trying to return to the existing Zorin installation.

This is why I think the distinction is important: Secure Boot was demonstrably capable of validating and booting another OS from the same Ventoy environment, while the existing Zorin boot path was rejected.

Regarding the linux-firmware changes, I had also considered firmware/package changes, but the current error appears to happen before the Zorin kernel starts. The firmware should first validate shim , then shim /GRUB and only afterwards the kernel. So I am currently looking more closely at the UEFI boot entry and the Zorin shim itself.

[scottyPee]

@Duarte

test

I addition to all the testing did you also make sure Secure Boot Key is enrolled in the MOK? See Example Below:

scott@scott-Falcon-Talon:~$ sudo mokutil --test-key /var/lib/shim-signed/mok/MOK.der
[sudo] password for scott:
/var/lib/shim-signed/mok/MOK.der is already enrolled

[Duarte]

I checked this again just now.

There is actually an important distinction in my case.

sudo mokutil --test-key /var/lib/shim-signed/mok/MOK.der

reports:

/var/lib/shim-signed/mok/MOK.der is already in the enrollment request

And sudo mokutil --list-new confirms one pending key:

CN=zorin Secure Boot Module Signature key

with SHA-1:

3c:c8:3d:9d:37:bc:4c:85:61:d6:df:81:9d:91:7b:00:82:f6:8d:bc

However, sudo mokutil --list-enrolled currently returns no entries.

So I would not describe the Zorin MOK as already enrolled. At the moment it is present as a pending enrollment request.

This is also why I currently cannot simply enable Secure Boot and continue testing from the existing Zorin installation: with Secure Boot enabled, the Acer firmware stops before Zorin/GRUB with Invalid Signature — Check Secure Boot Policy in Setup.

Therefore, keeping Secure Boot enabled is not currently a usable option for testing the MOK from inside my Zorin installation. I first need to understand why the firmware is rejecting the existing Zorin boot chain.

sudo mokutil --list-new
[key 1]
SHA1 Fingerprint: 3c:c8:3d:9d:37:bc:4c:85:61:d6:df:81:9d:91:7b:00:82:f6:8d:bc
Certificate:
Data:
Version: 3 (0x2)
Serial Number:
0d:fb:57:10:dd:dc:d7:dd:7a:87:de:c3:a7:44:73:7a:6b:f9:97:79
Signature Algorithm: sha256WithRSAEncryption
Issuer: CN=zorin Secure Boot Module Signature key
Validity
Not Before: May 28 18:49:15 2026 GMT
Not After : May 4 18:49:15 2126 GMT
Subject: CN=zorin Secure Boot Module Signature key
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
Public-Key: (2048 bit)
Modulus:
00:da:51:49:18:0c:50:23:a4:b0:01:6d:46:31:45:
dc:ce:58:a6:92:d9:83:3d:5d:10:59:3f:62:76:dd:
f6:e9:81:f4:c1:db:05:88:b9:79:28:05:20:ef:94:
40:0f:84:e7:41:79:f9:e8:51:7c:95:05:35:45:2f:
71:fb:9a:d5:73:aa:ba:c1:f0:c6:e7:42:0c:86:fe:
f5:df:73:18:c3:6c:ce:20:9e:03:90:53:1a:79:8c:
0a:31:c5:fa:00:23:b1:56:f5:75:f1:84:72:2f:bb:
17:d0:21:16:20:2f:20:4f:1b:1c:86:98:71:f5:7b:
7a:ee:9a:47:98:9f:ad:c5:ad:14:73:e4:f3:aa:99:
49:d4:b5:2e:d3:58:0a:af:44:1c:5c:f8:93:a1:9e:
26:18:9c:2e:94:2b:6d:ca:40:66:67:93:76:58:50:
6d:05:ae:94:60:8c:7b:95:22:d2:09:4f:9c:65:8c:
40:af:0b:36:d1:e3:ae:fa:2c:63:82:e1:58:ef:22:
a1:f7:d1:e6:48:fb:a8:7e:e1:0f:25:4b:07:1a:2b:
0b:f8:82:58:a9:57:92:00:09:2c:29:59:5d:67:ff:
f3:71:61:5a:93:93:ab:b7:98:56:8c:1f:85:cb:6f:
68:a2:e5:14:2f:dd:e8:25:33:ed:21:57:83:b4:85:
24:19
Exponent: 65537 (0x10001)
X509v3 extensions:
X509v3 Subject Key Identifier:
3E:85:7D:C8:E1:55:1A:62:67:33:27:98:8C:F2:AF:EB:9D:CB:40:68
X509v3 Authority Key Identifier:
3E:85:7D:C8:E1:55:1A:62:67:33:27:98:8C:F2:AF:EB:9D:CB:40:68
X509v3 Basic Constraints: critical
CA:FALSE
X509v3 Extended Key Usage:
Code Signing, 1.3.6.1.4.1.2312.16.1.2
Netscape Comment:
OpenSSL Generated Certificate
Signature Algorithm: sha256WithRSAEncryption
Signature Value:
43:22:0f:43:5f:8d:30:20:6c:3d:29:40:28:bb:38:28:57:6a:
d7:9d:95:32:96:f2:90:f1:30:64:4d:bd:ee:86:25:5f:e7:f2:
c3:22:ac:f2:2c:5f:55:5b:2b:f3:78:f5:05:46:38:69:0d:26:
d1:b0:cf:0b:51:f5:a4:60:de:3f:65:1d:df:14:a5:ed:49:f1:
ec:71:54:73:92:e3:58:77:84:d9:01:49:34:a8:65:a6:b3:7c:
1f:51:fb:12:2d:2c:40:82:57:bd:72:be:ba:f5:fd:e8:a9:d5:
57:79:70:cd:44:6d:5f:40:40:45:7c:04:8e:6d:90:f8:e9:b0:
4e:4c:40:f8:c0:4f:13:85:f9:eb:4e:67:5c:27:7e:8d:9e:39:
e9:56:ed:d6:3a:a2:d2:98:1f:8e:4d:55:05:4a:c7:a1:16:60:
ad:e8:c3:28:80:c9:b7:2d:ee:88:70:2e:39:97:32:14:b0:3d:
56:21:66:7e:0e:47:00:a8:26:87:fe:fb:14:1a:10:46:31:d6:
e6:54:5f:5f:a4:f5:87:7b:07:54:e5:f8:69:e1:14:d4:31:df:
a5:25:30:94:84:89:50:77:40:3f:17:82:a7:4d:0c:11:99:fd:
e0:ca:1b:14:c0:9f:73:fe:be:8a:d1:f7:b9:d7:3b:36:16:89:
ab:a3:8b:b1

[scottyPee]

@Duarte

/var/lib/shim-signed/mok/MOK.der is already in the enrollment request

It said /var/lib/shim-signed/mok/MOK.der is already in the enrollment request

It needs to say: /var/lib/shim-signed/mok/MOK.der is already enrolled

Without request...

You need to enroll it with the MOK (a Commodore 64 DOS-ish looking app from the early 90's) during Bootup.

I have some instructions I posted a few months back by watching a Linux Guru on Youtube - his youtube video link is also in the instructions.

Check this out:

[How to] Zorin and Secure Boot

I would also like to add that I needed to turn Secure Boot off in BIOS to install Zorin 18 as having it on crashed during install. After installing Zorin OS 18, I turned Secure Boot Back on. Verified Secure Boot was on with command: mokutil --sb-state Now at this point my Secure boot certificates were not enrolled in the MOK. Perform the following steps after turning secure boot on: 1.) Check if Secure Boot certs are already on computer: ls -lah /var/lib/shim-signed/mok/ ----> Directory li…

[swarfendor437]

That is the screen that I used to replace Windows 10 on client's Acer notebook last year when using Ventoy.

[Duarte]

@scottyPee

(a Commodore 64 DOS-ish looking app from the early 90's) during Bootup

Thanks, ScottyPee. I understand the distinction, and I agree that:

already in the enrollment request

is not the same as:

already enrolled.

That is exactly why I checked both --list-new and --list-enrolled.

In my current state I have:

sudo mokutil --test-key /var/lib/shim-signed/mok/MOK.der

/var/lib/shim-signed/mok/MOK.der is already in the enrollment request

and:

sudo mokutil --list-new

shows the pending:

CN=zorin Secure Boot Module Signature key
SHA1:
3c:c8:3d:9d:37:bc:4c:85:61:d6:df:81:9d:91:7b:00:82:f6:8d:bc

while:

sudo mokutil --list-enrolled

currently returns no entries.

So I agree that the key is pending rather than enrolled.

The difficulty in my particular case is what happens before I can get to the MOK Manager.

During the original Zorin installation, I did see the blue MOK Manager screen and was able to reach that stage of the boot process.

That screen does not appear anymore.

With Secure Boot enabled now, the machine instead stops immediately with:

Invalid Signature
Check Secure Boot Policy in Setup

I never reach GRUB, Zorin, or the MOK Manager.

This is why I am not sure that simply importing the MOK again is the explanation for the current problem. The normal sequence would be:

UEFI → shim → MOK Manager → enroll MOK → continue boot

but my current sequence appears to be:

UEFI → shim/EFI validation → Invalid Signature

So the firmware appears to be rejecting something before the MOK enrollment stage can take place.

There is also some additional history which makes me hesitant to assume that this is simply an unenrolled MOK.

I have already investigated the UEFI variables, PK/KEK/DB/DBX, the Zorin EFI boot entry, and the existing shimx64.efi. Among the things I found:

• the Acer PK currently installed does not correspond to the Acer KEK-update packages available in Microsoft's Secure Boot Objects repository;
• Microsoft KEK CA 2023 is not currently present in my KEK;
• Microsoft UEFI CA 2023 is present in DB;
• the Zorin UEFI boot entry changed from a normal HD(...)/File(\EFI\Zorin\shimx64.efi) entry to a VenHw(...) entry during the investigation;
• and the shimx64.efi currently on my ESP has a different size and PE structure from the signed package copy in /usr/lib/shim/.

I also tested Ventoy 1.1.17 with Secure Boot enabled. Ubuntu 26.04.1 booted successfully through Ventoy in Normal mode and reached the desktop. GhostBSD also booted far enough to reach its terminal, although it had a separate NVIDIA/XLibre graphical problem.

The Invalid Signature problem occurs specifically when returning to the existing Zorin installation.

So I am certainly not dismissing your MOK suggestion. In fact, it confirms another real difference in the current state: the Zorin MOK is pending rather than enrolled.

What I am trying to understand is why I can no longer reach the MOK Manager in the first place.

That seems to be an important distinction between the normal Zorin Secure Boot/MOK procedure you describe and what is happening on this particular Acer system.

If there is a way to force or otherwise reach the MOK Manager without first resolving the firmware's Invalid Signature rejection, I would be interested to know. Otherwise, I think the next question is why the firmware is rejecting the boot chain before MOK Manager is reached.