Windows驱动开发：自签名证书原理与实战，解决驱动强制签名问题

1. 项目概述：为什么我们需要自签名驱动程序？

如果你在Windows上开发过硬件驱动、虚拟设备或者一些需要深入系统底层的软件，大概率遇到过那个令人头疼的黄色感叹号。设备管理器里，你的硬件旁边赫然写着“Windows 无法验证此设备所需的驱动程序的数字签名”。在Windows Vista之后的64位系统上，特别是开启了安全启动（Secure Boot）的Windows 10/11，驱动强制签名策略（Driver Signature Enforcement）就像一道铁闸，没有微软认证签名的驱动根本无法加载。对于个人开发者、测试工程师或者企业内部开发来说，动辄数百甚至上千美元的EV代码签名证书，以及漫长的微软WHQL认证流程，在开发调试阶段既不现实也无必要。这时，“自签名”就成了打通这堵墙的唯一钥匙。

自签名驱动，顾名思义，就是自己给自己颁发的“通行证”。它不依赖微软或受信任的第三方证书颁发机构（CA），而是由开发者自己生成一个根证书，并用这个根证书为驱动程序文件（.sys, .cat, .inf等）进行签名。然后，我们将这个自生成的根证书手动安装到目标测试机器的“受信任的根证书颁发机构”存储区，告诉系统：“相信我，这个证书是我发的，用它签名的驱动都是安全的”。这样一来，系统就会允许加载你签名的驱动。这个过程听起来有点“自己给自己盖章”的意味，但在封闭的开发和测试环境中，它是完全合法、高效且成本为零的解决方案。本文将手把手带你走通从证书创建、驱动签名到系统信任的完整流程，并分享我踩过的那些坑和独家技巧。

2. 核心工具链与原理拆解

在动手之前，我们必须理解参与这个流程的几个核心角色和它们之间的关系。这不是一个简单的“点一下按钮”的操作，知其然更要知其所以然，才能在未来遇到各种诡异问题时游刃有余。

2.1 数字签名与证书链的底层逻辑

驱动签名本质上是数字签名技术在软件分发领域的应用。其核心目的是 完整性验证 和 身份认证 。

1. 完整性验证 ：确保驱动文件从签名后到安装前，没有被任何人（包括病毒或传输错误）篡改。这是通过哈希算法实现的。
2. 身份认证 ：告诉系统这个驱动是谁发布的。即使驱动完好无损，系统也需要知道它是否来自一个可信的来源。

这个过程依赖一个信任链：

• 根证书（Root Certificate） ：信任的起点。它是一对自生成的、长期有效的非对称加密密钥（公钥和私钥）。私钥必须绝对保密，公钥则随证书分发。我们将根证书安装到系统的“受信任的根证书颁发机构”，就等于告诉系统：“凡是用这个根证书下属密钥签名的东西，我都认。”
• 代码签名证书（Code Signing Certificate） ：在实际商业签名中，我们通常不会直接用根证书签名，因为根证书太宝贵了。我们会用根证书签发一个专门用于代码签名的“子证书”。在自签名场景下，为了简化，我们常常直接使用一个“自签名的代码签名证书”，它自己既是颁发者也是使用者。但从原理上，你可以理解为它就是我们的“签名工具”。
• 驱动文件签名 ：用代码签名证书的私钥，对驱动文件计算出的哈希值进行加密，生成签名块，并将签名块和证书本身一起嵌入到驱动文件（或单独的.cat文件中）。系统验证时，用证书中的公钥解密签名，得到原始哈希值，再与当前文件计算出的哈希值对比。一致则通过完整性验证；同时检查证书链是否最终追溯到一个受信任的根证书，通过则完成身份认证。

2.2 核心工具：Windows SDK 与 PowerShell

微软提供了一套完整的工具链来完成这些操作，主要包含在 Windows SDK 和系统自带的 PowerShell 中。

