Place under this directory any additional PEM-encoded (.crt) certificates
that you want to be included in the finalized new secure boot databases, which
will be generated by the create-databases.sh.
Any additional Key Exchange Key (KEK) certificates go under the kek/
subdirectory, and any additional Authorized Signature (db) certificates go
under the db/ subdirectory. It is important that you put the certificates in
the correct subdirectory. See the top-level README.md file for
more information about this. Note that the create-databases.sh searches the
two aforementioned subdirectories recursively, and ignores any files without a
.crt file extension.
Note also that as of the latest commit, it is now possible to define a fixed
GUID for each certificate. If you know which GUID belongs to your certificate,
you can put it on a single line in the file named <mycert>.crt.guid. You need
not panic if you don't know the GUID though - if the .crt.guid file does not
exist, then create-databases.sh will auto-generate a random GUID for it.
It's important to note that owner GUIDs serve an informational purpose only.
The UEFI firmware itself does not care what GUID is used for each certificate,
but it is a suggested convention to used predefined GUIDs for certain vendors.
For example, Microsoft's GUID is 77fa9abd-0359-4d32-bd60-28f4e78f784b.
Under the top-level directory of this repository, there is a folder named
extracerts.DEFAULT/. This contains some commonly desired certificates for
both KEK and db, which you may or may not want to include in your databases.
To start, you can copy this entire directory over by running the following
command (from the top-level directory of this repository):
cp -r extracerts.DEFAULT/{db,kek} extracerts/By default, this default set contains the Microsoft certificates for both KEK and db. If these are undesired, you can remove some or all of them. In particular, removing the Microsoft KEK certificates will prevent Microsoft from supplying and automatically installing dbx updates on your machine. Keeping the Microsoft KEK certificates will, on the other hand, allow both you and Microsoft to provide dbx updates. The distinction is explained in more detail in the top-level README.md file. In any case, we strongly recommend keeping at least the Microsoft db certificates, as they will be required for booting Windows and some Microsoft-signed GNU/Linux distributions.
NOTE: The certificate named "Microsoft Windows Production PCA 2011" was
revoked by Microsoft due to the BlackLotus bootkit vulnerability. It was
supposed to be replaced by the "Windows UEFI CA 2023" certificate. However
Microsoft has yet to replace the bootloaders in any Windows ISOs with ones
signed by their 2023 certificate. Even the latest Windows 11 ISO, which at the
time of writing is 25H2, still contains a Windows bootloader signed by the
revoked 2011 certificate. Microsoft has begun rolling out updates to existing
Windows installations that replaces their bootloader(s) with 2023-signed
versions. However we do not recommend removing the 2011 certificate at this
time. The extracerts.DEFAULT/ directory contains both the 2011 and 2023
certificates, with the aim of maximizing compatibility. Microsoft may soon
supply a dbx update which fully revokes the Windows 2011 certificate (by
blacklisting it) anyway. Note that the third-party MS 2011 certificate used
to sign Linux shims is unaffected. You can disregard everything written in this
paragraph if it made no sense to you. Microsoft is the one crapping their pants
right now, you don't need to yourself. By including the MS 2023 certs out of
the box, the scripts in this repository are actually filling in the gaps made
by Microsoft automatically!
As of the latest commit to this repository, there is also a directory called
extracerts.OPTIONAL/. Similar to extracerts.DEFAULT/ its contents can be
copied over to the extracerts/ directory if desired, but the difference is
that these certificates are actually not required and may not even be desired
by some users. At the time of writing, it contains the db certificate for
MassOS GNU/Linux, which is useful to use if you intend to
use MassOS, but is no longer essential, since MassOS now supports running under
a Microsoft-signed shim, and you can simply import the MassOS certificate into
shim's MokList database instead (which actually doesn't require taking control
of secure boot in the first place).
Some third party certificates may be distributed in the DER binary format,
instead of the default PEM format. Such certificates will instead use the
extension .cer or .der. You can use the OpenSSL command-line utility to
convert a DER certificate to a PEM one (replace example with the
actual name of the file):
openssl x509 -in example.der -inform DER -out example.crt -outform PEM
You may also wish to add OEM certificates for your device, which can be dumped
from your main system using the dump-existing.sh script, though this is only
required if some utility or function that is built-in to the firmware is signed
by such key. If this is not the case, you don't need OEM keys (and you probably
don't need to dump in the first place either, since most firmwares have a
"Restore Factory Keys" option). All dumped certs (including redundant Microsoft
ones) will be placed in dumped/ALL/KEK/crt and dumped/ALL/db/crt for KEK
and db respectively. The certificates which were detected to be OEM ones will
be placed in dumped/oem-crt/kek and dumped/oem-crt/db. Therefore, it is now
extrremely easy to copy those over to extracerts, and you can do so with the
following command:
cp -r dumped/oem-crt/{db,kek} extracerts/
Here is an image showing the setup for an example system, with annotations to help explain it:
