代码签名证书申请后能给驱动程序签名吗

能不能给驱动程序签名，完全取决于你申请的是哪一类代码签名证书。普通OV代码签名证书不能用于Windows内核模式驱动签名；必须持有EV（扩展验证）代码签名证书，才有资格进入驱动签名与WHQL认证流程。但还有一个容易被忽略的事实：EV证书的作用是完成“身份注册”和“提交预签名”，最终让Windows系统无条件信任的那份签名，由微软在审核通过后加盖。

一、普通证书与EV代码签名证书的分界线

代码签名证书按验证等级分为OV和EV两类。OV代码签名证书解决的是“这个软件是谁发的”，适用于普通.exe、.msi等桌面应用程序；EV代码签名证书在OV基础上执行更严格的企业实体核验，并且私钥必须存放在硬件或合规云端安全模块中，不可导出。

这条分界线在驱动场景中是硬性的。Windows 10（1607版本）起，64位系统强制要求内核模式驱动具备有效签名才能加载；而能够满足这一要求的证书类型，只有EV代码签名证书。普通OV代码签名证书签出来的驱动，系统会直接拦截，连“未知发布者”的警告都不会给。更关键的是，微软硬件开发中心在注册账户和提交驱动时，明确将EV代码签名证书列为唯一接受的证书类型，标准代码签名证书不在受理范围内。

二、EV证书在驱动签名中的真实角色

很多开发者以为拿到EV代码签名证书、用signtool签完.sys文件，驱动就能正常加载了。这在早期或许可行，但2026年的规则已经完全不同。

当前的标准路径是：EV代码签名证书签名→注册微软硬件开发者账户→用EV证书对驱动提交包进行预签名→提交微软硬件仪表板审核→微软加盖最终签名。你用自己的EV代码签名证书签的那一次，作用是向微软证明“提交者身份真实、文件未被篡改”；微软审核通过后，会重新生成目录文件（.cat）并嵌入微软自己的签名，这才是Windows系统最终信任的根。

2026年4月，微软进一步关闭了旧版交叉签名根证书的信任通道，内核驱动签名的标准路径被统一到硬件开发中心，未通过Windows硬件兼容性计划认证的驱动将默认不被加载。这意味着“自己拿证书签完就直接分发”的旧做法，在内核驱动场景中已经彻底失效。

三、内核驱动必须走完“EV+WHQL”两步

对于内核模式驱动程序，仅有EV代码签名证书还不够。EV签名解决的是“有资格提交”，WHQL认证解决的是“微软确认你的驱动兼容、稳定、可信任”。没有WHQL，驱动即使能安装，也会在用户端留下安全警告，并且无法通过Windows Update分发；有了WHQL，驱动才能获得微软官方签名，在系统加载时无警告、无拦截。

在选型上，安信证书的定位比较清晰：它本身不签发证书，而是作为Certum、GlobalSign等CA的授权渠道，提供从选型咨询、材料预审到签名部署的一站式服务。安信证书官网上的报价显示，Certum EV代码签名证书约2500元/年，支持内核驱动签名和WHQL认证，且采用云签名方式，私钥托管在合规云端安全模块中，无需等待硬件UKey邮寄，对需要频繁提交和续签的驱动开发团队来说，操作节奏更紧凑。如果项目对品牌背书有更高要求，GlobalSign EV代码签名证书（约4000元/年）是另一个常见选择。

代码签名证书申请之前，先确认一件事：你的驱动是普通应用层组件，还是需要进入Windows内核？如果只是安装包附带的可执行文件，OV代码签名证书足够；一旦涉及.sys文件、硬件驱动或需要通过Windows Update分发，EV代码签名证书是绕不开的入场条件，WHQL则是内核驱动走向“无警告加载”的必经环节。把证书类型选对，只是第一步；把EV签名嵌入微软的提交与审核链条，才是驱动真正可用的前提。

常见问题（FAQ）

Q1：我已经有OV代码签名证书，能不能补差价换成EV来进行驱动数字签名？

不能直接“换”。OV和EV是两类验证等级不同的证书，需要重新向CA提交EV代码签名证书申请并完成扩展验证流程。已有的OV代码签名证书可以继续用于普通应用程序签名，两者并行使用是常见做法。

Q2：EV代码签名证书用云签名、没有UKey，微软硬件开发中心认可吗？

认可。微软审核的是证书本身的EV资质和CA的合规性，并不限定私钥的物理形态。Certum的云签名方案私钥存放在合规云端HSM中，安全等级对标硬件令牌，注册硬件开发者账户和提交驱动预签名均可正常完成。

Q3：驱动签名时为什么一定要加时间戳？不加会怎样？

不加时间戳的签名，在证书到期的那一刻就会失效，已经分发出去的驱动会失去信任。加上可信时间戳后，签名的时间点被固定下来，即使证书后续过期或被吊销，此前已签名的驱动文件仍然有效。使用signtool签名时应始终添加RFC3161时间戳参数。