Signatures Invalid after BIOS update, Microsoft Certificate Revoked?

[Skyyblaze]

I followed the guide pretty early on and had no issues however yesterday I had to run a BIOS update on my mainboard and upon reinserting all the keys I still got hit with a Secure Boot Violation because of Invalid Signatures when booting OpenCore afterwards. Looking around I found out that the Microsoft Certificate was apparently revoked:

https://github.com/ValdikSS/Super-UEFIinSecureBoot-Disk/issues/15

Was this already reflected in the guide, is there an updated certificate?

[perez987]

@Skyyblaze I haven't used UEFI Secure Boot with OpenCore in a while and I didn't know that the 2011 Microsoft certificate was revoked and it is not possible to do this task as I wrote in the guide.

I have been looking for information and, although I am sure you already know it, there are some newer certificates. I suppose that with them this issue is resolved. I have to test it before changing the guide text.

If you haven't tried it yet, the links to the active certificates are those in point 2 or 3, depending on what operating systems you boot, I think that the ones in point 2 are enough for Windows and macOS with OpenCore:

---

1.- Microsoft KEKs enable signature database updates and binary execution.

• https://go.microsoft.com/fwlink/?LinkId=321185
• https://go.microsoft.com/fwlink/?linkid=2239775

2.- Microsoft certificates to verify binaries before execution.

• https://go.microsoft.com/fwlink/p/?linkid=321192
• https://go.microsoft.com/fwlink/?linkid=2239776

3.- Source: Microsoft Secure Boot Objects GitHub

---

I leave this open while we check if these changes are enough before updating the guide. If you prefer to make a Pull Request and propose the required changes, that would be fine with me. Thanks for your warning.

[Skyyblaze]

@perez987 Thanks for looking into this! To be honest without your guide I would be very confused about the signing process anyhow so I'm actually not sure how to proceed even though you shared the links.

I'm assuming these two files from the original files need to be updated:

Microsoft Windows Production CA 2011 Microsoft UEFI driver signing CA key

however I'm unsure which of the links you posted correctly correspond to these files. If you could guide me into the right direction I would try the guide with the new files and then report back if it works.

[perez987]

@Skyyblaze I’m out of home, I’ll answer later but for now notice that only one of the certificates has been updated (it has 2023 in the name), the other one remains unchanged (2011 in the name). If you get the 2 files of the point number 2, you’ll get both certificates, updated and unchanged. These are the ones you need to try.

[Skyyblaze]

@perez987 Alright I also won't be able to test things before the weekend but if I got you right then I have to re-follow the guide but instead of the 2011 Certificate I have to use: windows uefi ca 2023.crt, correct?

[perez987]

@Skyyblaze Yes, you are right.

So far, we were using 2 certificates, both dated 2011:

• MicCorUEFCA2011_2011-06-27.crt
• MicWinProPCA2011_2011-10-19.crt

if you download the 2 items of 2.- Microsoft certificates to verify binaries before execution you'll get 2 certificates:

• MicWinProPCA2011_2011-10-19.crt -> this has not changed
• windows uefi ca 2023.crt -> this has been updated and replaces MicCorUEFCA2011_2011-06-27.crtused before.

Are both certificates required or only the new windows uefi ca 2023.crt? Not sure, I guess that both are required. Remember that I haven't tried it yet but I think this is the fix.

[Skyyblaze]

@perez987

Alright thank you, I might be able to test things until Monday evening but when I do I'll report back!

[perez987]

@Skyyblaze Be careful because I have done the test with the updated certificate and now I have locked down the UEFI secure boot keys, I can boot macOS with UEFI Secure Boot disabled but, if I enable it, the motherboard does not pass the post phase and is stuck without access to BIOS.

In order to boot I had to completely erase the main BIOS and boot from the backup BIOS.

Now I can boot macOS and Windows with Secure Boot disabled but I have not been able to reset the secure keys to factory settings. Secure Variable is Locked Down or Security Violation warning is displayed.

I probably did something wrong. I downloaded the 2 certificates, the one from 2011 that has not been updated and the one from 2023, and generated the keys with both. I was able to put the keys (PK, KEK and db) in the firmware but after that I couldn't go back.

