尝试验证协议DLL代码签名时遇到错误的原因

协议DLL（如SecureCRT的SSH/Telnet协议插件、远程桌面协议DLL等）在验证代码签名时报错，核心原因通常就那么几类，按出现频率从高到低排列：
一、证书本身的问题（最常见）

证书已过期或被吊销。 签过名的DLL如果证书已过有效期，验证时会直接报”签名无效”。尤其是自签名证书，有效期通常只有1~2年，过期后签名立刻失效。

证书链不完整。 很多人只装了客户端证书（.pfx），但没安装中间CA证书。验证时系统找不到从根证书到签名证书的完整信任链，直接判定签名不可信。这是最容易被忽略的原因。

证书不是来自受信任的CA机构。 如果你用的是自签名证书，而目标系统（尤其是64位Windows）启用了驱动强制签名策略，自签名证书根本不在系统的”受信任根证书颁发机构”存储中，验证必然失败。

签名算法被弃用。 如果签名时用了SHA-1算法（2026年已经被Windows全面弃用），验证会直接报错。现在必须用SHA-256及以上。
二、DLL文件本身的问题

DLL在签名后被修改过。 哪怕改了一个字节，签名哈希就对不上了，验证必然失败。有些打包工具、压缩软件在解压过程中会改动文件时间戳或内容，导致签名失效。

DLL文件损坏或版本不匹配。 从网上下载的协议DLL如果本身就不完整，或者版本和你当前软件版本不对应，签名验证会报错。

签名后又被其他程序加了数字签名。 有些DLL被多个证书签过（双重签名），如果第二个签名覆盖或冲突，验证会混乱。
三、系统环境问题

系统时间不准确。 这是个低级但高频的原因。如果电脑系统时间和当前时间偏差较大（比如差了几个月），证书的有效期校验会直接失败，报”证书已过期”或”证书尚未生效”。

WINTRUST.dll加载失败。 Windows的签名验证依赖WINTRUST.dll和wintrust.dll这两个系统组件。如果它们被误删、损坏或被杀毒软件隔离，任何DLL的签名验证都会报错，典型错误码是0x800B0100（”无法验证文件签名”）。

杀毒软件或安全策略拦截。 Windows Defender、360、火绒等在扫描DLL时可能直接篡改或隔离文件，导致签名校验失败。企业环境中的软件白名单策略也会阻止未签名或签名不可信的DLL加载。

驱动强制签名策略生效。 64位Windows从Vista开始强制驱动签名，部分协议DLL如果被系统判定为内核态组件（比如某些SSH协议插件），必须用EV代码签名证书签名，普通OV证书签的名在这些场景下不被认可。
四、签名操作本身的问题

没加时间戳（timestamp）。 签名时如果没加时间戳，证书一过期签名就失效。正确的签名命令必须带时间戳参数，例如：

signtool sign /f certificate.pfx /p password /tr http://timestamp.digicert.com /td SHA256 myprotocol.dll

签名工具版本过旧。 老版本的signtool可能不支持SHA-256或新的证书格式，签出来的签名在新系统上验证不通过。

签名时用了错误的证书类型。 协议DLL如果要在SecureCRT等软件中正常加载，有些场景要求必须用EV代码签名证书，用OV或DV签的名会被软件本身拒绝。
五、快速排查步骤

第一步，右键DLL → 属性 → 数字签名，看签名状态是否显示”此数字签名正常”，颁发者是谁，证书是否过期。

第二步，用PowerShell验证：Get-AuthenticodeSignature -FilePath your.dll | Select-Object Status, SignerCertificate，Status显示Valid才算通过。

第三步，检查系统时间是否准确，运行sfc /scannow修复可能损坏的系统组件。

第四步，确认证书链完整，把中间CA证书也导入到”受信任的根证书颁发机构”存储中。

如果以上都没问题，大概率是杀毒软件拦截或签名时没加时间戳。需要的话可以把具体报错信息发过来，帮你进一步定位。