• MakeCert.exe (已弃用但仍有参考价值) ：旧版SDK中的证书创建工具。虽然微软推荐使用更强大的 New-SelfSignedCertificate PowerShell cmdlet，但很多老旧教程仍在使用它。了解它有助于理解参数含义。
• Signtool.exe ：签名工具的核心。它位于Windows SDK的 bin 目录下，负责实际执行签名操作。我们需要用它来为 .sys 、 .dll 、 .exe 或 .cat 文件添加数字签名。
• Inf2Cat.exe ：驱动程序开发中的关键工具。驱动程序包通常包含一个 .inf 安装信息文件。 Inf2Cat 会验证 .inf 文件的语法，并根据其中指定的目标操作系统版本，生成一个目录文件（ .cat ）。这个 .cat 文件才是最终需要被签名的对象，它包含了驱动包内所有文件的哈希列表。
• PowerShell (New-SelfSignedCertificate) ：这是现代Windows中创建自签名证书的首选方式。它功能强大，可以直接在系统中创建证书并存储到指定的证书存储区，无需生成额外的 .pfx 或 .cer 文件（当然也可以导出）。

注意 ：对于纯粹的驱动签名，我们主要与 Signtool 和证书打交道。 Inf2Cat 是在你从源代码构建驱动包时才需要的。如果你拿到的是一个已经编译好的 .sys 文件，可能只需要直接签名 .sys ；但如果是一个完整的驱动安装包（包含 .inf ），则通常需要签名 .cat 文件。

2.3 证书存储区：系统的“信任名单”

Windows的证书管理器（ certmgr.msc ）将证书分类存放在不同的逻辑存储区，理解它们至关重要：

• 个人（My） ：存放你拥有的、带有私钥的证书。我们自签名的代码签名证书（带私钥）通常先放在这里。
• 受信任的根证书颁发机构（Trusted Root Certification Authorities） ：这是系统的“终极信任名单”。任何证书只要其根证书在此列表中，该证书签名的内容就会被信任。 我们的自签名根证书最终必须安装到这里（对于测试机器）。
• 中间证书颁发机构（Intermediate Certification Authorities） ：在复杂的商业证书链中，这里存放的是由根证书签发的中介证书。自签名场景下一般不涉及。

核心流程概括 ：在开发机上创建证书并签名驱动 -> 将证书（不含私钥）导出为 .cer 文件 -> 在测试机上将 .cer 文件导入“受信任的根证书颁发机构” -> 安装驱动。

3. 详细实操流程：从零到驱动加载成功

下面我将以在Windows 11开发/测试环境为例，演示最常用的两种自签名流程。请确保你已安装最新版本的Windows SDK和对应的Windows驱动程序工具包（WDK），或者至少安装了Visual Studio（它通常包含这些工具）。

3.1 方法一：使用PowerShell创建证书并签名（推荐）

这是目前最简洁、最“原生”的方法，完全在PowerShell环境中完成。

步骤1：以管理员身份启动PowerShell 右键点击开始菜单，选择“Windows PowerShell (管理员)”或“终端 (管理员)”。所有证书操作都需要管理员权限。

步骤2：创建自签名根证书和代码签名证书 我们将创建一个专用于代码签名的证书。在PowerShell中执行以下命令：

# 创建一个新的自签名证书，用于代码签名，并存储在“个人”存储区
$cert = New-SelfSignedCertificate `
    -Subject "CN=MyDevelopmentRootCA" ` # 证书主题，CN是通用名，可自定义
    -KeyUsageProperty Sign ` # 密钥用途：签名
    -KeyUsage DigitalSignature ` # 密钥用法：数字签名
    -KeyAlgorithm RSA ` # 密钥算法：RSA
    -KeyLength 2048 ` # 密钥长度：2048位，安全且兼容性好
    -HashAlgorithm SHA256 ` # 哈希算法：SHA256，必须使用SHA256或以上
    -CertStoreLocation "Cert:\LocalMachine\My" ` # 存储位置：本地计算机的个人存储
    -Type CodeSigningCert # 证书类型：代码签名证书

