代码签名证书有什么特别之处？答案

【问题标题】：What is special about a code signing certificate?代码签名证书有什么特别之处？
【发布时间】：2010-09-17 07:06:09
【问题描述】：

它与我可以通过 makecert 生成或从某个权威机构购买的任何其他证书有什么不同？

【问题讨论】：

标签： code-signing certificate

【解决方案1】：

这取决于你用它做什么。如果您希望证书在 SSL 通信中被浏览器接受，则必须在浏览器中安装根证书。权威机构生成的证书已经在浏览器中安装了根证书。

如果您只是使用证书来签署程序集，那么您就不需要它。这取决于谁在检查证书以及他们是否关心根是否是已知的权威。

【讨论】：

【解决方案2】：

用于签署软件的证书与用于签署任何文档的证书相同。签名软件的不同之处在于签名最终驻留的位置。在典型的文档签名中，签名只是附加到原始文档中。出于显而易见的原因，您不能将签名附加到大多数类型的软件（某些解释语言会允许这样做，但我不知道它是否在实践中完成）。

签名问题的解决方案因执行环境而异。对于可执行二进制文件，签名通常存储在单独的文件中。在 Java 中，您可以在可执行 JAR 文件中嵌入签名。

微软有一个很好的参考introduction to the signing process。

【讨论】：

还要注意文末的社区内容。有一个用于调用 SignTool.exe 的示例批处理文件，包括时间戳选项。
另请注意，在社区内容发布示例命令行代码之前，该页面没有关于 PFX 是什么的参考。

【解决方案3】：

我还要补充一点，必须对 .NET 程序集进行强命名（这需要对其进行签名）才能添加到 GAC。

有不同类型的证书...来自 Win 2003 服务器中捆绑的 CA，您可以请求：

客户端身份验证
电子邮件保护
服务器身份验证
代码签名
时间戳签名
IPSec
其他

【讨论】：

严格来说这不是真的。您可以使用 sn -Vr 将未签名或测试签名的程序集安装到 GAC 中（这将关闭程序集的强名称验证）。

【解决方案4】：

据我所知，证书有一个“密钥使用”属性，描述了证书的用途：SSL 服务器、代码签名、电子邮件签名等。所以我认为这取决于操作系统或网络浏览器或电子邮件客户端来检查这些位。

【讨论】：

【解决方案5】：

当一个证书被调用时，它声称要执行的角色与识别一样重要。这不仅与身份有关，还与角色授权有关。电子邮件保护证书不应执行服务器身份验证。安全问题要求对通过单个证书赋予的权力进行必要的限制。底层 API 应该强制正确使用，无论是通过操作系统还是抽象，例如 .NET Framework。

有不同的证书类型，因为在身份验证和授权中需要它们的角色非常不同。允许不同的证书类型和层次结构允许证书链模型，如证书上的“证书路径”中所示。服务器身份验证证书将需要在受信任的根证书中的某处具有顶级 CA 证书......或者是最终实现的证书家族树的一部分。我敢肯定，第三方证书颁发机构会根据功能和信任度对它们进行定价。

Boot To The Head 是正确的...有一个增强的密钥使用属性，它提供了证书声明角色的描述（例如服务器身份验证；或者在我的情况下） CA 的证书：数字签名、证书签名、离线 CRL 签名、CRL 签名）。查看证书属性中的详细信息即可找到。

【讨论】：

【解决方案6】：

正如 Mile L 和 Boot to the Head 所述，扩展密钥用法决定了密钥的用途。

大多数商业证书颁发机构（Verisign 等）为单一目的或尽可能少地颁发证书。

他们利用这种缩小范围的目的为证书开辟不同的市场，然后对它们进行相应的定价。

当（在大多数情况下）生成的证书相同时，您会看到他们为 Windows 程序集/Java/Office/Adobe Air 等销售不同的对象签名证书。

例如这里发布的Comodo codesigning 证书可以签署Java 小程序、WebStart 应用程序、Firefox 扩展甚至Windows 程序集。

【讨论】：