Pre-submission testing for UEFI submissions

1 Introduction

This post provides guidance on how to test sign and verify UEFI modules before submitting them for signature by Microsoft UEFI CA. Before using the Windows Dev Center hardware dashboard to sign a UEFI driver or app, you should test sign your UEFI driver or app and verify it, following the guidelines provided here. Doing this helps you determine up front if your UEFI driver or app is signable and whether it works after being signed.

Doing QA on your product before having it signed by Microsoft UEFI CA reduces the likelihood of repeated submissions and so helps the Windows Dev Center hardware dashboard provide good turnaround time for signing, as each submission requires significant review resources from the dashboard.

Note: Don’t submit test signed UEFI modules to the dashboard. Submitted modules that are signed will fail.

2 Test sign and verify UEFI modules

Follow these steps to use and test your UEFI product before getting it signed by Microsoft UEFI CA:

1. Sign your product with your certificate (or a test certificate).
2. Add this certificate to the SecureBoot database.

3 Using Windows HCK to test sign and verify UEFI modules

You can use Windows HCK on a device running Windows by following these steps:

1. Prepare the test system.

2. Test sign the UEFI modules.

3. Install the “Lost” test certificate into the secure boot allow database.

4. Verify that test signed UEFI modules load and run successfully.

3.1 Prepare the test system

To install test certificates, including the “Lost CA,” onto a UEFI secure boot system to prepare it to test UEFI modules that are test signed, follow these steps:

1. Procure a UEFI secure boot–capable system for testing. The firmware should comply with UEFI 2.3.1 Errata C or higher.

2. In the BIOS configuration, enable secure boot custom mode and clear all secure boot keys and certificates. Note that some firmware ignores authentication of certain image paths, such as option ROMs. This should be re-enabled if you’re testing these image paths.

3. Uncompress to a USB drive. (This file is attached to this blog post.) If you have the Hardware Certification Kit installed, this file is also located at C:\Program Files (x86)\Windows Kits \8.0\Hardware Certification Kit\Tests\amd64\secureboot\

4. On the test system, boot to Windows, start Powershell as administrator, and execute Set-ExecutionPolicy Bypass –force.

5. Execute ManualTests\tests\00-EnableSecureBoot\EnableSecureBoot.ps1 and reboot the system. This enables secure boot with a test KEK that will be used later to install the “Lost” test key into database.

3.2 Test sign the UEFI modules

Follow the example at ManualTests\generate\TestCerts\Lost\signApps.bat to learn how to sign UEFI modules using the Lost certificate chain:

  • You’ll need to set your system clock back to 1/1/2012 to sign using the Lost certificate C:\WINDOWS\system32>date 1-1-12.
  • You might need to import the Lost*.cer into your certificate store. To do this, in File Explorer, go to ManualTests\generate\TestCerts\Lost\, right-click each .cer file, and click Install.
  • Get signtool.exe, which is available as a part of the Windows SDK.
  • Run signtool.exe sign /fd sha256 /a /f “ManualTests\generate\TestCerts\Lost\Lost.pfx” <your_module.efi>.

We recommend that you use a computer running Windows 8 or Windows 8.1 for signing. If the system used is running Windows Vista or a previous Windows operating system, you’ll need to run signtool.exe from the SDK directory where it is installed. On these versions of the operating system, signtool.exe depends on manifests and DLLs in that SDK directory for the /fd option to function properly.

Verify that secure boot is enabled: After you complete the steps in “Prepare the Test System” above, secure boot should be enabled, but the lost key isn’t yet installed into the database. If you try to load the test-signed UEFI driver or app, it should be blocked from execution. Some BIOS systems display a warning message, others fail silently. If execution is blocked, secure boot is correctly enabled for your module load path. If the test-signed UEFI module runs, secure boot is not correctly enabled.

3.3 Install the lost test certificate into the secure boot allow database

Open PowerShell as Administrator and run the following command:



This adds the “Lost” test certificate chain to the allow database. You can verify that the system is properly configured by trying to run the UEFI test modules in the HCK (for example, ManualTests\apps\<ARCH>\pressanykey1.efi) via a UEFI shell. It should display the test name and prompt you to press any key on the keyboard.

3.4 Verify that test-signed UEFI modules load & execute successfully

After the secure boot system is configured to trust the test certificates and the UEFI modules to be tested are signed by the test certificates, you are ready to begin testing. Install the UEFI modules, reboot, and determine if the modules load and execute successfully. You can test UEFI drivers for hardware either by installing them into your option ROM or via the DRIVER#### UEFI variables.

4 Using other tools

Here are a few links that might be helpful:

Sourceforge – SecurityPkg

Signing UEFI Applications and Drivers for UEFI Secure Boot

However, you have to clear secure boot in the BIOS, and then you have to either boot to Linux to run Linux tools, or you have to use SHIM with MokManager UI (which allows you to set the databases if the system is in SetupMode).

5 Troubleshooting

You can self-sign a UEFI shell by following the steps in section 3.2 above and use it to help troubleshoot problems in your EFI drivers/applications.

  1. Go to the Files folder on the EDK II SourceForge project site:
  2. Look for and download the newest folder with “Releases” in the folder name
  3. The precompiled EFI shells are located under EdkShellBinPkg. You can use this to print errors to UEFI shell and debug your applications.

Comments (5)

  1. Sathya says:

    Thanks for putting this together, will try the steps and revert back

  2. Eric D. says:

    Is this still valid?  The first half of step 3.1.3 does not result in "C:Program Files (x86)Windows Kits 8.0Hardware Certification" being created.  

  3. Certification team says:

    Eric D, I have attached the zip file to this post and modified the step above. Thanks for your feedback!

  4. liusirjiayou says:

    Thanks for this post.  Now I'm trying 3.3.5, but still get errors. can't figure out reasons or solutions.

    PS D:ManualTeststests0-EnableSecureBoot> .EnableSecureBoot.ps1

    Setting self-signed Test PK…

    Set-SecureBootUEFI : 身份验证数据不正确: 0xC0000022

    所在位置 D:ManualTeststests0-EnableSecureBootEnableSecureBoot.ps1:7 字符: 1

    + Set-SecureBootUEFI -Time 2011-05-21T13:30:00Z -ContentFilePath PK_SigList.bin -S …

    + ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

       + CategoryInfo          : PermissionDenied: (Microsoft.Secur…BootUefiCommand:SetSecureBootUefiCommand) [Set-Secu

      reBootUEFI], UnauthorizedAccessException

       + FullyQualifiedErrorId : SetFWVarFailed,Microsoft.SecureBoot.Commands.SetSecureBootUefiCommand

    Setting PK-signed Fabrikam KEK…

    Set-SecureBootUEFI : 身份验证数据不正确: 0xC0000022

    所在位置 D:ManualTeststests0-EnableSecureBootEnableSecureBoot.ps1:11 字符: 1

    + Set-SecureBootUEFI -Time 2011-05-21T13:30:00Z  -ContentFilePath Fabrikam_Test_KE …

    + ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

       + CategoryInfo          : PermissionDenied: (Microsoft.Secur…BootUefiCommand:SetSecureBootUefiCommand) [Set-Secu

      reBootUEFI], UnauthorizedAccessException

       + FullyQualifiedErrorId : SetFWVarFailed,Microsoft.SecureBoot.Commands.SetSecureBootUefiCommand

    Setting db to Microsoft Production & Test 2010 certificates…

    Set-SecureBootUEFI : 身份验证数据不正确: 0xC0000022

    所在位置 D:ManualTeststests0-EnableSecureBootEnableSecureBoot.ps1:15 字符: 1

    + Set-SecureBootUEFI -Time 2011-05-21T13:30:00Z  -ContentFilePath signing_signatur …

    + ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

       + CategoryInfo          : PermissionDenied: (Microsoft.Secur…BootUefiCommand:SetSecureBootUefiCommand) [Set-Secu

      reBootUEFI], UnauthorizedAccessException

       + FullyQualifiedErrorId : SetFWVarFailed,Microsoft.SecureBoot.Commands.SetSecureBootUefiCommand

    … operation complete.

    SetupMode should now be 0 and SecureBoot should also be 0. Reboot and verify that Windows is correctly authenticated, an

    d that SecureBoot changes to 1.

    PS D:ManualTeststests0-EnableSecureBoot>

  5. JJ Cox says:


    Error  0xC0000022 indicates that the test precondition was not completed.  You must clear or delete all Secure Boot keys prior to executing this script.

    JJ Cox [MSFT]