我碰巧翻译了他写的这篇文章 詹姆斯·波托姆利，技术顾问 Linux基金会，他们开始放在一起 预引导程序，以便您可以引导Linux.
正如我在上一篇文章中所解释的，我们已经准备好Linux Foundation预引导程序的代码。 但是，有一个 延迟 而我们可以访问Microsoft签名系统。
首先要做的是 支付99美元给Verisign （现为Symantec）并具有Verisign验证的密钥。 我们是为Linux Foundation做的，他们要做的就是致电总部进行验证。 密钥返回浏览器中安装的URL，但是可以使用标准的Linux SSL工具提取它并创建通常的PEM证书和密钥。 它与UEFI签名无关，但用于验证系统 系统开发人员 微软，你就是你所说的。 在创建sysdev帐户之前，必须对其进行测试 签署他们给您的可执行文件并上传。 他们对您在特定的Windows平台上进行签名提出了严格的要求，但请至少对其进行签名，然后创建我们的帐户Bingo。
创建帐户后，您仍然需要先上传UEFI二进制文件进行签名 签订纸质合同。 协议非常繁重，包括许多排除的许可证（包括用于驱动程序的所有GPL，但不适用于引导程序）。 最麻烦的部分是协议似乎已经达成 超出您签署的UEFI对象。 Linux Foundation的律师得出结论，它对LF基本上无害，因为我们不出售产品，但对其他公司则可能令人恶心。 根据Matthew Garrett的说法，Microsoft愿意与发行版进行特殊交易的谈判，以缓解其中的一些问题。
协议签署后， 技术乐趣。 您不能只上传UEFI二进制文件并对其进行签名。 首先你必须 将其包装为.cab文件。 幸运的是，有一个开源项目可以创建名为lcab的内阁文件。 那你必须 使用Verisign密钥对.cab文件进行签名。 同样，还有另一个开源项目可以做到这一点：osslsigncode。 对于需要这些工具的任何人，都可以在我的openSuse Build Service UEFI存储库中找到它们。 最终的问题是上传文件 需要Silverlight。 不幸的是，月光似乎不起作用，即使使用版本4预览，上传框也变为空白，因此 是时候使用Windows 7了 在kvm（基于内核的虚拟机）下。 在谈到这一部分时，您还必须证明二进制文件“将被签名， 不得根据GPLv3或类似的开源许可证获得许可”。 我以为是因为担心密钥公开，但根本不清楚（与“类似的开源许可证”相同）。
上传完成后，内阁文件将停止七个阶段。 不幸的是，第一次测试攀爬一直没有 锁定在第六阶段 （文件签名）。 6天后，我向Microsoft发送了一封支持电子邮件，询问发生了什么事。 答案是：“签名过程抛出的错误代码是： 您的文件不是有效的Win32应用程序。 它是有效的Win32应用程序吗？”。 答：显然不是，它是有效的64位UEFI二进制文件。 没有更多答案了...
我再次尝试。 这次，我收到了签名文件的下载电子邮件，董事会说 签名失败。 我下载并验证。 二进制文件可在secureboot平台上运行，并用密钥签名
主题= / C =美国/ ST =华盛顿/ L =雷德蒙德/ O = Microsoft Corporation / OU = MOPR / CN = Microsoft Windows UEFI Driver Publisher
发行人= / C =美国/ ST =华盛顿/ L =雷德蒙德/ O =微软公司/ CN =微软公司UEFI CA 2011我询问支持人员，为什么该过程指示失败，但是我进行了有效下载，并且在收到一堆电子邮件后，他们回答“请勿使用该文件。 签名错误。 我会回到你身边。” 我仍然不确定是什么问题，但是如果您查看签名密钥的主题， 密钥中没有任何内容可以指示Linux Foundation，因此我怀疑问题在于二进制文件是用通用Microsoft密钥而不是与Linux Foundation绑定的特定（可撤销）密钥签名的。
但是，状态是：我们将继续等待Microsoft向Linux Foundation提供经过签名并经过验证的预引导程序。 发生这种情况时，它将被上传到Linux Foundation站点供所有人使用。
数据来源： http://blog.hansenpartnership.com/adventures-in-microsoft-uefi-signing/
得出您的结论，但这将需要时间。