WinVerifyTrust仅验证签名链完整性与时间有效性，不校验颁发者和指纹；需手动提取证书上下文，用CertGetNameStringA解析颁发者、CryptHashData计算SHA256指纹，并严格比对。
WinVerifyTrust 验证主EXE签名颁发者是否可信
直接调用 WinVerifyTrust 可以验证当前进程 EXE 是否被可信证书签名，但默认不校验「颁发者」和「指纹」——它只判断签名链是否完整、时间是否有效、吊销状态是否正常。要验证特定颁发者（如 “DigiCert SHA2 Code Signing CA”）或 SHA256 指纹，必须配合 CRYPT_PROVIDER_DATA 和 CRYPT_PROVIDER_SGNR 手动提取签名信息。
关键点：不能只看 WinVerifyTrust 返回 ERROR_SUCCESS 就认为“安全”，它不阻止自签名或测试证书通过（除非显式配置策略）。你得在验证成功后，再从提供者数据里捞出证书上下文，用 CertGetNameStringA 和 CertGetCertificateContextProperty 逐项比对。
- 调用
WinVerifyTrust前，必须传入WINTRUST_DATA并设置dwUIChoice = WTD_UI_NONE和fdwRevocationChecks = WTD_REVOKE_NONE（否则联网吊销检查可能失败或阻塞） - 验证成功后，用
WTHelperProvDataFromStateData获取CRYPT_PROVIDER_DATA*，再用WTHelperGetProvSignerFromChain提取第一个签名者（CRYPT_PROVIDER_SGNR） - 从
pSgnr->pasCert[0].pCert拿到PCCERT_CONTEXT，这才是原始证书上下文
提取并比对证书颁发者名称（Issuer）
颁发者名称是可读字符串，但 Windows 存储的是 CERT_NAME_STR 编码格式（如 "CN=DigiCert SHA2 Code Signing CA,O=DigiCert Inc,C=US"），不能直接 strcmp。必须用 CertGetNameStringA 按 CERT_NAME_ISSUER_FLAG 解析，且注意返回值是字符数（含结尾 \0），不是布尔值。
常见错误：传错 dwType（比如用了 CERT_NAME_SUBJECT_FLAG）、忽略返回值直接用指针、没分配足够缓冲区导致截断。
立即学习“C++免费学习笔记（深入）”；
- 先调用一次
CertGetNameStringA(pCert, CERT_NAME_RDN_TYPE, 0, NULL, NULL, 0)获取所需长度 - 分配
char* issuerBuf = new char[len]，再调第二次填入内容 - 比对时建议用
_stricmp（忽略大小写），因为证书字段大小写不固定；例如匹配 "DigiCert" 而非硬编码全大写 - 若需精确匹配（如白名单控制），应提前把预期颁发者字符串 normalize 成 RDN 格式再比，避免因空格/逗号顺序差异误判
计算并校验证书 SHA256 指纹（不是文件哈希）
所谓“证书指纹”是指证书 DER 编码的 SHA256 哈希值，不是 EXE 文件本身的哈希，也不是签名块哈希。必须从 PCCERT_CONTEXT->pbCertEncoded 出发，用 CryptHashData 计算，而非读取文件某段。
容易踩的坑：有人误用 ImageHlpApi 的 GetSignedInfo 或直接哈希 PE 文件，结果永远对不上；还有人用 CertComputeSubjectNameHash（那是 SHA1 主题哈希，已淘汰）。
- 确保
hProv是有效的PROV_RSA_AES提供者（CryptAcquireContextA获取） - 调用
CryptCreateHash(hProv, CALG_SHA_256, 0, 0, &hHash)，再CryptHashData(hHash, pCert->pbCertEncoded, pCert->cCertEncoded, 0) - 用
CryptGetHashParam(hHash, HP_HASHVAL, hashBuf, &hashLen, 0)取出 32 字节原始值，再转为十六进制字符串（小写、无分隔符）用于比对 - 注意：Windows 自带的
CertFindCertificateInStore等函数不暴露指纹，必须自己算
完整流程中必须绕开的兼容性陷阱
WinVerifyTrust 在 Windows 7 上行为和 Win10/11 不同：Win7 默认不启用 WTD_REVOCATION_CHECK_END_CERT，即使你设了也可能被忽略；而 Win11 对 EV 证书有额外策略（如要求时间戳服务可用）。更麻烦的是，如果你的 EXE 是 32 位，在 WoW64 下调用时，某些证书存储访问会静默失败。
- 不要依赖
WINTRUST_ACTION_GENERIC_VERIFY_V2—— 它在旧系统上可能未定义，改用WINTRUST_ACTION_TRUSTPROVIDER_TEST或硬编码 GUID{0x00AAC56B,0xCD44,0x11D0,{0x8C,0xC2,0x00,0xC0,0x4F,0xC2,0x95,0xEE}} - 所有
Cert*和Crypt*API 调用后必须检查返回值（TRUE/FALSE），不能只看 GetLastError；例如CertGetNameStringA失败时返回 0，不是 -1 - 释放资源顺序很重要：先
CryptDestroyHash，再CryptReleaseContext，最后CertFreeCertificateContext；反过来可能导致句柄泄漏或崩溃 - 如果程序自身被加壳或压缩（如 UPX），签名验证大概率失败——因为
WinVerifyTrust校验的是原始 PE 映像，不是内存解压后的镜像
真正难的不是调通 API，而是把颁发者字符串标准化、把指纹计算路径和证书上下文生命周期管清楚。哪怕只漏掉一次 CertFreeCertificateContext，下次验证就可能拿到脏指针。