So you know, be careful if you try it.

[Skyyblaze]

@perez987

Alright thanks for the warning, I didn't have time to test things yet but I think I'll refrain for now then until this is better figured out.

[perez987]

@Skyyblaze Installing the updated Microsoft certificate into the UEFI firmware is pretty easy if you have Windows.

1. Open PowerShell as administrator
2. Run Set-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Control\SecureBoot" -Name "AvailableUpdates" -Value 0x40
3. Run Start-ScheduledTask -TaskName “\Microsoft\Windows\PI\Secure-Boot-Update”
4. Reboot
5. Check [System.Text.Encoding]::ASCII.GetString((Get-SecureBootUEFI db).bytes) -match ‘Windows UEFI CA 2023’
6. It must return True.

Microsoft firmware certificates are:

• Microsoft Corporation KEK CA 2011 stored in the KEK database
• two certificates stored in the DB:
  • Microsoft Windows Production PCA 2011, which signs the Windows bootloader
  • Microsoft UEFI CA 2011 (or third-party UEFI CA), which signs third-party OS and hardware driver components.

All three of these Microsoft certificates expire in 2026. Microsoft will be rolling out Secure Boot database updates in phases to add trust for the new DB and KEK certificates. The first DB update has added the Microsoft Windows UEFI CA 2023 to the system DB.

Next task is to resign OpenCore files having the new certificate. Here is where I failed. I'll comment if I find the way to do it.

[Skyyblaze]

@perez987 Alright, thanks for looking into it! I'll also comment if I find anything out.

[perez987]

@Skyyblaze Although I haven't gotten this to work yet with the 2023 certificate, I've gone back and reconfigured UEFI Secure Boot following the instructions in README.md. That is, as we have done previously:

• tested with the latest 2 BIOS for Z390 Aorus Elite (F10 and F11)
• default secure keys (Reset Secure Boot Keys)
• OpenCore 1.0.0
• modified script to make the task more user friendly (see below, sign.sh)
• personal keys shoved into firmware
• signed OpenCore efi files.

And I have been successful, by activating UEFI Secure Boot I can boot Windows 11, OpenCore 1.0.0 (-> macOS Ventura) and Ubuntu 24.04.

So now I have the question of what happens with the update 2023 certificate and the obsolete 2011 certificate because I have not installed the new one and everything seems to have worked fine. However, each new attempt to do the same with the new certificate leads to a BIOS lock (secure variables locked down or booting from backup BIOS to reset main BIOS).

The script can be run by this Linux command in Terminal sh ./sign.sh 1.0.0.

#!/bin/bash
#Copyrigth (c) 2021 by profzei
#Licensed under the terms of the GPL v3

# Linux command in Terminal
 # sh ./sign.sh 1.0.0

sudo apt update && sudo apt upgrade

if ! command -v unzip &> /dev/null
then
    echo "Installing unzip..."
    sudo apt install unzip
fi

if ! command -v sbsign &> /dev/null
then
    echo "Installing sbsigntool..."
    sudo apt-get install sbsigntool
fi

if ! command -v cert-to-efi-sig-list &> /dev/null
then
    echo "Installing efitools..."
    sudo apt-get install efitools
fi

VERSION=$1

echo "=============================="
echo "Creating efikeys folder"
mkdir efikeys
cd efikeys
openssl req -new -x509 -newkey rsa:2048 -sha256 -days 3650 -nodes -subj "/CN=KEYS PK/" -keyout PK.key -out PK.pem
openssl req -new -x509 -newkey rsa:2048 -sha256 -days 3650 -nodes -subj "/CN=KEYS KEK/" -keyout KEK.key -out KEK.pem
openssl req -new -x509 -newkey rsa:2048 -sha256 -days 3650 -nodes -subj "/CN=KEYS ISK/" -keyout ISK.key -out ISK.pem
chmod 0600 *.key

echo "============================="
echo "Downloading Microsoft certificates..."
wget --user-agent="Mozilla" https://www.microsoft.com/pkiops/certs/MicWinProPCA2011_2011-10-19.crt
wget --user-agent="Mozilla" https://www.microsoft.com/pkiops/certs/MicCorUEFCA2011_2011-06-27.crt

