在 Windows 生态里，“驱动签名”经常被当成一个笼统的动作。真正落地时，团队面对的却是一组不同的问题：驱动要不要送微软做兼容性测试，是否走 Attestation 提交，企业代码签名证书该选什么类型，发布后的驱动如何保持可验证。把这些概念混在一起，容易在申请阶段反复补材料，也会在上架阶段被系统提示拦截。
本文按开发者的实际流程梳理三条常见路径，并说明 EV 代码签名在其中的位置。文中信息用于一般技术说明，微软与 CA 的具体规则可能调整，提交前应以对应平台当期文档和审核要求为准。想了解证书类型与申请材料，可同时参考本站代码签名证书栏目。
一、三个概念分别解决什么问题
WHQL 是 Windows Hardware Quality Labs 的兼容性测试体系，重点在于硬件与驱动在 Windows 平台上的兼容性和稳定性。通过相关测试并完成微软侧签署后，驱动会获得对应的兼容性标识，适合有正式硬件产品、需要进入 Windows Update 分发或强调兼容性背书的企业。
Attestation 提交则面向不进入 WHQL 测试范围的驱动。开发者通过微软合作伙伴平台提交驱动包，由平台完成签署，使驱动能够在启用了强制签名策略的 Windows 系统中加载。它解决的是“能否被系统接受加载”的问题，不等同于兼容性认证。
EV 代码签名证书是 CA 签发的组织验证型代码签名证书，通常用于对驱动、安装包和可执行文件做发布者签名。它解决的是“文件由谁发布、发布后是否被篡改”的问题。三者的目标不同，不能互相替代。
二、不同驱动对应的常见路径
| 驱动类型 | 常见提交方式 | 企业侧准备重点 |
|---|---|---|
| 量产硬件驱动 | WHQL / HLK 测试后提交 | 硬件样品、测试环境、兼容性报告 |
| 非 WHQL 范围的内核驱动 | Attestation 提交 | 微软合作伙伴账号、EV 证书、驱动包规范 |
| 用户态组件、安装包 | 代码签名证书直接签名 | 组织实名材料、时间戳、构建流程 |
很多企业会把“驱动文件签名”和“驱动提交签署”混为一谈。前者是在本地用代码签名证书给 .sys、.cat、安装包签名，后者是把驱动包提交给微软平台完成系统侧签署。实际项目往往两者都要做：先用企业证书确保发布链路完整，再按驱动类型走平台提交。
三、EV 代码签名在流程中的作用
EV 代码签名证书需要完成较严格的组织身份核验，证书私钥通常存放在硬件令牌或符合要求的密钥介质中。对驱动项目来说，它既是发布者身份的证明，也是微软合作伙伴平台组织账号验证中经常被要求的一环。证书上的组织名称应与提交主体、驱动发布者信息保持一致，避免因为主体不一致导致审核退回。
在构建环节，建议把签名放在发布流水线的固定步骤：编译产物校验、版本号写入、签名、时间戳、验签、归档。签名顺序不要随意调整，尤其是安装包内含多个可执行文件时，应先签内部文件，再签外层安装包，否则外层签名可能因内层文件变更而失效。
四、常见卡点与排查方向
- 组织名称不一致：营业执照、英文翻译、微软账号、证书主体四处名称不统一，审核阶段容易被要求补充说明。
- 私钥介质不合规：使用导出型私钥或来源不明的证书，可能无法通过平台校验，也不利于密钥安全。
- 缺少时间戳：证书到期后，没有时间戳的签名会失去可信时间依据，历史版本验签容易出现异常。
- 签名后再次改动文件：任何字节变化都会破坏签名，打包脚本应在签名后禁止二次写入。
- 驱动包结构不完整：缺少 .inf、.cat 或目录结构不符合提交规范，会在平台预检阶段被退回。
遇到签名失败时，先用系统自带工具查看签名链和错误码，再判断是证书链、时间戳、文件被改动还是平台策略问题。不要直接在原包上反复重签，保留未签名产物和日志，便于定位。
五、时间戳与证书生命周期
代码签名证书有明确有效期。为了让已发布的驱动在证书到期后仍可验证，签名时必须添加可信时间戳。时间戳证明“文件在该时间点已经完成签名”，验签工具会结合证书有效期和可信时间判断签名是否有效。没有时间戳的历史版本，在证书过期后可能出现提示异常。
证书续期不是简单换一个新文件。企业需要盘点仍在维护的驱动分支、历史安装包、合作伙伴交付版本，确认哪些需要重新签名，哪些只需保留归档。对长期供货的硬件厂商，建议建立版本台账，将证书序列号、有效期、签名时间和哈希值一并记录。
六、给开发团队的行动清单
- 确认驱动属于 WHQL、Attestation 还是普通用户态组件，分别列出提交要求。
- 核对组织主体、英文名称、地址和联系电话，确保与证书申请材料一致。
- 准备符合要求的密钥介质，规定私钥使用人和审批流程。
- 在 CI 中固定签名与时间戳步骤，签名后执行验签并保存日志。
- 为每个发布版本记录哈希、签名时间、证书序列号和下载渠道。
SSLDUN 自 2017 年起通过合同方式获得 Certum 相关产品授权，可协助企业完成资料预审、中文沟通和续期提醒。证书审核与签发仍由 CA 按当期规则执行，开发团队应预留材料补充和平台审核时间，避免把签名安排压到发布前一刻。
七、常见问题
问：有了 EV 代码签名，是否还需要微软平台签署？
答：两者目的不同。EV 证书证明发布者身份，平台签署解决驱动在 Windows 中的加载与分发要求。是否需要提交，取决于驱动类型和分发方式。
问：Attestation 提交后，本地还需要签名吗？
答：通常需要保留企业侧发布者签名，用于安装包、可执行文件和历史版本验证。具体顺序按平台文档执行。
问：证书到期后旧驱动还能用吗？
答：已在有效期内完成可信时间戳的签名，通常仍可进行历史验证；但新版本必须使用有效证书重新签名。建议在到期前完成续期和版本切换。