Yes, but you must have your Secure Boot keys in hand. First, be aware that there are at least three forms that Secure Boot public keys may take:
.cer
/.der
files -- These files are used by most UEFI implementations, as well as by the MokManager tool that's paired with Shim.
.crt
-- These files are used natively by most Linux security tools, such as sbsigntool
and sbverify
.
.esl
-- These files combine multiple keys into one file. (The other files each contain a single key.) If you use a firmware user interface or KeyTool to save your keys, the resulting files will be in this format.
If you've installed your own Machine Owner Key (MOK) using MokManager, you should have the file in .cer
/.der
form. If you want to test whether the binary will work when booted with another key (such as the keys used to sign Ubuntu's or Fedora's version of GRUB), you'll have to obtain it. For convenience, I've collected several with rEFInd; you can download them piecemeal here. If you've taken full control of Secure Boot on your system, you should also already have the keys you created.
To verify a binary, you must have a key in .crt
form. If you've got a key in .der
or .cer
form, you can convert it:
openssl x509 -in mykey.cer -inform der -out mykey.crt
Then, you can check that the binary is properly signed:
sbverify --cert mykey.crt binary.efi
The result should be a message reading Signature verification OK
or Signature verification failed
.
Note that some UEFIs fail to launch even properly-signed binaries. This appears to be random; Binary A will launch OK, whereas Binary B, signed with the same key, fails. I believe this is a bug in the affected UEFIs, but I've not investigated it in detail. AFAIK, it doesn't affect binaries verified via Shim, but it can affect Shim itself or binaries launched without the help of Shim.