echo "============================="
echo "Signing certificates..."
openssl x509 -in MicWinProPCA2011_2011-10-19.crt -inform DER -out MicWinProPCA2011_2011-10-19.pem -outform PEM
openssl x509 -in MicCorUEFCA2011_2011-06-27.crt -inform DER -out MicCorUEFCA2011_2011-06-27.pem -outform PEM

echo "============================="
echo "Converting PEM to ESL..."
cert-to-efi-sig-list -g $(uuidgen) PK.pem PK.esl
cert-to-efi-sig-list -g $(uuidgen) KEK.pem KEK.esl
cert-to-efi-sig-list -g $(uuidgen) ISK.pem ISK.esl
cert-to-efi-sig-list -g $(uuidgen) MicWinProPCA2011_2011-10-19.pem MicWinProPCA2011_2011-10-19.esl
cert-to-efi-sig-list -g $(uuidgen) MicCorUEFCA2011_2011-06-27.pem MicCorUEFCA2011_2011-06-27.esl

echo "============================="
echo "Creating database of allowed signs..."
cat ISK.esl MicWinProPCA2011_2011-10-19.esl MicCorUEFCA2011_2011-06-27.esl > db.esl

echo "============================="
echo "Signing ESL files..."
sign-efi-sig-list -k PK.key -c PK.pem PK PK.esl PK.auth
sign-efi-sig-list -k PK.key -c PK.pem KEK KEK.esl KEK.auth
sign-efi-sig-list -k KEK.key -c KEK.pem db db.esl db.auth

cd ..
mkdir oc
cp efikeys/ISK.key oc
cp efikeys/ISK.pem oc
cp efikeys/PK.auth oc
cp efikeys/KEK.auth oc
cp efikeys/db.auth oc
cd oc

echo "============================="
echo "Creating required directories"
mkdir Signed
mkdir Signed/EFI
mkdir Signed/EFI/BOOT
mkdir Signed/EFI/OC
mkdir Signed/EFI/OC/Drivers
mkdir Signed/EFI/OC/Tools
mkdir Signed/Download

echo "============================="
#LINK="https://github.com/acidanthera/OpenCorePkg/releases/download/${VERSION}/OpenCore-${VERSION}-RELEASE.zip"
LINK="https://github.com/acidanthera/OpenCorePkg/releases/download/1.0.0/OpenCore-1.0.0-RELEASE.zip"
echo "Downlading Opencore ${VERSION}"
wget -nv $LINK

echo "============================="
echo "Downloading HfsPlus.efi"
wget -nv https://github.com/acidanthera/OcBinaryData/raw/master/Drivers/HfsPlus.efi -O ./Signed/Download/HfsPlus.efi
echo "============================="
echo "Do you use OpenLinuxBoot? (Y/N)"
read LUKA
LUKA1="Y"
LUKA2="y"
if [ "$LUKA" = "$LUKA1" ] || [ "$LUKA" = "$LUKA2" ]; then
    wget -nv https://github.com/acidanthera/OcBinaryData/raw/master/Drivers/ext4_x64.efi -O ./Signed/Download/ext4_x64.efi  
fi

