软件已经签名，用户运行时却仍看到“未知发布者”或安全警告，应先确认警告来自哪个机制，再检查用户实际下载的文件。签名存在、签名有效、目标电脑信任发布者，以及安全策略允许运行，是四个需要分别验证的条件。
本文以 Windows 桌面软件的 Authenticode 签名为主，面向软件开发、发布运维与证书采购团队，梳理 8 个根因和对应证据。驱动、MSIX 及企业受管环境另有要求，不能把普通 EXE 的验证结果直接套用到全部发布方式。
一 先认清警告 才能选对排查路径
UAC 提权提示关注程序请求的权限及发布者信息。签名被目标电脑识别和信任后，仍可能出现管理员授权提示；“显示已验证发布者”不等于“不再需要授权”。
SmartScreen 的下载或运行警告还涉及信誉判断。一个签名有效、发布者名称可显示的新程序，仍可能因为文件或发布者信誉不足出现“无法识别的应用”等提示。若看到这类信息，不应直接判断证书链已经失效。
企业的 AppControl、AppLocker 等策略也可能单独阻止软件运行。因此，第一份排查记录应包含完整提示文字、触发阶段、文件路径、Windows 版本、下载来源和文件 SHA-256，而不是只有“客户说不信任”一句描述。
二 签名了却不被信任的 8 个根因
根因一 签的是内部程序 用户运行的是未签名安装器
发布流水线可能只签了主EXE，却遗漏安装包、启动器、升级器或请求提权的辅助程序。用户最先执行的文件并不是团队验收过的那个文件，发布者自然可能显示异常。
应对实际触发提示的文件验证签名，逐项盘点安装与升级路径中执行的组件。签名内层程序不会自动替外层安装器签名，安装器有签名也不能证明全部内层文件都已签名。发布门禁应检查最终交付物和关键可执行组件。
根因二 签名后又打包或修改了受保护的内容
签名之后继续改写程序资源、嵌入配置或重新处理可执行文件，可能破坏被签名内容的完整性。文件属性里仍能看到“数字签名”页，不代表完整性验证一定通过。
应先完成会改变文件内容的处理，再签名、加时间戳并验证。对需要分层签名的安装包，先完成内层文件，再生成并签署最终安装器。若下载文件验证失败，应对照流水线产物和下载产物的哈希，定位改动发生在哪一步。
根因三 证书用途或实际签名身份选错了
HTTPS 服务器证书不能直接替代代码签名证书。签名使用的证书、用途与链路必须符合目标签名策略；仅有一张带企业名称的证书，并不代表它可用于目标文件的发布验证。
应检查实际签名者的主题、指纹、有效期及Code Signing 用途，并与采购及发布记录比对。多证书环境下，自动选择可能选中非预期身份。签名参数中的说明文字不会代替证书身份，验收应以文件中真实签名者为准。
根因四 目标电脑无法建立受信任的证书链
开发机可能缓存了中间证书，安装了测试根，或已有最新根库；用户电脑则可能缺少相应材料。因此，“我的电脑验证正常”不能代表所有客户环境都正常。
应在没有额外测试信任配置的干净环境验证，检查实际链、系统更新状态，以及离线或受管设备的证书分发情况。缺少中间证书与根不受信任是不同问题，应按链构建结果处理。
公开分发宜使用目标 Windows 环境认可的代码签名路径。自签名或私有 CA 可以用于受控内部部署，但需要组织按管理流程分发信任，不能要求公众随意导入一个根证书来替代发布验收。
根因五 时间戳缺失或无法验证
代码签名证书过期后，没有有效时间戳的签名可能失去有效性。可信时间戳用于证明签名在某个时刻已经存在，使符合条件的签名在签名证书过期后仍可被验证。
应检查是否实际写入了时间戳、时间戳证书链是否可验证，以及签名时是否位于签名证书有效期内。签名命令包含时间戳地址，不等于服务调用已经成功；应保存完整结果并将异常纳入发布阻断。
时间戳也不是永久豁免。签名完整性、吊销、算法与验证策略仍可能影响结果。新发布通常采用SHA-256 摘要，并按服务商支持方式使用 RFC 3161 时间戳；不能把本机文件创建时间当作可信签名时间。
根因六 吊销检查失败 被误判成证书已吊销
证书被吊销，与客户端无法取得吊销状态，是不同情况。代理、DNS、出站规则、证书分发点不可达或缓存问题，可能让验证无法完成；实际处理还取决于调用者和系统策略。[5][7]
排查时应保留错误码，检查失败证书及相应链路，必要时查看CAPI2 日志中的链构建、策略验证和检索记录。不要只测试一个网页能否访问，就认定全部验证服务正常。
若确认已吊销，应联系签名服务商或CA 查明原因，并按需要使用有效身份重新签署发布。如果只是状态无法获取，应修复网络或管理配置，不能把全局关闭吊销检查当作客户解决方案。
根因七 验证策略与软件类型或企业要求不匹配
普通 Authenticode 验证、驱动加载要求与企业应用控制规则并不相同。SignTool 未指定 /pa 时使用 Windows 驱动验证策略；用错验证方式，可能让普通应用得到与预期不同的结果。
对常规桌面 EXE，可先执行 signtool verify /pa /all /v "setup.exe"，检查完整验证输出。若是驱动，应按目标系统与发布流程核对微软驱动签名政策；普通代码签名通过不代表内核驱动一定允许加载。
企业环境则需查看策略命中原因。AppControl 的 CodeIntegrity 日志、AppLocker 的相应日志可以帮助识别被拒绝的文件和规则。[9] 修复应由管理团队调整必要的允许规则或发布配置，而不是让用户关闭系统保护。
根因八 签名有效 但SmartScreen 信誉仍不足
如果 Authenticode 验证通过、发布者也已识别，出现的却是 SmartScreen“无法识别的应用”警告，就应转入信誉与分发问题排查。微软说明，文件哈希或发布者证书的负面或未知信誉，都可能导致警告；OV、EV 有效签名也不保证首次下载免警告。
应保持真实发布者身份与清晰分发来源，确保所有最终交付物正确签名，检查是否存在恶意软件误报，并按微软官方渠道提交需要复核的样本。不要通过制造下载量或要求用户忽略全部警告来解决问题。
不存在适用于所有软件的“签名后几天必定消除警告”承诺。采购代码签名服务时，应重点核对身份验证、密钥保护、时间戳、流水线集成和支持能力，而不是只听“保证无弹窗”的宣传。
三 用三步检查缩小问题范围
第一步，锁定最终文件。把官网或分发入口实际下载的文件与发布产物核对，记录哈希、签名者和触发警告的组件。对客户端发布，应从安装到首次启动、升级及卸载检查整条流程。
第二步，验证签名与链。可使用PowerShell 的 Get-AuthenticodeSignature -LiteralPath'.\setup.exe' 查看签名状态、签名证书及时间戳信息，再用 SignTool 获取详细验证结果。命令应在目标 Windows 环境中执行，当前开发环境的结果不能替代客户环境。
第三步，判断拦截机制。签名失败先处理文件、证书、时间戳和链；签名有效却被阻止，再查看SmartScreen、企业策略或驱动要求。保留截图、哈希、工具输出与日志，才能让开发团队、管理员和 CA 围绕同一份证据定位问题。
发布完成的标准，应是最终文件的签名和时间戳验证成功、目标环境信任路径正确、必要的策略要求满足，并且已按真实分发方式测试。它不等于承诺所有Windows 安全提示都消失。
常见问题 FAQ
问题一：EXE 已签名 为什么仍然显示未知发布者？
先确认提示对应的是哪个文件。可能是安装器或提权组件未签名，也可能是签名完整性、证书链、时间戳或目标电脑信任异常。验证用户实际执行的最终文件，不能只看内部主程序。
问题二：买 EV 代码签名证书 能保证不出现 SmartScreen 吗？
不能保证。微软当前说明中，有效OV 或 EV 签名的新应用仍可能因信誉不足出现警告。EV 身份验证与签名信誉是不同事项，选型应结合发布流程和支持需求。
问题三：已验证发布者的程序 为什么仍弹出 UAC？
UAC 还用于确认管理员权限请求。发布者已验证说明身份信息得到识别，并不意味着程序自动获得管理员权限。应同时评估是否确实需要提权。
问题四：代码签名证书过期 已发布的软件要全部重新签吗？
不一定。有效可信时间戳可能使签名在签名证书过期后继续可验证，仍须满足完整性、吊销与相关策略。缺失或无效时间戳的文件应结合实际结果安排重签。
问题五：自签名证书能解决公众用户的未知发布者吗？
一般不能自动获得公众Windows 环境的信任。它适合受控内部测试或部署，并需按组织流程管理信任。公开软件应采用适合目标环境的受信任签名路径。
问题六：开发机验证正常 客户电脑失败 怎么排查？
核对双方使用的文件哈希、系统版本、根与中间证书、网络和企业策略。再使用干净目标环境复现，避免开发机缓存或测试根掩盖问题。
问题七：只签安装包 是否还需要签主程序和升级器？
需要按组件用途检查。外层签名不会自动替内层可执行文件提供独立签名。会被运行、提权或被策略单独检查的组件，应纳入签名清单与验收。
问题八：排查签名不受信任 应准备哪些材料？
准备完整警告截图、触发阶段、文件路径与SHA-256、Windows 版本、下载来源、签名者、时间戳、SignTool 输出及相关日志。先定位失败环节，再决定修复、重签或提交复核。