是否可以减轻最近更改对代码签名过程的影响？

Question

代码签名行业最近采纳了 CAB 论坛关于代码签名的建议。现在私钥只能存储在 CA 提供（或管理）的硬件（USB 密钥）上。

我看到了以下缺点：

• 大多数人会选择使用 CA 存储密钥——这意味着 CA 将持有您的私钥并控制您证书的每个应用程序。
  • 它将知道您签署的每个文件的哈希和以及您签署它的时刻
  • 它将把您的钥匙交给政府
  • 它可以拒绝签名（例如出于政治原因）
  • “所有钥匙放在一个篮子里”问题
  • 您的构建过程需要有效的互联网连接
  • 您的构建过程必须依赖 CA 基础设施才能正常工作
  • CA可以随意强制你升级
  • ...大部分适用于那些选择硬件选项的人（您会得到一个由 CA 控制的黑匣子）
• 我们使用 DigiCert 并被迫更新构建服务器操作系统，因为他们的平台（将哈希和转发到 CA 服务器进行签名的逻辑）最低支持 Windows 10
  • ...他们将来可能会迫使我们升级
  • 升级操作系统会带来很多麻烦——由于较新的次要 VS 版本、库不兼容、无法构建的第 3 方软件包、特定于操作系统的怪癖等而导致构建中断
    • 持续面临被迫升级的威胁会让情况变得更糟

有办法避免这种痛苦吗？

我看到的选项：

1. 不要使用代码签名——很诱人，但在我们的例子中并不是一个真正的选择
2. 找到另一个 CA——显然所有 CA 都采纳了这些建议。如果这不是真的，请告诉我
3. 在我们的环境中创建一个专用服务器并仅将其用于签名（将其合并到构建过程中）。我很想听到关于如何促进这一点的建议。一定会有实用程序......

Answer 1

假设您的私钥由 DigiCert ONE 服务持有，您可以用 Jsign 替换 Signtool 来签署您的二进制文件（免责声明：我是作者）。 Jsign 是跨平台的，可直接将文件的哈希发送到 DigiCert API，因此您不受 DigiCert 客户端工具要求的束缚。

语法如下：

jsign --storetype DIGICERTONE --alias test \
      --storepass "<api-key>|/path/to/Certificate_pkcs12.p12|<password>" application.exe