它是否与我通过makecert生成的任何其他证书不同或从某个权威机构购买？
答案 0 :(得分：5)
如 Mile L 和引导到头部所述，扩展密钥用法决定了密钥的用途。
大多数商业证书颁发机构（Verisign等）为单一目的或尽可能少的证书颁发证书。
他们利用这种缩小的范围来开辟不同的证书市场，然后相应地定价。
当（在大多数情况下）结果证书相同时，您会看到他们为Windows程序集/ Java / Office / Adobe Air等销售不同的对象签名证书。
例如，此处发布的Comodo codesigning证书可以签署Java小程序，WebStart应用程序，Firefox扩展甚至Windows程序集。
答案 1 :(得分：3)
用于签署软件的证书与用于签署任何文档的证书相同。签名软件的不同之处在于签名最终所在的位置。在典型的文档签名中，签名只会附加到原始文档中。出于显而易见的原因，您不能将签名附加到大多数类型的软件上（某些解释性语言会允许这样做，但我不知道它是否在实践中完成）。
签名问题的解决方案因执行环境而异。对于可执行二进制文件，签名通常存储在单独的文件中。在Java中，您可以在可执行的JAR文件中嵌入签名。
Microsoft对introduction to the signing process提供了很好的参考。
答案 2 :(得分：2)
这取决于你正在做什么。如果您希望SSL通信中的浏览器接受证书，则必须在浏览器中安装根证书。当局生成的证书已经在浏览器中安装了根证书。
如果您仅使用证书来签署程序集，那么您不需要它。这取决于谁在检查证书，以及他们是否关心根是否是已知权威。
更多信息：
答案 3 :(得分：2)
据我所知，证书具有“密钥用法”属性，用于描述证书的用途：SSL服务器，代码签名，电子邮件签名等。所以我认为这取决于操作系统或Web浏览器或电子邮件客户端，以检查这些位。
答案 4 :(得分：2)
当证书被激活时，它声称要执行的角色与识别一样重要。它不仅涉及身份，还涉及角色授权。电子邮件保护证书不应该能够执行服务器身份验证。安全问题决定了通过单一证书给予的权力的必要限制。底层API应该强制执行正确的用法，无论是通过操作系统还是抽象（如.NET Framework）。
存在不同的证书类型，因为在身份验证和授权中存在非常不同的角色。允许不同的证书类型和层次结构允许证书链模型，如证书上的“证书路径”中所示。服务器身份验证证书需要在受信任的根证书中的某个位置具有顶级CA证书...或者最终成为证书系列树的一部分。第三方证书颁发机构，我敢肯定，在功能和信任的范围内对它们进行定价。
引导到头是正确的...有一个增强型密钥用法属性，它提供了证书所声称角色的描述（例如服务器身份验证;或者对于我的情况） CA的证书：数字签名，证书签名，离线CRL签名，CRL签名）。查看证书属性中的详细信息，您将找到它。
答案 5 :(得分：1)
我还要补充说，必须强烈命名.NET程序集（需要对其进行签名）才能添加到GAC中。
有不同类型的证书...来自CA捆绑在Win 2003服务器中，您可以请求：