首次成功安装 Linux Mint 19.1 Cinnamon 后，我执行了安装后建议执行的步骤。在这里我还升级了我的系统（在检查并安装驱动程序之后）。然而，在升级过程中，弹出以下消息：
您的系统启用了 UEFI 安全启动。 UEFI 安全启动与第三方驱动程序的使用不兼容。系统将帮助您禁用 UEFI 安全启动。为了确保此更改是由您作为授权用户而不是攻击者进行的，您必须选择一个密码，然后在重新启动后使用相同的密码来确认更改。如果您选择继续，但在重新启动时不确认密码，Ubuntu 仍将能够在您的系统上启动，但这些第三方驱动程序将无法用于您的硬件。
然后我设置了 MOK PW 并重新启动了机器，签署了密钥。但是，我真的不知道是什么引发了此消息，以及我在那里签名的密钥。我认为这与我之前安装的第三方 Nvidia 驱动程序有关，因为我昨天将系统回滚到驱动程序安装之后（系统更新之前）。然后我禁用了nvidia显卡（驱动程序所针对的），并且在再次更新系统时，没有弹出提示我签署密钥的消息。
当前签名的密钥之一（我怀疑它可能是）具有以下属性，这听起来很糟糕：
X509v3 Basic Constraints critical
CA: False
总而言之，我的主要问题如下：这一切意味着什么？我实际上对所述密钥进行了哪些签名，这会对我的系统产生任何负面影响吗？我如何找出我最初在那里签名的密钥以及该密钥是否“安全”？
答案1
在 X.509v3 证书术语中，证书扩展可以指定为批判的如果证书的创建者（和/或认证机构）要求验证此证书的人必须了解这个扩展否则视为该证书无效。
“基本约束”扩展是最基本的证书扩展：它确定证书是常规证书（“CA：False”）还是证书颁发机构证书（“CA：True”，具有可选的路径长度值，即此 CA 证书之后的中间 CA 证书的最大允许深度）。
在所有现代系统中，“基本约束”证书扩展应该始终是关键扩展。
所以，这些属性：
X509v3 Basic Constraints: critical
CA: False
用人类的话来说就是：“这是不是CA 证书。如果出现在需要CA证书的情况下，肯定是有人做错了。如果您不理解此限制，则根本不应出于任何目的依赖此证书。”换句话说，这是对任何非 CA 证书的完全正常且预期的扩展。
A非关键如果尝试验证证书的程序无法理解 X.509v3 扩展的含义，则应该可以安全地忽略它。
由于安全启动不能在启动时检查任何证书颁发机构，因此这些属性对安全启动没有任何意义。当安全启动生效时，固件应该验证任何更改现有主密钥 (PK) 或密钥交换密钥 (KEK) 的请求是否都使用与当前 PK 证书对应的私钥进行签名，并且任何更改现有主密钥 (PK) 或密钥交换密钥 (KEK) 的请求是否都已签名。更新现有的白名单 (db)、黑名单 (dbx) 或时间戳 (dbt) 密钥使用与当前 PK 证书或任何当前 KEK 证书对应的私钥进行签名。启动时，加载的任何可执行代码不应与任何黑名单 (dbx) 条目匹配，并且应使用与白名单 (db) 证书之一匹配的密钥进行签名，或者可执行文件的加密哈希应直接包含在白名单中。这些检查完全独立于 X.509 PKI 层次结构。
安全启动密钥证书仍然可以是公司 PKI 层次结构的一部分，以便在必要时可以对证书进行外部验证，此时，X.509v3 证书扩展可能会发挥作用。但对于启动时安全启动检查，任何 X.509v3 证书扩展似乎通常都会被完全忽略。
由于事实证明某些系统固件不允许系统所有者以有用的方式修改安全启动密钥，因此shim.efi开发了引导加载程序。它提供了安全启动的扩展方案：shim.efi由 Microsoft 签名，并且它提供了第二个白名单（MOK，机器所有者密钥），该白名单被合理地强烈保证独立于固件控制，但在与其他安全启动类似的安全条件下启动关键变量。
MOK 注册过程涉及 NVRAM 变量 和shim.efi，因此操作结果为不是存储在可以用或类似的方式回滚的常规文件中timeshift。事实上，看起来适当的 NVRAM 变量是使用仅指定 UEFI 启动服务访问的属性创建的，因此只有shim.efi或另一个 UEFI 启动时工具可以在创建后修改它们......假设固件根据 UEFI 工作并且安全启动标准。