代码签名证书被吊销怎么办？从清点旧包到恢复新版交付

代码签名证书被吊销，先停用这张证书的签名任务，向颁发机构核实原因，再找出下载页和更新渠道里用过它的文件。恢复发布要同时解决两件事：新包的来源可信，新签名能被接收端验证。只买一张新证书，旧安装包和旧更新器不会自动跟着修好。

本文按Windows软件的下载、安装和升级链路排查。Java包、苹果应用和内核驱动，需另核对应平台的发布要求。

一、先拿到明确的吊销结果，别凭一句签名错误下结论

把CA通知放在证书详情旁边，先核对颁发者，再逐字符比序列号。两处都吻合，就在清单中标记这张。遇到两张都写着同一公司，也照样分别比对：企业名称告诉你是谁在发软件，不能据此区分新旧证书。

截图只有“未知发布者”时，请客户补上原文件和详细报错。接下来盯住错误对应的证书：是签署程序的那张，还是链中的上级证书？明确查到吊销结果，再按该证书追查；提示“无法查询吊销状态”，则先测试网络能否访问状态服务，并核查验证环境。没取回状态信息，不能推断CA已经执行了撤销。

接着让CA说明吊销原因和生效时间。私钥泄露、未经授权签名，与其他撤销原因要分别处理。不要一见吊销就断言软件有病毒，也不要只看证书上写着明年到期，就认定它还能继续签名。

时间戳也得放在具体验证规则里看。DigiCert的吊销文档明确把带时间戳的签名列入影响范围，并要求使用有效证书重签。处理旧包时，要把证书状态、签名与时间戳、目标系统采用的策略放在一起核对，不能承诺“以前签的全有效”。

二、把受影响的包找齐，产品名称不够用

按发布版本展开文件清单，在每份文件的数字签名详情中找到颁发者、序列号，筛出与通知相符的项目。每行再补上文件名、SHA-256摘要和交付位置，版本号也保留。客户只说“我装的是上一版”还不够，让他提供文件摘要，才能对到清单中的具体成品。

取样覆盖官网按钮、CDN入口和客户交付目录，每个位置都下载一份，记清出处并计算SHA-256。若三个入口返回了两种摘要，就按两份成品分别追踪，不能因为都叫同一个文件名就合并。研发本地的样本留作参照，清点对象是渠道实际发出的副本。

清单还要沿安装和更新流程往下展开：主安装器运行时另外取了哪些组件，旧版升级时拿到的是增量包还是完整更新包？把实际下载对象补进表里，再翻客户交付记录找专用版。换掉外层安装器的签名，只处理了外层文件，后面取回的组件仍须逐份核查。

涉及来路不明或未经授权签名的文件，先停止分发，保留副本与发布记录供排查。对已确认来自正常构建的历史版本，再根据验证结果安排替代版本和客户动作。

三、旧版受不受影响，要在下载、安装和升级处分别检查

Windows软件代码签名不是做完一次验证就算结束。用户下载文件、启动安装器、运行已安装程序、更新器接收下一版，调用的检查机制并不完全相同。程序现在还能打开，不能证明下一次安装或更新一定通过。

用Microsoft SignTool检查文件时，可以按工具文档选择Authenticode验证策略，读取完整结果。保留检查的文件摘要、系统版本、联网状态、时间和错误原文。不要把“在我电脑上成功了”当成交付结论。

先收齐两台机器的验证输出，确认文件摘要一致，再看检查策略是否相同。查清有没有联网请求、缓存中用的是哪份状态信息，别只比最后一行。输出只有“状态未知”，接下来查数据为何取不到；它没有证明CA已经撤销该证书。

请客户指出出错的按钮和提示界面，再在测试环境中用已核实来源的相同版本复现。浏览器拦住下载、系统阻止安装、更新器不收新包，要分别找到对应文件和规则。证书吊销不是终端卸载操作；判断旧版受了哪些影响，要按客户实际采用的策略检查启动和升级。

四、涉及密钥或账户失控，先恢复可信签名环境

私钥泄露或签名滥用已经查实，就停掉相关签名任务，再逐条翻日志找产出文件。每条任务都要对回发起账号和机器，确认是否属于批准的发布。对不上的任务，把原始日志、构建记录和文件副本一起保存，交给CA与安全负责人调查。