echo "============================="
echo "Unzipping OpenCore ${VERSION}"
unzip "OpenCore-${VERSION}-RELEASE.zip" "X64/*" -d "./Signed/Download"
rm "OpenCore-${VERSION}-RELEASE.zip"
echo "============================"
echo "Signing drivers, tools, BOOTx64.efi and OpenCore.efi"
echo ""
sbsign --key ISK.key --cert ISK.pem --output ./Signed/EFI/BOOT/BOOTx64.efi ./Signed/Download/X64/EFI/BOOT/BOOTx64.efi
sbsign --key ISK.key --cert ISK.pem --output ./Signed/EFI/OC/OpenCore.efi ./Signed/Download/X64/EFI/OC/OpenCore.efi
sbsign --key ISK.key --cert ISK.pem --output ./Signed/EFI/OC/Drivers/OpenRuntime.efi ./Signed/Download/X64/EFI/OC/Drivers/OpenRuntime.efi
sbsign --key ISK.key --cert ISK.pem --output ./Signed/EFI/OC/Drivers/OpenCanopy.efi ./Signed/Download/X64/EFI/OC/Drivers/OpenCanopy.efi
sbsign --key ISK.key --cert ISK.pem --output ./Signed/EFI/OC/Drivers/CrScreenshotDxe.efi ./Signed/Download/X64/EFI/OC/Drivers/CrScreenshotDxe.efi
sbsign --key ISK.key --cert ISK.pem --output ./Signed/EFI/OC/Tools/OpenShell.efi ./Signed/Download/X64/EFI/OC/Tools/OpenShell.efi
sbsign --key ISK.key --cert ISK.pem --output ./Signed/EFI/OC/Drivers/HfsPlus.efi ./Signed/Download/HfsPlus.efi
sbsign --key ISK.key --cert ISK.pem --output ./Signed/EFI/OC/Drivers/AudioDxe.efi ./Signed/Download/X64/EFI/OC/Drivers/AudioDxe.efi

if [ "$LUKA" = "$LUKA1" ] || [ "$LUKA" = "$LUKA2" ]; then
    sbsign --key ISK.key --cert ISK.pem --output ./Signed/EFI/OC/Drivers/OpenLinuxBoot.efi ./Signed/Download/X64/EFI/OC/Drivers/OpenLinuxBoot.efi
    sbsign --key ISK.key --cert ISK.pem --output ./Signed/EFI/OC/Drivers/ext4_x64.efi ./Signed/Download/ext4_x64.efi
    echo "Linux drivers signed"
else
    rm ./Signed/Download/X64/EFI/OC/Drivers/OpenLinuxBoot.efi
fi

echo "============================"
echo "====CREATED BY LUKAKEITON==="
echo "============================"

[Skyyblaze]

@perez987 Hmm I assume you aren't using a current BIOS so your UEFI doesn't know that the old certificate was revoked yet?

[perez987]

@Skyyblaze F10 and F11 are the latest non beta bios available for my mobo. Maybe Gigabyte has not updated this feature yet for this model.

[perez987]

@Skyyblaze Added Microsoft 2023 updated certificate into UEFI secure variables (KEK and db). Not replacing any variable but appending to the existing (the ones I made yesterday on Ubuntu to sign Opencore files).

1. KEK details after adding 2023 key:

KEYS KEK is my own KEK generated by the linux script. KEK CA 2011 is the default Microsoft KEK. KEK 2K CA 2023 is the appended Microsoft KEK.

2. db details after adding 2023 key:

KEYS ISK is my own variable generated by the linux script. PCA 2011 and UEFI CA 2011 are the default Microsoft variables. UEF CA 2023 is the appended Microsoft variable.

Windows 11 and signed OpenCore boot fine after enabling Secure Boot. The same as before adding 2023 keys.

Tried with BIOS F11 (latest) and F10.

[Skyyblaze]

@perez987 I see interesting, so the important part is to Append the keys and not Replace them?

[tonho911]

@perez987 There is a small script error like in sh ./sign.sh 1.0.0. Can you please check again and correct it? thx

Unzipping OpenCore
unzip: cannot find or open OpenCore--RELEASE.zip, OpenCore--RELEASE.zip.zip or OpenCore--RELEASE.zip.ZIP.
rm: cannot remove 'OpenCore--RELEASE.zip': No such file or directory