# 将证书同时添加到“受信任的根证书颁发机构”（仅限开发机！）
$rootStore = New-Object System.Security.Cryptography.X509Certificates.X509Store("Root", "LocalMachine")
$rootStore.Open("ReadWrite")
$rootStore.Add($cert)
$rootStore.Close()

Write-Host "证书已创建并添加到受信任根证书区。指纹: $($cert.Thumbprint)" -ForegroundColor Green

关键参数解析 ：

• -Subject “CN=…” ：这是证书的标识名。 CN （Common Name）最好包含有意义的名称，如公司或项目名。
• -KeyLength 2048 ：2048位RSA是当前安全与兼容性的平衡点。4096位更安全，但有些旧工具或系统可能支持不佳。
• -HashAlgorithm SHA256 ： 必须使用SHA256或SHA384、SHA512。 Windows从某个版本开始已禁止用SHA1签名的驱动加载。
• -CertStoreLocation “Cert:\LocalMachine\My” ：证书创建在“本地计算机”的“个人”存储区。相比“当前用户”存储，这能让所有用户访问到该证书，更适合开发环境。
• 重要警告 ：上述命令将证书同时加入了“受信任的根证书颁发机构”。这 仅适用于你的开发机 ！对于其他测试机，你应该只导出公钥证书（.cer）再手动导入其“受信任的根证书颁发机构”，而 绝不 在测试机上生成或拥有私钥。

步骤3：找到你的证书指纹 创建成功后，记下输出的 Thumbprint （指纹），它是一个40位的十六进制字符串，如 a1b2c3d4e5f67890123456789012345678901234 。你也可以通过以下命令查看：

Get-ChildItem -Path Cert:\LocalMachine\My -CodeSigningCert | Format-List Subject, Thumbprint, FriendlyName

步骤4：使用Signtool为驱动文件签名 首先，找到 signtool.exe 。它通常在 C:\Program Files (x86)\Windows Kits\10\bin\<版本号>\x64\ 或 x86 目录下。为了方便，可以将其路径加入系统环境变量 PATH ，或者直接使用完整路径。

假设你的驱动文件是 mydriver.sys ，在包含该文件的目录下打开PowerShell，执行：

# 使用证书指纹进行签名
& "C:\Program Files (x86)\Windows Kits\10\bin\10.0.22621.0\x64\signtool.exe" sign /fd SHA256 /sha1 YOUR_CERT_THUMBPRINT mydriver.sys

# 或者使用证书主题名称（如果唯一）
# & "C:\Program Files (x86)\Windows Kits\10\bin\10.0.22621.0\x64\signtool.exe" sign /fd SHA256 /n "CN=MyDevelopmentRootCA" mydriver.sys

签名参数解析 ：

• sign ：执行签名命令。
• /fd SHA256 ：指定签名文件时使用的摘要算法，必须与证书哈希算法匹配或更高，推荐统一用SHA256。
• /sha1 <指纹> ：通过证书指纹指定使用哪个证书进行签名。这是最精确的方式。
• /n “<主题名>” ：通过证书的主题名指定。如果存储区有多个相似主题的证书，可能出错。
• /tr <时间戳服务器URL> 和 /td SHA256 ：这是 强烈建议添加的参数 ，用于添加时间戳。即使你的证书过期，带有有效时间戳的签名在签名时刻仍然是有效的。例如： /tr http://timestamp.digicert.com /td SHA256 。

一个更健壮的签名命令示例：