使用UKEY代码签名证书，要核查令牌保管、调用它的电脑及相关操作记录。使用云代码签名证书，要核查签名账户、调用凭据和任务权限。密钥存放方式不同，排查入口也不同，不能只换一张证书就结束。

替代申请中写清原证书标识和密钥泄露事实，交由CA核实。此时必须换一套密钥，不能继续拿旧公钥申请新证书。证书下发后，检查其中公钥是否来自本次生成的密钥对，并把核对结果留在这次变更记录中。

源码版本与构建环境查清后，再产出准备发布的新包。旧EXE的出处无法核实，就先留作调查，别抢着换签名。验签核对的是签署身份和签后内容有没有被改过；程序内部是否藏着恶意行为，还要单独排查。

五、新包签好了，再试旧用户能不能收到它

这次即便用EV代码签名证书接替旧证书，也不能向客户承诺SmartScreen会立即信任新文件。选定来源可信的构建产物后，用新凭据完成签名和时间戳操作，再为该成品留下验签与试装记录，供交付时逐项复查。

测试机先装客户正在使用的版本，再从软件内部发起更新，观察它在哪一步接收或拒收新包。查明产品是否绑定了旧证书指纹、某个公钥或发布者条件，并对照客户现有允许规则。文件验签的结论之外，还得拿到更新器的接收结果。

把更新器的结果与企业终端策略分开核对。产品接受新包，客户的应用控制规则仍挡住它，就由客户管理员审核新发布者、证书或文件规则。给出新旧文件对应信息，按授权流程更新配置，不让用户关闭签名验证来安装。

旧更新路径已走不通，就准备经过验证的替代安装包和明确的迁移步骤。测试时从旧版本实际升级，检查安装结果、版本号及必要配置是否保留。光在空白电脑上装一次，不能代表已有客户升级成功。

六、下载页、更新清单和客户说明一起换

按第二节的清单逐处处理分发副本，官网新包上线后接着清CDN旧缓存，再换掉客户交付目录里的旧文件。测试人员从每个对外位置取回一份成品，登记摘要和签名；哪一处还拿到旧版，就把该位置退回发布人员继续处理。

成品经过重签或重建，字节变了，更新清单中的摘要就得重算。把成品的地址、版本和新摘要一同写回清单，再触发一次更新，用收到的包重新计算核对。清单若仍存着旧摘要，完整性校验就会挡下这次更新。

客户说明写清受影响版本、替代版本、核实过的获取渠道和需要执行的动作。是否重装、是否更新允许规则，要根据已验证的失败阶段说明，别给所有客户发一句“重新下载即可”。

最后保留CA通知、受影响文件清单、新包验证和升级结果。替代代码签名证书已经能用于签名，只完成了凭据切换；新版确实能送到客户并通过接收检查，才完成这次交付恢复。

代码签名证书吊销后处理常见问题

1、证书被吊销，就说明软件一定有病毒吗？

不能仅凭吊销认定软件带毒。先读CA通知里的撤销理由，确认是主体资料变化，还是私钥失控、可疑签名。调查时把报错文件对回构建记录，找出有疑点的任务和成品；软件是否含恶意内容，要检查这些成品，不能拿通知代替检测。

2、旧安装包有时间戳，是否就不用处理了？

仍要核查。可信时间戳不是吊销豁免，应按具体文件、吊销信息和接收环境验证。一次验证成功，也不能代表全部客户的安装与更新路径都通过。

3、签名工具还能调用旧证书，可以继续发布吗？

不能继续用它交付。工具报成功，只代表签名运算做完了，接收端是否信任这个凭据是另一道检查。先落实CA要求的处置措施，等替代凭据审核完成，再签新包、查结果；别把工具的绿色提示当成交付已经恢复。

4、拿到新证书，能直接给旧安装包重签吗？

把旧包摘要对回发布记录，先确认它是可信成品。核对不上，或已怀疑构建环境失控，就先排查并重新构建；来源已确认的包，重签后仍要做安装和从旧版升级的测试，不能直接把新签名当成安全证明。

5、给代码签名证书续费，能恢复被吊销的那张吗？

续费救不回那张旧证书。联系颁发机构，问清替代申请的材料和审核安排；如果原来的私钥已经外泄，申请时必须换掉它。拿到替代凭据，还得让客户旧版实际下载并接收新包，不能到领取代码签名证书就结案。

相关阅读：代码签名证书被吊销