很多软件团队在开发阶段进展顺利，到了发布环节却被签名问题拖住：证书还没下来、安装包签完又被覆盖、用户下载后仍提示未知发布者、旧版本证书到期无法验签。代码签名不是单个动作，而是一条贯穿申请、构建、发布和续期的流程。把它提前纳入发布计划，能减少临时返工。
本文给出一套适用于桌面软件、驱动程序、脚本和安装包的规划框架。不同产品的签名要求并不相同，涉及平台政策时应以对应平台当期规则为准。证书类型和申请材料可参考本站代码签名证书栏目，产品信息以代码签名证书页面为准。
一、先确定证书类型，而不是先比价格
代码签名证书常见分为组织验证型（OV）和扩展验证型（EV）。OV 证书完成企业或组织身份核验，适合常规软件安装包、脚本和更新程序签名。EV 证书的核验更严格，通常要求硬件密钥介质，在微软合作伙伴平台、驱动提交和部分高信任场景中使用较多。
选择时先回答三个问题：发布对象是谁，是否涉及内核驱动或平台白名单，私钥由谁保管。面向普通用户的工具软件，OV 往往已经满足基本发布者身份展示；涉及驱动、平台账号验证或客户明确要求 EV 的项目，则应优先确认 EV 的申请条件和交付周期。
二、把实名材料准备放在项目排期里
证书申请不是付款后立即签发。组织名称、注册地址、联系电话、经办人身份、营业执照或登记文件都需要核验，部分场景还会进行电话回访或补充材料。跨境主体可能涉及翻译件、公证文件或额外的地址证明。建议在计划发布日前预留至少两到三周，遇到材料补正再顺延。
材料准备的核心是“一致性”：营业执照名称、英文翻译、网站主体信息、软件发布者名称、发票抬头应能互相对应。若企业近期做过名称变更，提前准备变更证明，避免审核时出现主体断裂。经办人应熟悉企业基本信息，能够接听核验电话。
三、签名顺序要与构建流程绑定
一个安装包往往包含主程序、动态库、服务、脚本和卸载程序。合理的顺序是先签所有需要独立验证的内部文件，再签安装包外层。若先签外层再修改内部文件，外层签名会失效；若只签外层，内部文件在解包后仍可能显示未知发布者。
建议把签名步骤写成流水线任务：构建完成后生成哈希清单，按清单逐个签名，统一添加时间戳，随后执行验签。验签不通过就阻断发布，而不是把问题留给用户。签名日志、证书序列号、时间戳服务和产物哈希应一起归档，方便后续追溯。
四、时间戳不是可选项
证书有效期有限，签名时间戳用于证明文件在某个可信时间点已经完成签名。没有时间戳的文件，在证书到期后可能无法通过历史验证。对需要长期下载、长期维护或客户留存的软件，时间戳尤其重要。
时间戳服务也可能出现网络异常。构建脚本应设置重试和超时，并在失败时明确报错，不能生成一个“看似签名成功但没有时间戳”的产物。发布前抽查历史版本，确认签名链、时间戳和文件哈希均可验证。
五、版本迭代中的证书管理
- 建立证书台账：记录颁发者、主体、序列号、有效期、密钥介质编号和保管人。
- 区分“重新签名”和“重新打包”：仅换证书时，确认文件内容未变化，避免无意引入新差异。
- 保留历史证书和已发布产物：客户验证旧版本时需要完整签名链。
- 设置续期提醒：在到期前完成新证书申请、测试签名和发布切换。
- 限制私钥使用：签名操作留痕，离职或交接时回收介质并更新权限。
续期阶段容易出现的风险是“新证书主体信息变化”。如果企业名称、地址或英文翻译发生调整，新签名与旧版本可能显示不同发布者。应提前和客户沟通，并在更新说明中解释主体变更原因。
六、发布前的检查清单
- 确认证书类型与产品要求匹配，EV 项目已准备合规密钥介质。
- 核对组织名称、地址、电话、网站与申请材料一致。
- 构建流水线已包含签名、时间戳、验签和归档步骤。
- 安装包内部文件与外层文件均完成签名。
- 在干净系统上安装、升级、卸载，观察发布者提示。
- 记录版本号、签名时间、证书序列号与哈希值。
- 安排证书续期和旧版本维护计划。
SSLDUN 在 Certum 相关产品的服务中，可协助企业做材料预审、中文沟通和续期提醒。需要说明的是，证书审核与签发由 CA 按其规则完成，任何服务方都不能替代 CA 的审核结论。把流程做扎实，比在发布前临时寻找捷径更可靠。
七、常见问题
问：开发测试阶段也需要正式证书吗？
答：测试可以使用测试签名或内部证书，但发布产物必须使用正式证书。测试证书不要流入公开下载渠道。
问：签名后修改版本信息会怎样？
答：文件字节发生变化，原签名失效。版本信息应在签名前写入，签名后只做只读校验。
问：OV 证书能否用于驱动提交？
答：是否接受取决于平台当期要求。涉及驱动和合作伙伴平台时，先确认 EV 要求，避免申请错类型。