& "C:\Program Files (x86)\Windows Kits\10\bin\10.0.22621.0\x64\signtool.exe" sign `
    /fd SHA256 `
    /sha1 a1b2c3d4e5f67890123456789012345678901234 `
    /tr http://timestamp.digicert.com `
    /td SHA256 `
    mydriver.sys

步骤5：验证签名 签名完成后，务必验证：

& "C:\Program Files (x86)\Windows Kits\10\bin\10.0.22621.0\x64\signtool.exe" verify /v /kp mydriver.sys

• /v ：详细输出。
• /kp ：验证策略，确保签名符合内核模式代码签名的要求。 如果看到“Successfully verified”字样，并且哈希算法、证书链信息正确，说明签名成功。

3.2 方法二：传统方式（MakeCert + Signtool）

虽然 MakeCert 已过时，但在一些特定环境或遵循老旧指南时可能还会遇到。了解它有助于排错。

步骤1：创建自签名根证书 你需要找到 makecert.exe （通常也在Windows SDK目录下）。通过命令行（管理员）操作：

makecert -r -pe -n "CN=MyTestRootCA" -ss CA -sr LocalMachine -a sha256 -cy authority -sv MyTestRootCA.pvk MyTestRootCA.cer

• -r ：创建自签名（根）证书。
• -pe ：将私钥标记为可导出。
• -n “CN=…” ：证书主题。
• -ss CA ：证书存储名，自定义为“CA”。
• -sr LocalMachine ：存储位置为本地计算机。
• -a sha256 ：签名算法。
• -cy authority ：证书类型为颁发机构。
• -sv .pvk ：指定输出的私钥文件。
• 最后是输出的公钥证书文件。

执行过程中会提示你为私钥文件设置密码。

步骤2：创建代码签名证书（由根证书签发）

makecert -pe -n "CN=MyTestCodeSigning" -a sha256 -cy end -sky signature -ic MyTestRootCA.cer -iv MyTestRootCA.pvk -sv MyTestCodeSigning.pvk MyTestCodeSigning.cer

• -cy end ：证书类型为终端实体（用于签名）。
• -sky signature ：密钥用途为签名。
• -ic 和 -iv ：指定颁发者证书和私钥文件。

步骤3：将PVK和CER合并为PFX文件 Signtool 通常使用包含私钥的PFX文件进行签名。使用 pvk2pfx.exe 工具：

pvk2pfx -pvk MyTestCodeSigning.pvk -spc MyTestCodeSigning.cer -pfx MyCodeSigning.pfx -po mypfxpassword

步骤4：使用PFX文件签名

signtool sign /fd SHA256 /f MyCodeSigning.pfx /p mypfxpassword /tr http://timestamp.digicert.com /td SHA256 mydriver.sys

• /f ：指定PFX文件路径。
• /p ：PFX文件的密码。

步骤5：将根证书（MyTestRootCA.cer）安装到测试机的“受信任的根证书颁发机构” 这是让测试机信任你签名的关键一步。双击 .cer 文件，选择“安装证书” -> “本地计算机” -> “将所有证书放入下列存储” -> “浏览” -> 选择“受信任的根证书颁发机构”。

3.3 为完整驱动包（.inf + .sys）签名

如果你的驱动包含 .inf 文件，最佳实践是签名目录文件（ .cat ）。

步骤1：使用Inf2Cat生成目录文件 首先，确保你的 .inf 文件语法正确，且 [Version] 节中定义了正确的 CatalogFile 和 DriverVer 日期。然后在包含 .inf 文件的目录打开“适用于VS的x64/x86本机工具命令提示符”（来自VS安装）：

inf2cat /driver:. /os:10_X64

• /driver:. ：指定驱动文件所在目录为当前目录。
• /os:10_X64 ：指定目标操作系统为Windows 10 64位。可以指定多个，如 /os:7_X64,8_X64,10_X64,11_X64 。

成功后会生成一个 .cat 文件。

步骤2：签名.cat文件 使用 signtool 像签名 .sys 一样签名这个 .cat 文件。

signtool sign /fd SHA256 /sha1 YOUR_CERT_THUMBPRINT /tr http://timestamp.digicert.com /td SHA256 mydriver.cat

步骤3：验证.cat签名

signtool verify /v /kp mydriver.cat

步骤4：安装驱动 现在，你可以右键点击 .inf 文件，选择“安装”。系统会检查关联的 .cat 文件的签名，并因为其根证书已被信任而允许安装。

4. 测试机部署与信任建立

开发机上签名成功只是第一步。要让驱动在另一台干净的测试机上运行，必须建立信任。

操作流程：

1. 从开发机导出根证书 ：在开发机上打开 certmgr.msc ，导航到“受信任的根证书颁发机构” -> “证书”，找到你创建的自签名根证书（如 MyDevelopmentRootCA ）。右键 -> “所有任务” -> “导出”。在导出向导中， 选择“不，不要导出私钥” ，然后选择格式为“DER 编码二进制 X.509 (.CER)”，最后指定导出路径和文件名（如 MyRoot.cer ）。
2. 将证书文件传输到测试机 。
3. 在测试机上导入证书 ：
   • 双击 .cer 文件，点击“安装证书”。
   • 选择“本地计算机”，点击“下一步”。
   • 选择“将所有证书放入下列存储”，点击“浏览”。
   • 关键步骤 ：选择“受信任的根证书颁发机构”，点击“确定”，然后完成导入。
4. 安装驱动 ：现在，测试机已经信任了你的根证书。你可以通过设备管理器更新驱动、右键安装 .inf ，或使用 pnputil 命令来安装已签名的驱动包。

重要安全提示 ：自签名根证书是你的“万能钥匙”。务必妥善保管导出的 .cer 文件，并 绝不 将包含私钥的 .pfx 文件或带私钥的证书存储区权限随意分发。测试完成后，应从测试机的“受信任的根证书颁发机构”中删除此证书。

5. 高级配置、排错与实战心得

即使按照步骤操作，你也可能会遇到各种问题。下面是我在多年实践中总结的常见坑点和解决方案。

5.1 禁用驱动程序强制签名（临时测试）

在极端情况下，你可能需要完全关闭驱动签名强制以进行调试。 注意：这会严重降低系统安全性，仅限临时在测试机上使用，且重启后可能失效或需要重新操作。

• 方法A：高级启动菜单（Windows 10/11）

  1. 设置 -> 更新与安全 -> 恢复 -> 高级启动（立即重新启动）。
  2. 重启后选择“疑难解答” -> “高级选项” -> “启动设置” -> 重启。
  3. 重启后按 F7 键选择“禁用驱动程序强制签名”。

• 方法B：使用BCDEdit命令（需要管理员权限）

  # 禁用
  bcdedit /set testsigning on
  bcdedit /set nointegritychecks on # 在某些系统上可能需要
  # 启用
  bcdedit /set testsigning off
  bcdedit /set nointegritychecks off
  

  执行后需要重启。桌面右下角会出现“测试模式”水印。

5.2 常见错误与排查表

5.3 自动化与集成实践

对于频繁的驱动构建和测试，手动操作效率太低。这里分享一个我常用的PowerShell脚本框架，可用于自动化签名流程：

# AutoSignDriver.ps1
param(
    [string]$DriverPath = ".",
    [string]$CertThumbprint = "YOUR_CERT_THUMBPRINT_HERE",
    [string]$TimestampUrl = "http://timestamp.digicert.com"
)

$SignToolPath = "C:\Program Files (x86)\Windows Kits\10\bin\10.0.22621.0\x64\signtool.exe"

function Sign-File {
    param([string]$FilePath)
    Write-Host "正在签名: $FilePath" -ForegroundColor Yellow
    & $SignToolPath sign /fd SHA256 /sha1 $CertThumbprint /tr $TimestampUrl /td SHA256 $FilePath
    if ($LASTEXITCODE -ne 0) {
        Write-Host "签名失败: $FilePath" -ForegroundColor Red
        exit 1
    }
    Write-Host "验证签名: $FilePath" -ForegroundColor Yellow
    & $SignToolPath verify /v /kp $FilePath
    if ($LASTEXITCODE -ne 0) {
        Write-Host "验证失败: $FilePath" -ForegroundColor Red
        exit 1
    }
    Write-Host "成功: $FilePath" -ForegroundColor Green
}

# 签名所有.sys文件
Get-ChildItem -Path $DriverPath -Filter *.sys | ForEach-Object {
    Sign-File -FilePath $_.FullName
}

# 如果有.cat文件也签名
$catFile = Get-ChildItem -Path $DriverPath -Filter *.cat
if ($catFile) {
    Sign-File -FilePath $catFile.FullName
}

Write-Host "所有驱动文件签名完成！" -ForegroundColor Cyan

你可以将此脚本集成到CI/CD流水线（如Azure DevOps, Jenkins）的构建后步骤中，实现驱动编译后的自动签名。

5.4 关于时间戳的深刻教训

我曾经因为忽略时间戳，在证书过期后导致所有已签名的驱动在全新系统上都无法安装。 时间戳服务器 的作用是记录你执行签名操作的那个时间点。即使你的签名证书在2024年1月1日过期，只要你的驱动是在此日期之前（例如2023年12月1日）签名的，并且签名时添加了有效的时间戳，那么系统在验证时会检查“签名时刻”证书是否有效，而不是“安装时刻”。因此， 永远使用时间戳签名 。除了上面用的DigiCert，还有其他公共时间戳服务器：

• http://timestamp.sectigo.com
• http://timestamp.comodoca.com
• http://timestamp.globalsign.com/scripts/timestamp.dll

在 signtool 中使用 /tr 参数指定。如果某个服务器不可用，可以尝试换一个。

5.5 内核模式与用户模式签名的细微差别

我们主要讨论的是内核模式驱动（.sys）的签名，它要求最严格。对于用户模式的驱动程序或普通应用程序（.exe, .dll），签名流程基本相同，但验证策略宽松一些。例如，某些用户模式组件可能在没有签名的情况下也能运行（但会有SmartScreen警告），而内核驱动没有有效签名则根本无法加载。在签名时，内核驱动更强调使用 /kp 参数进行验证，并确保哈希算法符合Windows硬件兼容性计划的要求。

6. 从自签名到生产签名：路径与考量

自签名是开发和测试的利器，但绝不能用于公开发布。要分发驱动，你必须获得受微软信任的代码签名证书。

1. 标准代码签名证书 ：来自受信任的CA（如DigiCert, Sectigo）。适用于普通应用程序和部分用户模式驱动。但自Windows 10 1607版起，对于新的内核模式驱动，仅此证书已不够。
2. 扩展验证（EV）代码签名证书 ：这是发布内核模式驱动和通过微软WHQL认证的 必需品 。EV证书的私钥存储在硬件加密设备（如USB令牌）中，安全性极高。购买EV证书后，你可以用它来签名驱动，并将其提交给微软进行WHQL测试。通过后，驱动将获得微软的正式数字签名，可以在所有开启安全启动的Windows系统上无缝安装。
3. Windows Hardware Compatibility Program (WHQL) ：这是微软官方的硬件兼容性测试和签名程序。使用EV证书签名驱动提交后，微软会进行一系列测试。通过后，你的驱动会被加入微软的官方驱动目录，并通过Windows Update自动分发。这是驱动分发的“黄金标准”。

个人经验之谈 ：在项目早期，用自签名快速迭代原型和进行内部测试。当驱动功能稳定，准备进行外部Beta测试或小范围分发时，可以考虑购买标准代码签名证书（如果只是用户模式）或直接上EV证书（如果是内核模式）。在提交WHQL之前，务必使用EV证书在所有目标Windows版本上进行充分的签名和测试，因为EV证书的签名行为与自签名在某些边缘情况下可能有细微差别。整个自签名的熟练过程，实际上为你后续操作生产证书打下了坚实的基础，因为工具（signtool）和核心概念（证书链、时间戳）是完全相通的。