Signing drivers, tools, BOOTx64.efi and OpenCore.efi
Error reading file ./Signed/Download/X64/EFI/BOOT/BOOTx64.efi: No such file or directory
Error reading file ./Signed/Download/X64/EFI/OC/OpenCore.efi: No such file or directory
Error reading file ./Signed/Download/X64/EFI/OC/Drivers/OpenRuntime.efi: No such file or directory
Error reading file ./Signed/Download/X64/EFI/OC/Drivers/OpenCanopy.efi: No such file or directory
Error reading file ./Signed/Download/X64/EFI/OC/Drivers/CrScreenshotDxe.efi: No such file or directory
Error reading file ./Signed/Download/X64/EFI/OC/Tools/OpenShell.efi: No such file or directory
warning: data remaining[37888 vs 37892]: gaps between PE/COFF sections?
warning: data remaining[37888 vs 37896]: gaps between PE/COFF sections?
Signing Unsigned original image
Error reading file ./Signed/Download/X64/EFI/OC/Drivers/AudioDxe.efi: No such file or directory
Error reading file ./Signed/Download/X64/EFI/OC/Drivers/OpenLinuxBoot.efi: No such file or directory
Image was already signed; adding additional signature
image_write/open: No such file or directory
Linux drivers signed
====CREATED BY LUKAKEITON===

[perez987]

@tonho911 I'm out of home, I'll review later. Are you running the script by doing sh ./sign.sh 1.0.0 in the script folder?

[tonho911]

@perez987 Yes, I did it as in the example, but sorry I deleted the first comment because the writing was too big (directly copied from MobaXtrem)

[perez987]

@Skyyblaze At the moment, I don't know what modifications to make to the guide. Until now:

1. Microsoft has updated one of its certificates but, by enabling UEFI Secure Boot, Windows 11 and OpenCore (secure keys signed) boot fine with the default BIOS keys (which only contain Microsoft certificates from 2011)
2. If I add the 2023 Microsoft certificate to the secure BIOS keys: Windows 11 and OpenCore also boot fine with UEFI Secure Boot enabled.

Microsoft offers updated files to be shoved into the firmware from the BIOS menu, they are those in the attached file Microsoft-2023.zip but, if you replace your BIOS keys with these from Microsoft, OpenCore (digitally signed) does not boot (as expected) since BIOS does not contain our custom keys that we have created from Linux.

In short, on my motherboard the guide works fine as is, even without adding the updated Microsoft certificate. So I don't know how to approach this issue.

Note: when I shove my own keys into the firmware, with PK I have to use Update since there must only be one key but with KEK and db (or dbx if I also want to update it) I use Append, this way I don't delete the existing keys but rather that I add the new ones (they can coexist).

Microsoft-2023.zip

[perez987]

@tonho911 You are right, there is a typo related to the Linux drivers.

Now:

if [ "$LUKA" = "$LUKA1" ] || [ "$LUKA" = "$LUKA2" ]; then
    sbsign --key ISK.key --cert ISK.pem --output ./Signed/Drivers/OpenLinuxBoot.efi ./Signed/Download/X64/EFI/OC/Drivers/OpenLinuxBoot.efi
    sbsign --key ISK.key --cert ISK.pem --output ./Signed/Drivers/ext4_x64.efi ./Signed/Download/ext4_x64.efi
    echo "Linux drivers signed"
else
    rm ./Signed/Download/X64/EFI/OC/Drivers/OpenLinuxBoot.efi
fi

Fixed:

if [ "$LUKA" = "$LUKA1" ] || [ "$LUKA" = "$LUKA2" ]; then
    sbsign --key ISK.key --cert ISK.pem --output ./Signed/EFI/OC/Drivers/OpenLinuxBoot.efi ./Signed/Download/X64/EFI/OC/Drivers/OpenLinuxBoot.efi
    sbsign --key ISK.key --cert ISK.pem --output ./Signed/EFI/OC/Drivers/ext4_x64.efi ./Signed/Download/ext4_x64.efi
    echo "Linux drivers signed"
else
    rm ./Signed/Download/X64/EFI/OC/Drivers/OpenLinuxBoot.efi
fi

--output ./Signed/Drivers/ must be replaced by --output ./Signed/EFI/OC/Drivers/

Try and comment if you have success.

[Skyyblaze]

@perez987 Hmm I see, now I'm really unsure what to do as my BIOS clearly doesn't like th old key anymore but I also don't want to mess too many things up.

[tonho911]

@tonho911 You are right, there is a typo related to the Linux drivers.

Now:

if [ "$LUKA" = "$LUKA1" ] || [ "$LUKA" = "$LUKA2" ]; then
  sbsign --key ISK.key --cert ISK.pem --output ./Signed/Drivers/OpenLinuxBoot.efi ./Signed/Download/X64/EFI/OC/Drivers/OpenLinuxBoot.efi
  sbsign --key ISK.key --cert ISK.pem --output ./Signed/Drivers/ext4_x64.efi ./Signed/Download/ext4_x64.efi
  echo "Linux drivers signed"
else
  rm ./Signed/Download/X64/EFI/OC/Drivers/OpenLinuxBoot.efi
fi

Fixed:

if [ "$LUKA" = "$LUKA1" ] || [ "$LUKA" = "$LUKA2" ]; then
  sbsign --key ISK.key --cert ISK.pem --output ./Signed/EFI/OC/Drivers/OpenLinuxBoot.efi ./Signed/Download/X64/EFI/OC/Drivers/OpenLinuxBoot.efi
  sbsign --key ISK.key --cert ISK.pem --output ./Signed/EFI/OC/Drivers/ext4_x64.efi ./Signed/Download/ext4_x64.efi
  echo "Linux drivers signed"
else
  rm ./Signed/Download/X64/EFI/OC/Drivers/OpenLinuxBoot.efi
fi

--output ./Signed/Drivers/ must be replaced by --output ./Signed/EFI/OC/Drivers/

Try and comment if you have success.

U have to be kidding bro, it works, thanks...

[tonho911]

@perez987 Hmm I see, now I'm really unsure what to do as my BIOS clearly doesn't like th old key anymore but I also don't want to mess too many things up.

What brand of motherboard are you using? If it's a gigabyte, be careful if you want to change the keys in secureboot, because I've made bootloops for 3pcs gigabyte motherboards, and the solution is to flash the bios with the bin file in the original version. But not with MSI, Asrock, even if you enter the wrong key, it's also safe, whether it's someone else's or you found it on the web, it's still safe, just reset it, it's back to the beginning, but not gigabytes.

I'm confused about the function of backup bios or dual bios which the brand is always proud of.

[Skyyblaze]

@tonho911 Ah that might explain things as I am using a Gigabyte mainboard. They are a brand that never let me down in the past 15 or so years but I also never had to utilize the DualBIOS feature so I don't know how it works.

[tonho911]

@Skyyblaze I've tried it on almost all brands of motherboards, especially PCs, and what you need to pay attention to is Gigabyte, just CSM Compt Enable can create a bootloop if you've already entered the keys and enabled SecureBoot. Even though on other brands (H110 and above) there's no CSM Enable Disable option, if UEFI mode is on, CSM is definitely disabled. For Gigabyte, I also experienced a case like yours, sir, where I couldn't enter the keys. There are only a few ways I can do it. Firstly, maybe you can create a special EFI partition (ESP) and enter the keys there, secondly, flash the BIOS again. which makes him read it from the beginning again, thirdly, play the bios foot jumper pin but be very careful because this is when the battery is installed, if it's wrong it will short circuit and that's the end of it

[Skyyblaze]

@tonho911 Interesting, I never had any trouble with Gigabyte boards while MSI has always been troublesome for me but for different reasons. Well I'll play around with it and see what I can do.

[perez987]

@Skyyblaze @tonho911

I am restructuring the entire site to make it more useful to the user. I have separated it into sections.

If something you read seems incomplete or you want to contribute or comment on anything, I would appreciate it.

This does not solve the original question of @Skyyblaze but I cannot reproduce the issue with the certificate on my system.

What I do see frequently are the Security violation or Try again after system reboot or Secure variables are locked down errors. Sometimes I have even had a BIOS lock and it has been difficult for me to recover it to continue working.

All of this is included in the guide.

[perez987]

@Skyyblaze Have you read the new guide The easy way (no Linux nor Windows needed)? Easier than ever and no worries about Microsoft certificates.

[Skyyblaze]

@perez987 Huh thanks for the heads-up, this sounds very interesting and easy indeed. I'll try it when I have time!

[y2kPArt9]

@Skyyblaze Have you read the new guide The easy way (no Linux nor Windows needed)? Easier than ever and no worries about Microsoft certificates.

It’s work bro