.NET程序集有强名称签名，还需要代码签名证书吗？

2026年10月16日

代码签名证书要不要买，不能只看Visual Studio的“为程序集签名”有没有打勾。这个选项完成的是.NET强名称签名，解决程序集身份问题；软件交到客户手里，要让Windows核验发布企业，则需要安排Authenticode签署。一个DLL既可以保留原有强名称，又带上企业证书签名，不必在两者中二选一。

如果交付清单只写一句“所有文件已签名”，测试人员拿到程序后，还是得回头问开发：做的是强名称，还是企业发布者签名？这句话少写几个字，交接时就多出一轮沟通。把两项任务拆开说清，才能知道项目里的密钥该用在哪儿，以及采购的商业证书到底补上了哪一步。

一、强名称签名，先解决程序集怎么认的问题

程序集是.NET组织代码和元数据的基本单元，常见文件形式包括DLL和EXE。假设你手头有一个组件的两个版本，它们的文件名都是Tools.dll，按名称归档就分不清新旧。强名称会把组件的名称、版本、区域性信息及公钥组合起来，让程序集身份包含这些区分信息。

签署强名称需要一对公私钥，项目可以通过.snk文件提供这份密钥材料。你可以在开发工具中生成密钥对，再交给构建步骤使用，这条路径没有CA审核企业资料的环节。因此，项目成功生成强名称，并不代表某家证书颁发机构已经核实了公司身份。

你在程序集信息里看到的PublicKeyToken，也就是公钥令牌，是从公钥计算得到的简短标识。它用于程序集身份相关的记录，不能拿来证明营业执照审核通过。更要分清：看到公钥令牌，只能说明读到了这项数据，连强名称签名是否有效，都还没有验证。

二、代码签名证书，回答软件是谁发布的

当客户检查Windows软件的发布者时，Authenticode签名才是这里要看的对象。它将文件签名与代码签名证书关联，验证时检查证书信任链、签名覆盖内容的完整性等信息，帮助接收者确认发布者身份。

拿数据采集软件来说，开发人员要检查采集组件有没有引用错版本，客户验收时则要确认安装包上的企业身份。两边都在检查“身份”，检查对象却差了一层。给采集组件加上强名称，并不会自动给安装包补上企业发布者信息。

同一个DLL可以既有强名称签名，也有Authenticode签名。前者围绕程序集身份工作，后者通过证书体系验证签名者。买到EV代码签名证书后，也无需为了“统一身份”，把项目原来的强名称密钥换成商业证书。别把公钥令牌抄进证书指纹的位置，它们标识的对象不同，不能互换着填。

三、运行环境换了，强名称的用途也要重新判断

判断是否需要强名称，先看项目运行在哪里。

老项目如果基于.NET Framework，并且要将组件部署进GAC，也就是全局程序集缓存，强名称就是入库要求。与已有强名称组件配合、处理特定程序集引用关系时，它也有实际用途。接手这样的项目，不能仅凭“现在不流行了”就删掉签名配置。

换成.NET Core或.NET 5及后续版本，运行时加载组件时不会校验强名称签名，程序集绑定也不依赖这套身份。新建一个只面向这些运行时的普通项目，不能因为文件后缀是DLL，就断定必须加上强名称。

不过，组件如果还要供.NET Framework项目使用，就要把这部分兼容需求一起考虑。判断依据应当是调用方和运行环境，不能只看开发电脑安装了哪个版本的SDK。

这些区别也说明了为什么强名称不能当安全防线。它不负责确认软件没有病毒，也不阻止别人反编译代码。项目有了强名称，不等于可以省掉权限控制、依赖审查和安全测试。

四、两种签名都要做，发布顺序怎么安排

对于同时需要两种签名的程序集，可以把流程安排成：完成会修改程序集内容的处理，再完成强名称签署，最后做Authenticode代码签名并验证。

举个具体例子：某个DLL编译后还要混淆，混淆工具会改动文件内容。如果先签名，再把文件送去混淆，前面的签名结果就不能直接作为交付依据。工具若支持处理强名称重签，也要检查最终产物的验证结果，不能只看混淆任务显示“成功”。

到了Authenticode步骤，使用发布主体对应的代码签名证书，为最终DLL或EXE完成签名，并配置时间戳。随后把这些产物放入安装包，安装包本身有发布者验证需求的，再单独签署安装包。里面的DLL签过名，不会让外层安装程序自动获得签名。

开发和发布人员交接时，把两项任务写清楚就行：“程序集强名称已验证”“最终安装包的发布者签名已验证”。仅留下一句“软件签过名了”，下一位接手的人仍然不知道验了什么。

五、怎么检查，才不会把两种结果看反

检查强名称，可以在装有相应工具的Visual Studio开发者命令提示符中使用Sn.exe。先认清下面两条命令的用途，别把显示信息当成验签成功：

sn -T Tools.dll

sn -vf Tools.dll

带大写T的那条只读取公钥令牌，适合查看组件的身份信息；带-vf的那条才会强制执行强名称验证。命令中的Tools.dll是示例文件名，使用时换成实际路径。特别留意大写T：Sn.exe的参数区分大小写，不能随手改写。

检查Authenticode签名，则使用Windows SDK中的SignTool，例如：

signtool verify /pa /v Tools.dll

这条命令按照默认Authenticode验证策略检查签名，并输出详细信息。先看工具是否报错，再看签名中的企业身份是否与交付主体相符，同时保留证书链的验证结果。即使Sn.exe已通过强名称检查，发布者签名仍要单独验；反过来，Authenticode签名验证通过，也不能说明组件引用关系正确。

如果项目报的是程序集加载或引用错误，就沿着依赖、版本、目标框架继续查。如果问题是Windows无法验证发布者，就检查Authenticode签名和证书信任。前一类错误若一直靠重装商业证书来处理，排查方向从一开始就偏了。

六、安信SSL证书两款EV代码签名证书：价格与签名方式

需要给客户交付带企业发布者身份的软件，可以在安信SSL证书申请GlobalSign EV代码签名证书，4000元/年。该方案通过Ukey硬件令牌使用签名私钥，费用包含令牌，国内通过顺丰寄送，申请和安装也有指导。接入.NET发布流程时，把令牌用于最终文件的Authenticode签署，原项目的强名称配置继续负责程序集身份。

如果要把这一步交给云签服务，安信SSL证书还有Certum专业版EV代码签名证书，年费2500元，无需邮寄加密硬件。云签负责给待发布产物加上企业身份签名，强名称任务仍由项目自己的构建流程安排。两份凭据各归各位，发布记录里也要分清两次操作。

两款产品列出的都是年费，购买按年办理。普通.NET桌面程序并不强制使用EV代码签名证书，采购前先确定发布主体和交付要求。组件引用报错则回到项目配置处理，购买更高等级的证书不会修复程序集依赖。